Even though I find Fossil to be a far more rewarding experience, Git did one thing that few technologies ever have done (any?). Across platforms, across development models, across the entire programming field, a majority of programmers now have a point of common interest, Git. 97% of programmers may only ever use a thin layer of monkey-see monkey-do subcommands and Git..b hand holder websites, but the technology is of common interest. As a profession, we should aim for more of those.

So, learn enough Git to not be left out of the common conversations, and then use Fossil. :-)

Edit: Just as I pressed Submit I realized that SQLite may count as another of the rare ubiquitous technologies, putting Fossil only one small step away from the greatness of a globally accepted point of common interest.

Unfortunately this is probably true. Git is everywhere. There is as LOT that I like better about fossil, but the truth is that if git included a ticket and wiki system for cheap like fossil does, I would probably switch over to the dark side and use git just in order to be compatible with all the git hooks that are everywhere these days. They are in IDE's, they are on GitHub and other sites, they are just everywhere. If you want to get along with most of the development world, git is the common denominator...like it or not...and there are things I do really dislike about git, but nonetheless that is where it is now. Things can change, we'll see what it looks like in 10 years, but for the foreseeable future that is true.

Nonetheless I continue with fossil for my own small projects because A, I like using it a lot more and B it includes the wiki and ticket system, which is really key for me. In order to setup similar functionality with git requires setting up a huge infrastructure that is way over the top too much for me...for me the sheer simplicity of fossil with a single small executable and a few sqlite files laying around is just way too awesome for the simple work I do.

On the Git is everywhere front...

I've lately been playing a little bit with Rust. Cargo (the Rust build tool) supports using Fossil as the SCM. But it sets it up in a very Git way. A ".fossil" repository in the root of your checkout. Even when other tools attempt to support alternatives to Git, they support them in the Git way.

I use Fossil because I don't want to use Git. Git is NOT easier than fossil. Git is a horribly complex system with arcane invocations. Fossil is clean and simple. Like many things in the world today, the common perception is upside down because everything is based on a culture of personality. If Linus Torvalds says use Git, then by his word, we will use Git.

I wish a culture of competency and logic predominated instead. Then I think Fossil would do better. I will continue to use Fossil because it is the first SCM product that was understandable to me and works well with the way I think and work.

I am quite sure that Tovolds doesn't care if anyone outside the Linus kernal group uses GIT. It is there to use or not as you like. It just works well for him and that is enough.

I use Fossil because I don't want to use Git. Git is NOT easier than fossil. Git is a horribly complex system with arcane invocations. Fossil is clean and simple.

Same here, except I use monotone instead of Fossil… and while I take a stand of using it for my personal projects (which, still, need to be "exported" to github as a way to receive user patches) I am either using SVN o git on the workplace.

I bear much of the same heavy spirit and little hope as you (and the rest of the thread) carry.

It's a sad state of things, and it doesn't look like it will improve anytime soon. gameoftrees is one of the few efforts that could at least in theory improve that (as a personal tool, while the rest of the team would probably continue using plain git).

I'm personally not worried about it whether git will be the dominate source control system. I'd rather people focus on building applications and maintaining those applications.

There was a time when it looked like Windows was going to be the only serious operating system for business or home use. Along came Apple computer and later their very polished operating system. Linux, while just a kernel, has fostered many distributions via kernel + userspace GUI stuff. Now there's a new X compositor thing, wayland, appearing. X.org may fade away and perhaps will only be memories in our minds and no longer a window system we remember. Windows has a subsystem layer to run Linux.

Just today someone on the OpenBSD mailing list asked why not use git. Here's the thread: https://marc.info/?t=156380787000001&r=1&w=2

All this said, I enjoy Fossil and appreciate its growth in popularity and features.

I thought one of the *BSD projects is (or was) using Fossil. Obviously not OpenBSD.

Jörg Sonnenberger of the NetBSD project evaluated switching to Fossil some years ago but rejected it due to the time it takes to rebuild the repo lookup tables after the initial on-clone data pull. It took many hours on their busy ~25-year-old repo, so they couldn't tolerate it.

We have a possible solution for that, but now we want someone who cares to implement it.

Interesting way to solve a cvs/git problem: https://gameoftrees.org

https://undeadly.org/cgi?action=article;sid=20190810123007

Stefan uses Fossil! https://lobste.rs/s/sxpmar/game_trees_version_control_system_under#c_6nwn2k

got is still too complicated: it retains the stage/unstage and rebase features of Git.

Just today someone on the OpenBSD mailing list asked why not use git.

Because git is the lazy choice.

I don't deny that git works for Linux. Linus is why git works for Linux. Linus demands a high level of discipline from his lieutenants and their lieutenants. I would expect any VCS to work for Linux while under Linus's command.

