Is Git irreplaceable?
(1) By Warren Young (wyoung) on 2019-07-21 06:34:08 [source]
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.
Replacing RCS with CVS was easy. Replacing CVS with Subversion was a big fight in many places. Replacing the remaining CVS and Subversion repos with something modern may never happen. Replacing Git with something better looks impossible.
Old small tech monopolies have fallen many times — e.g. VisiCalc — but I'm struggling to come up with a case where a truly global monopoly like Git has fallen to a single replacement. Here are my best examples, and they're all weak:
Metcalfe's original Ethernet has been replaced a bunch of times, but we either keep calling its replacement Ethernet or we quickly make an Ethernet bridge for it. (e.g. WiFi)
Fossil's already participating in the Git monopoly in this way through
fossil git exportand
fossil import git.
Microsoft's long-term stalwarts Windows and Office are dying, but they're not being replaced by a single thing. There's a diaspora for each: mobile OSes, Chrome OS, and desktop Linux on one side, and everything from Markdown to Google Docs on the other.
Fossil is part of the Git diaspora, but that's a long way from achieving anything like a replacement of Git.
Adobe's having a hard time hanging onto its old market, but it's because people are abandoning their powerful professional general-purpose tools in favor of task-specific and less-functional alternatives: CMSes instead of page-oriented web design, mobile photo apps instead of Photoshop, the web instead of print...
I can only think of one case where a formerly market-leading Adobe product has been completely replaced by a single thing: Flash and HTML5. Observe that it took many years and a tremendous amount of market power to pull that off. Every other dead Adobe product is going the diaspora route, and the dying ones are going that direction, too.
I believe Adobe's Creative Cloud subscription model is relevant here only in that it is a rational reaction of Adobe's leadership to the dying market, not the cause of it.
Even if you believe CC is killing Adobe, that's irrelevant to our argument here, since subscriptions are the sustaining life force for GitHub, GitLab, BitBucket, etc. not their poison. Fossil's world domination will not come from dissatisfaction over subscription fees elsewhere. To the extent that anyone's replacing those cloud repository services with Fossil, I believe it's far more likely due to a wish for control, security, and overall simplicity than a desire to save money.
The market's spoken on that point already with the move to cloud services, where we relinquish control and tolerate lower security to gain some up-front simplicity. It's really easy to set up a basic Fossil server, but it's not as easy as signing up for a GitHub account. Then if you want to add HTTPS to that, running a Fossil server suddenly becomes a lot more complicated.
IPv4 still won't go away despite the standardization of a superior replacement 21 years ago, which subsequently achieved near-complete market penetration a decade or so ago.
Fossil can be one of the many little mammals that help take down the Excel and Git dinosaurs, but I cannot see it ever turning into the "human race" of DVCS products and overrunning the planet.
(2) By Brian Tiffin (btiffin) on 2019-07-21 16:02:21 and edited on 2019-07-21 16:10:52 [history] [link] [source] in reply to 1
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'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.
> Just today someone on the OpenBSD mailing list asked why not use git. And a few individuals in that discussion also mentioned Fossil as a possible replacement though it was ruled out due to scale issues. I find it unlikely that OpenBSD will switch to any new DVCS or other VCS until the benefits clearly outweigh the costs. Thanks, Andy
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.
(11) By sean (jungleboogie) on 2019-08-10 19:28:10 and edited on 2019-08-10 19:37:52 [history] [link] [source] in reply to 6
Interesting way to solve a cvs/git problem: https://gameoftrees.org
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
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).
(23) By Stephan Beal (stephan) on 2020-01-07 15:48:48 and edited on 2020-01-07 16:10:17 [history] [link] [source] in reply to 22
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:
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. :)
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...
Gameoftrees.org is the BSD/MIT licensed variant
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[^1] 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:
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:
.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).
(34) By Warren Young (wyoung) on 2020-01-17 10:08:39 and edited on 2020-01-17 10:13:22 [history] [link] [source] in reply to 33
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
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.