Why does git work for other projects? My guess is that many (most?) of those use git very simply, avoiding (most of) the features that get git users in trouble.

I say "(most of)" because rebase seems very popular. From my observations, non-core contributors seem to be contributing most on non-core features. I would expect these to be low activity parts of the code base, so much less likely to venture into trouble.

For what it's worth, nearly all of my attempts to contribute changes to even near-core features resulted in many iterations of updating and resolving conflicts before my changes were accepted (or I gave up).

Often it just "seems to work". I get annoyed when I submit my personal contribution to a third party project, presenting a good pull request (the Git way) only to see my contribution being squashed into a single commit that says "merge pull request", and all my description (and even my email and paternity) are wiped-away because the repo maintainer doesn't know how to use Git well.

Just recently I've spent a whole morning creating a nice pull request to enhance a project, and present it a series of individual commits, each introducing a separate feature, with meaningful commit headings and descriptions. After the PR was squashed it, there's only a single commit with a vague "merge pull request", which is attributed to the repository owner — my user ID and email no longer appear anywhere.

Why? Because using Git the right way is to complicate for many people (who'd like to spend more time coding than learning complex tools), so they just settle for a combination of commands which they know will do the job (e.g. pull the third party PR branch locally, test it, then squash it locally and push it upstream yourself).

Tristano Ajmone (Italy)

After the PR was squashed it, there's only a single commit with a vague "merge pull request", which is attributed to the repository owner — my user ID and email no longer appear anywhere.

That's been my experience, too. As a result, I now present my changes as a single commit. Sometimes this survives and my commit appears as I submitted it. More often, the dev accepting my PR makes a new commit with just "merge PR #xxx" as the comment. No doubt doing just as you described.

FYI: Warren's thread got picked up by HN on 2020-01-06. Lots of follow-up discussion there.

Thanks. Interesting link in the discussion to a new Source Control system,
based on DArcs (i.e. system of patches), and implemented in Rust, with the
catchy motto "Simple, distributed, fast. Pick any three" :).

Was new to me, so sharing it here. --DD

https://pijul.org/

It's a little weird that they blatantly hijack sqlite's motto but make not a single mention of fossil in their FAQ, as if they've never heard of it. They mention darcs, git, svn, and cvs, but not fossil.

Uh? I don't see that motto in http://fossil-scm.org/home/doc/trunk/www/index.wiki, nor any motto for that matter.

Oops, SQLite's motto, not Fossil's, my bad.

This is a common motto and joke, I doubt SQLite is the first one to use it. Not sure why you'd feel offended by it, even more so when it's from an unrelated project (SQLite is a "embedded" DB, not an SCM).

This is a common motto and joke, I doubt SQLite is the first one to use it. Not sure why you'd feel offended by it,

i didn't say offended, i said it's "little weird." FWIW, i've never seen any other project use that motto, and sqlite's had it for more than a decade.

even more so when it's from an unrelated project (SQLite is a "embedded" DB, not an SCM).

Please double-check check which SCM sqlite uses (and which embedded database software fossil is based on) ;).

Edit: there's a very strong hint as to the answer to both of those in the GoT FAQ:

http://gameoftrees.org/faq.html#openbsd

Office is far from dying. The market share is actually going up yoy.

Office is far from dying. The market share is actually going up [year over year].

It does look like there is some recent bounce back, but that ignores the fact that Office was once had a market share in the 95% range. That was eroded badly over about 10 years by Google Docs, blogging, mobile, and such.

In the past few years, Office 365 has begun clawing some of that back by participating in the new mobile spaces. It took Microsoft an awful lot of effort to achieve that, and even then, I don't see it ever getting back into the 90s of percent use.

How do we apply any of that to Fossil? We don't have a megacorp backing us to push Fossil's adoption. It's actually the other way around: in a sense, Microsoft bought Git via GitHub.

How do we apply any of that to Fossil? We don't have a megacorp backing us to push Fossil's adoption.

Preferably, one of us need to become a billionaire so they can do for Fossil what Mark Shuttleworth did for Ubuntu.

That'd be my personal preference, anyway :).

one of us need to become a billionaire

I nominate you. :)

Hi

I deliberately skipped reading the text so it doesn't alter my thoughts "prematurely".

I think one does not need to replace git, just the tools that are used to work on top of the undelying system ("blockchain" and (merkle-)dag trees).

Like got (game of trees) but better...

Microsoft's long-term stalwarts Windows and Office are dying

MS Windows is not dying at all. It is - unfurtunately - the standard OS used by default by 90% of desktop users in the world.

Microsoft's long-term stalwarts Windows and Office are dying

[Windows] is...the standard OS used by default by 90% of desktop users in the world.

Yes, and my original point is that desktop computing is being displaced by other forms: Chromebooks, mobile, etc. Microsoft has repeatedly tried and failed to push Windows into those markets, and under Nadella, they've basically given up trying.

Even if you consider only desktop computing, that just supports my original point here: it's very difficult to replace a global monopoly. Windows is "dying" only to the extent that other platforms are replacing it, not because Windows is losing much ground in its original core market.

For any of this to have any bearing on the original question of whether Git can ever be replaced, you'd have to imagine a world where the Internet and GitHub are no longer the platforms of choice, so that switching DVCSes is less painful because you're switching the low-level platform as well.

The Internet isn't going away for the same reason Ethernet isn't going away: whatever we replace it with, it'll still be called the Internet, and we'll have gateways between the two as long as the transition occurs. (I'd say this has already happened several times. 1985's Internet, 1995's Internet, and 2020's Internet are all very different from each other.)

GitHub may eventually die, but not for a long while in the future. Even if Microsoft does somehow manage to beach that aircraft carrier, I think the inertia from it and competing platforms (GitLab, BitBucket, etc.) will continue indefinitely.

Replacing Git is not likely to happen on a global scale, but there are couple ideas for "small" quality-of-life changes Fossil could make that would make it much more adapted to compete and thrive in a Git world.

• Boost the visibility of Fossil’s existing "pull request" functionality: Bundles. Make it easy to make bundles from the web UI (just like we can already make tar archives from the web UI). Make it easy to submit/upload bundles via the web UI. An uploaded bundle would be attached to a ticket; if accepted, its data removed and replaced with a reference to the branch/checkin.

• Implement Oauth so people can quickly create user accounts tied to their identities at Github or any other Oauth provider (https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/). On repos where this is enabled, this would make it easy for anyone with a Github account to contribute just as they do on other Github projects, without the rigmarole of creating Yet Another Login Somewhere.

• Stop fighting the syntax highlighters...drop the use of <blockcode><pre> for code markup and go with <pre><code> like everyone else in the world, preferably also specifying class names with the file's extension and other niceties for syntax highlighters. (Perhaps also, do line numbering outside the listing)

These would go a long way toward addressing the three things that seem to put Github users away off using my Fossil repos: 1) "how do I submit a pull request", 2) annoyed they have to make Yet Another Login on a weird little website, why not just put it on GitHub, 3) "wut no syntax highlighting?".

... changes Fossil could make that would make it much more adapted to compete and thrive in a Git world.

It's a common misconception that fossil aims to (or should aim to) compete with git. Where that idea comes from is anyone's guess, as nobody associated with the project has ever (to the best of my knowledge) espoused it.

Git and Fossil are completely different beasts with completely different needs and different targets. Git can no more painlessly serve small-team projects via CGI than fossil can scale to the Linux kernel's scope. Apples and oranges. (Yes, there's 3rd-party CGI infrastructure for git, but i was unable to get it working in less than an hour when i tried it 6 or 8 years ago.)

Boost the visibility of Fossil’s existing "pull request" functionality: Bundles. Make it easy to make bundles from the web UI (just like we can already make tar archives from the web UI). Make it easy to submit/upload bundles via the web UI.

As neither of fossil's two primary client trees (sqlite and fossil itself) accept drive-by patches, there would seem to be little incentive to put in the effort for this (again, keeping in mind that "competing with git" is in no way a factor which drives fossil's development). That said, patches implementing it would almost certainly be welcomed.

Implement Oauth ...

Or LDAP or Active Directory or whatever the cool kids are using this week. This is another case of "not needed by fossil's core-most clients." Fossil's lack of need (so far) for this feature goes back, i opine, to its scale: it targets small/mid-scale projects with a relatively tight-knit group of developers. As i believe Richard put it (and my apologies if this is mis-attributed): Fossil is the Cathedral and Git is the Bazaar.

Again, though: patches in this direction would likely be welcomed, provided they were implemented in a way which allowed fossil to easily swap out auth methods to whatever the cool kids are using this week. It seems fair to say, though, that none of the currently-active fossil developers have much need or interest in implementing it.

Stop fighting the syntax highlighters...drop the use of <blockcode><pre> for code markup and go with <pre><code> like everyone else

Fossil's markdown handler and the /artifact page both use the (dare i say it?) git-conventional/markdown-conventional (is there a difference?) pre/code pair. The /artifact page guesses the language-XXX tag to add to the block based on the file extension¹ and the markdown handler allows one to specify a language using the same approach markdown conventionally does.

Fossil does not (and likely never will) include specific syntax highlighting support with its core deliverable because doing so requires inclusion of a non-trivial 3rd-party JS library. However, it is quite simple to plug a 3rd-party syntax highlighter into fossil, as i recently documented for my own future reference:

https://fossil.wanderinghorse.net/r/cwal/doc/tip/doc/highlightjs/README.md

That page uses the syntax highlighter itself, and here's an example of it at work on a fossil-served C file via the /artifact page:

https://fossil.wanderinghorse.net/r/cwal/artifact/677b9fdd88782ef2

---

1. ^{^} should .h files use language-h (as they currently do) or language-c (which seems more correct)?

It's a common misconception that fossil aims to (or should aim to) compete with git.

Maybe compete was the wrong word? But the misconception might come from the heavy work and discussion that's been done on interoperating with git, as well as threads like this one and of course the title of the widely-shared "Fossil vs. Git" (VERSUS is competition language.)

I understand that Fossil's core contributors don't intend to compete with git per se, but I as a Fossil user and advocate do have to compete with Git when it comes to attracting and training contributors to my projects. Don't think of me as a bazaar advocate, think of me as trying to bootstrap a couple of cathedrals.

Or LDAP or Active Directory or whatever the cool kids are using this week.

Just to clarify... OAuth is almost as old as Fossil. It's a bog-standard protocol for allowing identity reuse across independent websites. I can understand you not having interest in implementing it, but to imply it's a fad is silly.

Fossil's markdown handler and the /artifact page both use the (dare i say it?) git-conventional/markdown-conventional (is there a difference?) pre/code pair.

I must have missed this. My 2.10 copy still uses blockquote-pre. The new functionality is almost there (line numbering is still janky).

VERSUS is competition language

That is a meaning of the word, but not the only one. My nearest electronic dictionary includes the definition, "as opposed to; in contrast to."

The document you point at goes to great lengths to show that Fossil and Git are very different things. While I'm not opposed to all of your ideas, we should also be under no illusion that Fossil will ever become feature-for-feature competitive with Git, if only because some of Git's features we absolutely do not want. (rebase, separate stage-and-push, etc.)

Ultimately, Fossil moves forward as its contributors wish. If you want to see Fossil do a thing, follow the contribution guide.

I...do have to compete with Git when it comes to attracting and training contributors to my projects

I've maintained a few significant FOSS projects of my own and been a contributor to others, and I can tell you that every time the VCS is given as an excuse for why someone isn't contributing, it's just a ready-to-hand excuse, not the real reason.

FOSS existed before VCSes were even widely-relevant. You can't square that with the claim that choice of VCS greatly affects whether contributions get made.

Another way to puncture that argument is to challenge the person claiming that they'd contribute if only... to provide a patch or even just a copy of the changed file. Statistical prediction: crickets. Those who are disposed to contributing will do it whatever VCS you use, and those just making excuses will continue to make them no matter how much you accommodate their demands.

And if those counterarguments still don't work for you, set up a Fossil-to-Git mirror of your project and watch the PRs continue to fail to appear. That's right, I'm saying you can offer to hand-convert GitHub PRs to patches and push them up through Fossil, and it still won't be enough for a lot of self-styled potential contributors.

OAuth is almost as old as Fossil.

And the current version of LDAP is about a decade older, with the original version being years older still. Through Microsoft Active Directory, it remains in widespread use within almost every large organization.

AD in turn can connect to pretty much every other SSO system you can name via ADFS.

But here again we have the old problem: someone has to have this problem and want to have it scratched themselves. I've written AD integration code for $dayjob, but I don't need Fossil to have AD integration myself, so I don't write it.

I'll tell you this much: this is something of a tarpit, not in the slightest way trivial. Not only is it a mapping problem, where ontologies collide, identity is a nontrivial problem to begin with. Just for one example, there is no "I" for me to this very forum, only wyoung and wyetr, depending on where I'm posting from. Which one is "Warren Young?" Both and neither, because "Warren Young" is a third "I".

If you think that's just pseudopsychological mumbo-jumbo, then which of my two GitHub public identities — which I keep separate for much the same reason as my identities here — do those two fossil-scm.org logins map to?

For that matter, wyoung is a different "I" here on the forum than on fossil-scm.org/fossil, with very different powers on each repo. Which one is the true "wyoung" and how do we map that "I" into and out of other identity systems?

I'm telling you, it's a tarpit.

I suspect if Fossil ever gets a feature along these lines, it'll have to be locally-pluggable and configurable so that the answers to these questions can be pushed out to the edges. I doubt Fossil core can provide answers that a large number of users will find even marginally useful, much less wholly agreeable.

My 2.10 copy still uses blockquote-pre

And inside that is <code class="language-FOO">, so you're both right.

I wrote that feature, and I used it to implement Prism.JS on my public repos. It's do-able.

line numbering is still janky

Please post an example showing the problem, preferably a link to a public Fossil instance showing the symptom.

EDIT: "Erm, trouble with grammar have I, yes!" — Yoda

• Syntax highlighting - As Stephan said, this can be done, and he has it working.

• Oauth support - I think the best way to do this is to run Fossil behind a webserver and setup the webserver to be an Oauth client. It will probably be necessary to "massage" the resulting user ID to make it acceptable to Fossil. Also, you will need to setup a separate registration page to collect the user info and send it to you so you can add the new user to the Fossil repo.

• Easier bundle submission - Fossil's ticket system supports attachments. You could create a wiki page to create a submission ticket. Also, modify the view ticket page to display submission tickets specially and make it easy to attach the bundle. (Unfortunately, Fossil only allows attaching to an existing ticket, not when creating a ticket.)

Of course, this assume that the would be contributor actually sets up Fossil. Otherwise, the contributor will be submitting a patch file. But, the same submission ticket idea for bundles will work for patch file, too.

The main real showstopper which prevents Fossil for going it's way of being possible to replace Git - is the entrance threshold, that is, how easy is to contribute, which practically means "pull requests" or something similar.

That is, Git was taken by GitHub because of Linux kernel, but real mass spread of Git is due to GitHub's ability to easily:

• submit a contribution
• accept a contribution

See, one does one command "git push" and HTTP link in reply, where PR is confirmed, than upstream developer can VIEW the submitted code easily on Web UI or begin a CODE REVIEW process, again on Web? with ability to put comments on each code line, in which request to do some things in the patch other way (then contributor can just push new commits with fixes), etc.

The crucial thing of what GitHub, GitLab (and other competitors) have offered on top of plain Git - is easyness of collaboration and code review.

It's really, REALLY has nothing to do with "Cathedral vs Bazaar" style - because similar workflows is adopted by many commercial companies which are defineteley Cathedral inside!

See, I worked at several companies where they had an internal GitLab instance, then junior / linear programmers forked branches for each task in issue tracker (maybe not GitLab's one, but e.g. Jira), then created Merge-Requests from these task branches, which were reviewed by senior developers / team leads (if not GitLab but e.g. Atlassian one, it can be even vote like "3 of 5 reviewers OK then merge automatically") and then merged (either via Web or manually via Got cmds after testing).

Now see what? The entire niche of that tools was born just due to Git lacking features, but Fossil already has many of them! Tickets, forum, wiki - almost everything is here already. Missing is only the last and crucial part - interface for easy code review. That is, it not enough to just send a fossil bundle by manually attaching file - this already perceived as boring even by those who remember RCS and CVS. And also this is not enough for upstream to do many repetitive manual actions of taking that bundle, importing it, reading diffs, then manual copy-pasteing of diff lines into message to originator... Time-consuming - machine must work, and people think.

So this probably should be new type of artifact, for code review in UI. But observe also:

Git had architectural support for such global collaboration - in form of E-Mail address

Moreover, Git is able to record distinct "author" and "committer" fields, thus in proper done Pull-Request on GitHub there could be commits showed as authored by that 3rd-party contributor (not core developer). While it's very simple technically, this has serious moral and ethical consequences, as honoring / giving credits to contributors right available (not in unknown txt-files "maybe I'll not forget you"...).

So, fossil needs to expand U cards format in manifests for e-mail address, and/or have new T card type. This is not an "identity system" - but this allows to individual projects to have such, if they need.

P.S. Let me emphasize once again: the attitude of all that previous threads on pull-requests, contributors, GitHub etc. summarized as "- How to do PRs? - bundle ... - That's too hard, GitHub's better" - is, actually, a question of moral and ethics. Psychologically, they are unconscious, but all them roughly could be translated as:

Who the hell are YOU (what right do you have) to REQUIRE me to do such many actions and put so many efforts (ahh, and that's going to be repeated each time!) for such perhaps small contribution? This is UNFAIR!

And so they move to "competitors" on this "market" where "price" is much more close to "average market".

In fact, this is not CatB but more of "closed" vs "open" society distinction (one make impose strict high standards on code itself, and being Cathedral, like FreeBSD, but still be open to contributions).

Note that the same logic applies also to Bug Reports, e.g. for many software it is "What? I have to register on this zillionth small web site and receive spam on mail just to tell your prog crashes with this cmdline option?!". And here Fossil (and many projects on it) already has very good openness - by allowing anonymous tickets.

Now that's what coould be done with code revies / PRs... of course not anonymous here, but the indentity system and such should be left to eash project. Tools, not policy - the old Unix principle.

-- nuclight

similar workflows is adopted by many commercial companies which are defineteley Cathedral inside!

Irrelevant, because within a company, you don't need to allow anonymous contribution. Junior devs simply commit to a branch in the company's central repo, then they prevail on some senior dev to merge their branch down. You see more or less the same thing happening here within the Fossil project for potentially controversial changes.

put comments on each code line

While that would be a convenient quality-of-life improvement to have in Fossil, I don't see it as a key reason behind GitHub's success. It came rather late, as I recall, after GitHub was already successful.

In Fossil, you can get much the same effect by pointing at a commit's /info page and to its contents' /file?ln=NN pages from a forum post.

For instance, I recently made this commit. One of the changes was to this line. Now you can see both the diff and a reference to the line number, and you can comment on it here in a forum reply.

All of the pieces for a code review feature are there, just not nicely linked together yet. So, yes, it would be nice if you could do the line highlighting thing from within a diff, then create a forum posting from that link to discuss it, which linked back to the commit. It would also be nice to be able to merge a branch from Fossil UI, rather than only from the command line.

I don't see any of this as a deal-killer for Fossil. If you do, we'll gratefully consider your contributions.

Git had architectural support for such global collaboration - in form of E-Mail address

Yes, and it's arguably a tarpit of a GDPR violation. There is no way to support the Europeans' notion of "right to be forgotten" within Git short of shooting the Merkle tree full of holes.

Back when all of this GDPR stuff was hot news, I recall GitHub, Inc. basically punting on this, saying it's the repo owner's problem. That's BS, as far as I'm concerned, but it'll probably take a lawsuit to settle it. Fortunately, no one's been crazy enough to bother.

Meanwhile Fossil takes a principled PII protection stance from go: we reveal only user names, nothing else. If you're from the EU and you think even your user name should be removed from the history of a project, and the repo owners agree to accommodate you, it'll still shoot holes in the Merkle tree, but it's a lower risk than in Git repos.

Note that this sort of thinking is spreading beyond the EU. California has a GDPR-like law on the books now, and all of this current kerfuffle in the US Congress, grilling the brass from the big tech companies, is likely some sort of prelude to passing similar laws at the federal level.

If you're outside both the US and the EU, this still affects any organization with global reach, and it affects software products produced within their bounds, which outsiders then use.

Git is able to record distinct "author" and "committer" fields

That would be nice. Currently, fossil praise shows the user name of the one who did a merge to a parent branch for changes that it should attribute to the committer to that line on the merged branch.

Thus in the workflow above, where a junior dev creates a branch and a senior merges it, the senior currently gets credit for the junior's work in such reports. I think the senior shouldn't be mentioned except in the commit that did the merge, unless they edit lines of committed code as part of that merge, and then only for those changed lines.

This is UNFAIR!

This is a project management decision, is what it is.

The GitHub PR world is a mess. I just had someone send me a PR for a Fossil-based project I mirror to GitHub, and I had to tear it to pieces to get anything I could merge. For most of it, I ended up using GitHub's code review features to explain why each of dozens of unacceptable pieces couldn't be merged.

That would be an argument in support of your position if the one pushing it took my feedback and changed their branch to make their fork mergeable as-is, but they didn't. They just said "sorry for wasting your time" and went away. This is typical of anonymous-grade PRs.

It is in fact one of the major problems with bazaar development: many forks and PRs never go anywhere. The ability to easily create them doesn't tell you anything about how useful they will be, and it doesn't aid the merge in the main case, where the offered PR is unacceptable as-is, and the one pushing for it isn't willing to work within the project's rules to make it acceptable.

If you have a contributor who is likely to provide contributions that are almost always mergeable as-is, Fossil's answer is, "Give them a commit bit!" Now you don't need PRs.

What is making Git so successful and where could Fossil-scm become better?

I think the visibility is one point. When to be found by whom?

Searching the web by Google for keyword Fossil shows many watches and links to prehistoric life but NOT easy to find fossil-scm with an association to version control systems. (This is different if you know already that you have to search for the keyword fossil-scm.)

Doing the same for keyword Git shows the 3 main points:

• Downloads
• Book
• Wikipedia

The "easy to learn" aspect is another often under-estimated point.

How many up-to-date books are printed and/or available about Fossil?

Git is described everywhere - but mainly just the basics or for experts and corporate usage.

Fossil-book (Schimpf-book) seems to be old but still the newest and only available.

I missed good examples - only that book gave me the required introduction to start with fossil-scm at all. I would have liked more examples to learn from and to shorten the experimental phase.

The first step is always the most important one on each long walk in any direction.

Integration into IDE and other infrastructure

Fossil-scm is good not only for the intended use but also for other use-cases. This needs to be accepted and smooth integration into other environments is needed. The hooks concept and the /ext CGI are powerful ones and should be improved. CI/CD for DevOps is such an interesting field. - Low degree of dependencies, easy multi platform installation and usage; inside containerized environments!? From repository per auto-sync to an hook'ed update... (Example: How to re-sync an already versioned set of files with hook-activation? From once-only to repeatability.)

What's needed to create Git compatible interfaces for integration? REST-API ? Integration APIs? Git-to-fossil wrapper tools? Which IDE's are the major players and how could fossil become integrated into them?

How to make fossil-scm work together with Git instead of trying to replace it?

Push/pull/sync integration with Git but user activities via fossil-scm only - is that feasable? Fossil-scm could become the front-end for otherwise only git based version control. - My feeling "why should someone do this" leads to the slice-clone subjects. Why do I have to have the whole repository if I need only to work on one branch (vertical split) or on recent commitments (horizontal cut-off)? Why do I have to deal with the difficulties of Git if fossil-scm is so much easier to use and has everything compact in very few database(s)?

The more share fossil-scm will gain the more willingness will raise to use fossil-scm where Git is not absolutely needed and for purposes where Git would not fit well or not at all.

Proposal:

Start collecting use-case examples and compare them with how Git could do them - or not. Compare the effort, the pros and cons and how fossil-scm could help with. - Accept that fossil is already as-it-is more than just a software development support tool.

I think the visibility is one point. When to be found by whom?

It's practically all over the site at sqlite.org and mentioned many times in the forum and in the former mailing list. Those who actively use SQLite are probably aware of the VCS driving sqlite. Those who actively use linux could be aware of what VCS is being used for the linux kernel, but may only know it by name.

How many up-to-date books are printed and/or available about Fossil?

I'm certain the number is 0. I think for someone to write a book, they'd want to know how many people would actually buy it to see if their investment of time is worth it. Even if you're talking about a free ebook/PDF, you would want an idea of how many people will read it prior to starting it. I'm not so sure Fossil is something that needs a book. The help commands are online and updated. If you clone the Fossil repo, you can get the Fossil site all locally to work offline. I don't know what people do for git documentation offline...maybe man git??

Perhaps something would be helpful for a new user to Fossil is a test repo with examples that existing documentation and forum posts covers. Branching, blames, forking, mistake branches, etc. Pretty much exactly the Fossil repo but in a much more contained manner.

Start collecting use-case examples and compare them with how Git could do them - or not.

You're saying see how people who use git actually use it for their projects and see how it would be different if they replaced Fossil?

I agreed with Sean that maybe we don't need a book and maybe we can bridge this documentation alternatives with the idea of use cases. For example, we are making a workshop in IndieWeb with "pocket infrastructures" and I'm writing most of the documentation as the related workshops happen. As in Schimpf's book, this is a Fossil by example work, but we don't want to cover broad Fossil's use cases, but use it in a pretty focused way, as the storage backend for the Brea headless CMS.

We use and agile customized workflow where I prepare and take quick Markdown real time notes on CodiMD that are complemented by the community and they're stored in Fossil using Pandoc and Brea to convert them to micro-site. The IndieWeb with Brea site is made using Brea and showcases the use of the technologies behind (Pharo, Pandoc, Fossil).

Also I have made some reproducible research visualizations and docs using Fossil as a portable future proof document format for storing computable documents and related static resources (this was before the Web Document Format proposal in this forum).

By the way, I'm kind of amazed by this obsession with popularity and huge scales (particularly in the Global North) and becoming the "next big thing". But I think that the differential values of Fossil are in those places where big numbers are not the core issue and paradoxically the big majorities are well served by these technologies of innovation from the edges suited for the small/middle size communities. Is kind of similar to how most projects are more like SQLite that like the Linux Kernel. In our different use cases, we have had laser focus custom made documentation practices well suited for collectives like us and Fossil has been a core technology there.

Maybe what we need is not only to show how we are similar to Git/Git*b, but how we're different, and how those differences add value to a wide a diverse number of communities around the world (for example in agile and resilient documentation and data storytelling practices) with decrease complexity and overheat. Fossil could be like SQLite, that is not the next big thing, but the small thing that is everywhere, well suited for the computation in edges and the people and communities behind.

By the way, I'm kind of amazed by this obsession with popularity and huge scales (particularly in the Global North) and becoming the "next big thing".

Amen.

Becoming popular, widespread, or supplanting git has never been a stated fossil project goal. All statements suggesting otherwise, insofar as i've noticed anyway, have been from newcomers who assume, for whatever reason, that that's something we're interested in doing and/or have failed to achieve so far.

Fossil is, first and foremost, perhaps even exclusively, developed to be useful for those who currently use it, not for those who might potentially use it "if we could only draw them away from git."

Fossil is not about supplanting git. Fossil is about being useful in and of itself, independent of the usefulness of any other SCM. No one single SCM is a perfect solution for all projects, and there's lots of room for several, perhaps even many, SCMs to coexist without any of them having to actively compete for popularity or mind-share.

I worry that Git might be the last mass-market DVCS within my lifetime.
Git effectively has a global monopoly on DVCSes, and I don't see how you replace such a thing.

Perhaps via an approach like Jujutsu (https://github.com/martinvonz/jj).
I.e. an alternate simpler yet innovative porcelain over a Git repo. Maybe...

A wrapper is a nice approach and maybe that would work for me. I guess I could use Fossil today just by running a background sync with the Git repo but that seems redundant (literally). There are a couple things holding me back from using Fossil:

1. Work is all based around GitHub and that's where I also publish my open source projects
2. I use Emacs and its magit tooling is the best VCS interface I've seen aside from Eclipse / Smartgit (I don't use VSCode much but it seems like magit might be better than VSCode's support)

#1: we use GitHub for PRs and code reviews and whatnot so that would really require a two-way sync with Fossil. If that worked, it'd just be using Git as a "GitHub adapter" which is really the redundant approach but I don't see how to get around that.

#2: a wrapper for Emacs that presents a "Git face" for Fossil to support what magit needs might be a cool thing to write but I'm not sure what exactly it would need.

Given the description of your workflow, I wonder why the actual VCS underlying your user-facing tooling does even matter.

I mean, if you're using magit from emacs and Github, does it even matter that Github and magit use Git internally, so that you are not required to touch its CLI (maybe aside from no-brainer stuff like git clone / git push which is sort-of the same across all DVC systems I've seen)?

My work needs to get to and from GitHub using the Git protocol and now that I dig some more, I'm a little pessimistic about background synchronization; see "all but impossible" in the note at mirrortogithub.md:

• The mirroring is one-way. If you check in changes on GitHub, those changes will not be reabsorbed by Fossil. There are technical problems that make a two-way mirror all but impossible. (This is not to be confused with the ability to import a Fossil mirror from Github back into a Fossil repository. That works, but it is not a mirror.)

Not being able to absorb Git changes back into Fossil would seem to make background synchronization impossible...

Emacs magit doesn't work with Fossil so at minimum it'd need a wrapper like I mentioned above. It could potentially take a "split" approach and use an export-only git repo for the rev logs and whatnot. Maybe that approach would make it possible to at least use Fossil with magit. For open source projects on GitHub though, it seems like merging the first PR would require abandoning Fossil for the project.

Well, no, that's not what I was asking about, actually ;-)

I was interested to hear why you appear to long for using Fossil at your workplace even though you appear to not actually use Git directly.
Like, you have two interfaces you interact with: Github web UI and magit in Emacs.
Suppose they are named Frobhub and mafrob; does it then matter they use "something called Git" as the data storage format and wire transfer protocol?

In other words, to me, your setup looks like Git is sort of a bit of infrastructure which can be mostly ignored as long as the user-facing tooling work.

---

As a matter of fact, I think the whole Git's shtick today is that it is well insulated from a Joe Average Developer by the tools they use — such as IDEs, — so they can mostly ignore the particulars of the DVCS they are using.
This is distinctly different from the relatively short timeframe (2005-2010 may be?) where distributed VC systems were riding atop their hype wave, and Git certainly had an appeal as a tool designed for hackers by (renowned) hackers.

IOW, from my PoV Git merely became an infrastructure thing. It's like you are not too much interested in how exactly electricity is delivered into your house, you just use it.

Directly meaning using the git command in a terminal as opposed to using Emacs as my terminal? I use the command line when I need to, like to manage Git worktrees, but magit's usually way faster to use -- for most cases using magit only needs a keystroke from me in Emacs; way less typing, no need to open a terminal and/or change directories, or whatever. So yes, Git does function behind the scenes for me.

I'd prefer to use Fossil rather than Git underneath all that, so it's not the command line or web interface that makes me prefer Fossil.

I like Fossil because of its philosophy, design, approach, and implementation. I like the single exe, the way it stores all the data in SQLite, the simplicity of its object model (without sacrificing any power), the way multiple checkouts link to a single repo (predating Git worktrees), the fact it includes a web server that provides much of what GitHub does. These are some of the things I like about Fossil as opposed to Git/GitHub.

So if I could switch to Fossil today I would but I'd still be using Emacs as my terminal for most of my access.