The major competitor to git is mercurial, and while git has won the popularity contest mercurial is still in use across large projects.
Java/openjdk moved from mercurial to git in the 2021 time frame.
I don't believe fossil has ever been used on a scale as large as openjdk from an organizational point of view (thousands of participants in the ecosystem, across dozens of jdk implementations, across more than a dozen hardware platforms, etc)
Fossil as used in sqlite vs mercurial/git openjdk repos as used across the java ecosystem - I think java is one of the projects where platform support is at least as wide as sqlite, if not greater, and the codebase is much larger and more sprawling.
Facebook has moved on from mercurial as well, and it's not to fossil.
Fossil is a great tool, but seeing it as "one or the other" vs git isn't useful.
In particular, this guide on the fossil website is a guide for users wanting to use fossil, so git is not the only competitor, but for the purposes of fossil adopters, that web page is a great resource!
I don't have any special knowledge of this, but it's possible at large companies for both to be going on. The people who don't like the tool move away, and the people who like it try to address some of the complaints to try to dissuade other people from jumping ship, and if they're very good at it, possibly convince others to come back.
As someone who kept track of this from the outside, my understanding is that Mononoke, which was that "Mercurial server written in Rust," eventually diverged from Mercurial proper, and is now a new SCM called "eden". It's also no longer a DVCS.
Gotcha, I don't know about the details, I just know that their readme states very plainly that "Despite having originally evolved from Mercurial, EdenSCM is not a distributed source control system."
Big tech companies often use Mercurial because it's similar enough to git that they can use much of the existing skillset of their engineers, while also modular and easy to customise to allow them to back it on to their custom source control systems.
Wikipedia lists [1] a few more: ArX, Bazaar, Mercurial and so on. Note sure which one qualifies as the "main" competitor though ... feels like an uphill battle. :)
If you want a significantly different one, Pijul[0] is based on the theory of patches and has some really interesting properties (but, to be honest, it would probably take Github accepting Pijul repositories for me to use it which is a shame).
Don't forget Darcs, which is the original implementation of patch theory. I read somewhere that it used to be dismissed because of quadratic complexity on some operation but that this has been solved quite some time ago.
Edit: Correcting myself (and go do your own research, I'm not even remotely involved in any of these things):
> Darcs 2 recently [2020] solved the exponential merge, but it is now quadratic (which is still exponentially slower than Pijul instead of double-exponentially)
I'd like to read more about the actual "theory of patches" but all I can find I'd rather hand-wavy high level descriptions in the docs. Is there more to read about that?
Can you elaborate on some use-cases? I'm finding it hard to imagine a situation where `git worktree add <path> <commit>; do_operation_in_path <path>; git worktree remove <path` is any different than `git checkout <commit>; do_operation_in_path <path>; git checkout -`
You're forgetting the stash command in your latter example. God help you if you're doing anything more than switching to one other branch at a time to make one small change and returning.
Also, if you're unlucky enough to be using an IDE that doesn't always handle large codebase changes well (e.g., let's say... Xcode), then you've eliminated that problem too.
The code base i work on takes a long time to rebuild when crossing certain points in the history, so I have persistent worktrees for the last few versions that we still support. Lets me drop into an older version for a backport without the long wait.
Suppose you have one repo with branches main, v1 and v2 (for example, releases are made from these). The branches are there forever, they are very long running branches.
Some days you work with v1 and some days with v2, and sometimes with main. Sometimes fixes are quick, sometimes not. Sometimes you must switch the working branch while you are in the middle of doing something that is not quite finished.
If you need to change between v1, v2 or main, just change a directory. Done.
So for the above example, setting up this:
cd repo
git checkout -b main origin/main
git worktree add ../v1 origin/v1
git worktree add ../v2 origin/v2
I.e. having a separate worktree for each long running branch makes working with the branches so much easier.
It lets you efficiently have multiple checkouts of different branches at once without duplicating the actual git storage. It also lets you leave a worktree where it is while working on another - for instance, you could have editor windows in different branches at the same time, which isn't an option if you only have one checkout and have to stash+checkout to switch branches.
I like the idea of a completely self-contained source code control.
Honestly, some images of Fossil's UI would be very nice.
One thought: What's now making Git super-powerful is that every IDE that I use has halfway-decent support for Git. I can view a diff of my changes and commit without leaving the IDE. Do any major IDEs integrate with Fossil?
That's really cool! Looking at source files it looks like it does not show color coding. Minor caveat but I'm so used to see code in color formatting that without it I find it hard to read it.
But more importantly, things like side-by-side screenshots of Gitlab / Github / Fossil of major features will also be immensely helpful. I'm thinking of things like pull requests, ticket trackers, ect.
I made this comment on a post a few days ago about using a different SCM:
> I feel like an SCM would have to be WAY better than git to make it worth using. The entire developer community is on git, so you are still going to have to know how to use git in order to access other open source projects. If you are already going to have to be using git for many things, why add a second SCM you have to learn to use?
Because it gets the job done without needing to check the manual every time. We use fossil to manage most of our company code. It's stupid easy to set up, it has a web UI, it has a simple bugtracker, a wiki and a bunch of other stuff. It's fully replicated, we have backups on each repo that somebody is working with and is in sync. We don't bother with git unless we publish something on github.
Do you use any kind of CI/CD pipeline process at all? Pretty much every significant CI platform that I know of is Git-native, or in some cases MAY have some legacy Mercurial support.
If I'm having to give up CI, or hand-roll my own pipeline system completely from scratch, then that's just an unacceptable trade-off. For a personal toy project, fine. But this seems like ridiculous bikeshedding for a professional shop in the 2020's. "Without needing to check the manual every time"? Sheesh, there are really only a few Git commands that most developers ever have to run on a regular basis anyway, and usually an IDE abstracts those.
It's easy nowadays because it's popularity forced everyone to build integration. Git is a absolute nightmare to integrate with CI tools though if you actually have to develop the integration yourself. Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same, and git log is A. not easy to consume B. unreliable since git has so many methods to rewrite history. If you're using something like GitHub it's obviously much easier to use their API but even that is quirky sometimes.
That's my point. Most shops do NOT want to develop their on CI pipeline systems from scratch. I don't care if Fossil makes that theoretically easier, I don't want to do that at all. I want to use a Gitlab CI, or a Circle CI, or hell even a Jenkins. Git has that available ecosystem. No other serious competitor does.
Theoretically, it might be easier to weave your own cloth and then tailor pants from scratch, if you use some novel synthetic fiber rather than cotton. But I don't want to weave my own cloth and tailor my own pants, so I wear cotton blue jeans.
> Git has no native way to reliably tell you what you actually worked on in a branch. Yes it has git diff but that is not precisely the same
I'm not sure exactly what you mean by "what you actually worked on". If you want the files that changed a git diff between the tip of your branch and merge base of the target branch is usually sufficient.
> and git log is A. not easy to consume
You can customize the log format to make it easier to consume
> B. unreliable since git has so many methods to rewrite history.
I'm not sure what that has to do with CI/CD. But if that is somehow a problem for you, then just don't allow rewriting history. Every git server software I'm aware of supports rejecting pushes that rewrite history.
> I feel like an SCM would have to be WAY better than git to make it worth using.
That's how Git overthrew SVN. Cheap branching, robust conflict management, and offline workflows were killer features. Throw in Github, which is more accessible and lower friction than emailing patches and lurking on mailing lists, and SVN's fate was sealed.
Not only that, but it got in as programming was exploding in popularity. It didn’t need to convert people from SVN because it could focus on new users.
A really critical sneaky trick that Linus pulled in the implementation of Git was to just pretend like Sha1 hashes never collide, which helped make "cheap branching, robust conflict management, and offline workflows" possible. This (false but convenient) assumption massively reduced the complexity of many algorithms, and allowed Git to efficiently do things that other source control systems couldn't do. I personally switched from Darcs to Git about 15 years ago entirely due to performance issues.
I suspect the answer is "probably yes", since SHA-1 collisions do exist, and practical ways to generate collisions are known.
Which doesn't mean it's currently risky, I'm not sure how you'd turn a collision into an attack without leaning on external systems (like code review that approves by SHA, and allows you to push later). But if MD5's history is any clue, that will not be true in the long run.
The time to begin moving to a new algorithm was several years ago, when those collisions were demonstrated. Git is unambiguously lagging behind basic security practices here, though that's likely currently fine. The question is for how long that will remain true, and that's something that can only be answered after it has already become unsafe.
Yeah. I think it's still "probably has happened", but it is very very easy to work around: just try again. The timestamp (and thus the hash) will have changed.
Or if I'm wrong about the timestamp being part of the computed checksum: add a space to your commit message. Very simple.
Yeah, the non-malicious failure mode is extremely reasonable, and overall I think it's a good choice... minus not building in support for changing the algorithm from the beginning. Checksum algorithms somewhat regularly need changing. This was completely foreseeable.
The malicious failure modes... I don't know. No doubt something is possible, particularly when you account for common surrounding-system usage patterns.
> A… sneaky trick that Linus pulled… was to just pretend like Sha1 hashes never collide. This (false but convenient) assumption…
As an infosec engineer, this is a bit disingenuous. From a statistical perspective, you can pretty much assume that it's impossible to create colliding SHA-1 hashes.
In the intervening years we've discovered security flaws in SHA-1 that allow attackers to create collisions under certain circumstances. That's not great, and now we have ways to migrate repositories to SHA-256 hashes (although it's not yet the default).
But this decision wasn't "sneaky". Cryptographers everywhere routinely build systems under the assumption that hash collisions can't happen, because that's an explicit design goal of hash functions. If we ever find a way that this doesn't hold true, the answer isn't to design the system around the possibility of a collision, it's to switch to a better hash.
Have hash collisions in Git ever been a problem for you?
What is the exact scenario in which a hash collision would be dangerous? (Like, you give some random person push access to your repository and... I'm really getting lost here... they override some commit with a different commit with the same hash? And that's somehow worse than them just creating a new commit with a different hash, which you would notice for sure? And the only reason you won't notice their Evil Change is because they sneaked it in inside a hash collision?)
We don't know how to push bad artifacts into a Merkle tree by exploiting SHA-1's weaknesses. The thing is, though, we didn't want to be pushed into scrambling for a better hash algorithm after some clever bastard works that trick out. :)
It appears that git currently has experimental, non-backward-compatible support for sha256, so I'd guess "as soon as they finish fixing any issues and figure out a nice upgrade path", with the caveat that there's little pressure because it's not actually a practical problem yet and isn't expected to be one in the foreseeable future.
My prediction, tangentially: The next evolution over Git will happen at GitHub.
GitHub (and to a much lesser extent, GitLab) is really what allows Git to monopolize the VCS landscape these days, and it's been true almost from the start. GitHub was really Git's killer app; before it was popular, there was still uncertainty about whether the winner of the VCS wars would be Git, or Mercurial, or Bazaar, or whatever. GitHub was what helped Git win that war.
Nobody will be able to break Git's hold over the world except GitHub itself, unless they are able to disrupt GitHub entirely. The player in the best position to do so is Microsoft. They can sneakily launch a competing version (without cannibalizing their own product) within GitHub itself, allowing repos to be selectively "upgraded" to it, and even two-way-mirrored so that Git users can continue to use it until they're ready to migrate.
I think Git will relatively easy to disrupt on technological merits as we slowly (very slowly!) move away from old ways of doing things. The current development cycle where individual developers hack away at their local repo and then submit patches already seems antiquated; meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way?
The other trend we see is the need for code collaboration tools to become more integrated. Git is essentially a glorified file system that happens to have good undo and diffing tools, and the workflows around building, testing, project management, etc. are comparatively primitive for what we developers actually need. For example, right now I do commits locally, then push to a branch, create a PR, and wait for it to build and run tests, then look at the failures, and go back, do some more commits, and rinse and repeat. Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes?
In particular, we see tools winning over other tools when they reduce friction. I think that's where the next iteration of version control and code collaboration tools will find its way in.
>meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way?
It's bad enough for anything but some quick notes, but it sounds like a nightmare for code.
>Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes?
Nobody stops you from auto saving and running a build every time a files change (I actually did this for my thesis in Latex). IMO this has nothing to do with Git.
Of course you can automatically trigger builds on save; my point is that there's an entire shift in thinking that's possible if we treat development as less of a sequence of discrete "stop the world" actions and more as a continuous loop.
As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality.
It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
>As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality.
That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say.
>It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.
If the other SCM is compatible with Git, you may not have to learn much about Git. That's my hope for my SCM: https://github.com/martinvonz/jj. I agree that it seems very hard for a new SCM to get many users without having good compatibility with Git.
and "Conflicts can be recorded in commits", e.g. for starting resolving a merge at home, continuing in the afternoon at the co-working space, a different laptop.
`jj edit` and `describe` looks like things I'd use a lot.
Nice with Rust and Nix (Hi Martin I'm Magnus from Gbg btw :- ))
`jj st` — nice naming. I've named my scripts directory just 's', since, typing is not that fun
What was the impetus that inspired Fossil? Reading through the article and the links from it, I get the impression that this was created for ideological reasons rather than a technical need.
I do appreciate them being upfront about not supporting rebasing, as it saves me the time I might have otherwise wasted in trying it out.
Fossil creator here: Fossil was created for one purpose - to support the development of SQLite, a job at which it has been successful beyond all expectation. Any other use of Fossil (and there is a lot of that, though still a lot less than there is for Git) is just gravy.
Fossil was designed to support the SQLite workflow. Git was designed to support the Linux Kernel workflow. Both systems seem amazingly well-suited for the projects for which they were designed.
Should you use Fossil or Git on your project? I suppose that depends a lot on whether your project workflow more closely matches the Linux Kernel or SQLite. There are other considerations, but I think that is the main differentiator of the two systems.
Side note: I've had a lot of help writing Fossil over the past 15 years, and especially a lot of help on the documentation. The article being discussed by this thread originated with me, but has been extensively edited by others with different ideas about the advantages and disadvantages of Fossil vs. Git. See https://fossil-scm.org/home/finfo/www/fossil-v-git.wiki?ubg for a complete timeline of changes to that one file, color-coded by committer. (BTW: Can Git or GitHub generate such a timeline?) My color is brown. If you scroll through the history, you can see that most of the edits to the article are by others. Which is fine. Just don't attribute everything you read there to me.
Thanks for your efforts! Both SQLite and Fossil are brilliant products. Fossil may not meet everyone's needs but its a great tool to be aware of as an option.
git workflows typically involve an engineer working on a branch, adding commits, then making a PR which then gets reviewed and (in most companies) squashed down to a single commit and merged to main.
Fossil doesn't support rebasing so the squashing isn't possible and I'm not sure the pull request concept is either. How do code reviews work with Fossil? Is this back to the svn days when everyone just made YOLO commits straight to trunk? I either don't get it or this seems like a huge step backwards.
From what I understand, Fossil was designed for single developers or small teams where all developers are trusted to push directly to the trunk. In other words, the model used by sqlite (the same person made both).
It's probably possible to set up a pull/merge request workflow in fossil, but that isn't what it was designed for
I am possibly very ignorant to realise the value of yet another SCM and I wasnt even sure why being written in C was a feature (or even if it is a single binary). I mean I get why those are good things for the right systems but for an SCM? Sure going over a lot of files and computing hashses and diffs etc - we have lang servers you talk to over some kind of RPC in an IDE - so computing hashes/diffs alone(?) being a reason for C-devel - does it hold water?
Having said that what made me pause to take a second look (pardon the superficiality) was the involvement by Dr Richard Hipp (sqlite). I mean there has gotta be something to it right?
ultra-summary: they had specific needs for SQLite development, and nothing else was addressing them. It was _not_ intended to solve anyone else's problems. It's _probably_ not the right solution for _most_ devs.
Is there anything like Fossil — with a built in ticket tracker — but that does not remember exactly what I did? But instead focuses on a nice looking history?
Hmm but after having websearched for "fossil ticket site:news.ycombinator.com", not sure if I really want a built in ticket tracker. Also, seems Fossil remembers and redistributes all old revisions of tickets and comments — including typos and angry words or ... accidentally copyrighted material? someone might have added, not sure if I like that
Any thougts about Fossil's ticket tracker? (Anyone has used it?)
73 comments
[ 0.12 ms ] story [ 117 ms ] threadWhy I'm using Fossil SCM instead of other source control systems (2016) - https://news.ycombinator.com/item?id=31634560 - June 2022 (127 comments)
Fossil - https://news.ycombinator.com/item?id=30815693 - March 2022 (131 comments)
Fossil versus Git - https://news.ycombinator.com/item?id=30404112 - Feb 2022 (5 comments)
Git vs. Fossil: what you should have done vs. what you did - https://news.ycombinator.com/item?id=27736980 - July 2021 (127 comments)
Fossil - https://news.ycombinator.com/item?id=24643200 - Sept 2020 (109 comments)
Fossil vs Git - https://news.ycombinator.com/item?id=19006036 - Jan 2019 (247 comments)
Fossil – High-reliability, distributed software configuration management system - https://news.ycombinator.com/item?id=17246044 - June 2018 (7 comments)
Fossil versus Git - https://news.ycombinator.com/item?id=17235150 - June 2018 (1 comment)
Fossil – A high-reliability distributed software configuration management system - https://news.ycombinator.com/item?id=17230766 - June 2018 (40 comments)
The Fossil distributed version control system - https://news.ycombinator.com/item?id=16838207 - April 2018 (52 comments)
Fossil – Next Generation - https://news.ycombinator.com/item?id=15752725 - Nov 2017 (123 comments)
Fossil SCM - https://news.ycombinator.com/item?id=13668952 - Feb 2017 (144 comments)
Fossil: A decentralized version control, bug tracking, and wiki software - https://news.ycombinator.com/item?id=12673229 - Oct 2016 (98 comments)
Has anyone tried the Fossil SCM? What's your opinion? - https://news.ycombinator.com/item?id=11934336 - June 2016 (3 comments)
Fossil SCM keeps more than just your code - https://news.ycombinator.com/item?id=10737131 - Dec 2015 (90 comments)
Fossil – Simple, high-reliability, distributed software configuration management - https://news.ycombinator.com/item?id=8697028 - Dec 2014 (84 comments)
Fossil SCM 1.23 released - https://news.ycombinator.com/item?id=4357107 - Aug 2012 (2 comments)
Fossil Versus Git - https://news.ycombinator.co...
The major competitor to git is mercurial, and while git has won the popularity contest mercurial is still in use across large projects.
Java/openjdk moved from mercurial to git in the 2021 time frame.
I don't believe fossil has ever been used on a scale as large as openjdk from an organizational point of view (thousands of participants in the ecosystem, across dozens of jdk implementations, across more than a dozen hardware platforms, etc)
Fossil as used in sqlite vs mercurial/git openjdk repos as used across the java ecosystem - I think java is one of the projects where platform support is at least as wide as sqlite, if not greater, and the codebase is much larger and more sprawling.
Facebook has moved on from mercurial as well, and it's not to fossil.
Fossil is a great tool, but seeing it as "one or the other" vs git isn't useful.
In particular, this guide on the fossil website is a guide for users wanting to use fossil, so git is not the only competitor, but for the purposes of fossil adopters, that web page is a great resource!
https://github.com/facebookexperimental/eden
[1]: https://en.wikipedia.org/wiki/List_of_version-control_softwa...
[0]: https://pijul.org/
Edit: Correcting myself (and go do your own research, I'm not even remotely involved in any of these things):
> Darcs 2 recently [2020] solved the exponential merge, but it is now quadratic (which is still exponentially slower than Pijul instead of double-exponentially)
https://news.ycombinator.com/item?id=25473473
Thanks, you successfully blew my mind today when I searched what this was, and learned what it was. I can't believe I've been missing out on this.
I have an application for this command today in a work project that will allow me to leave work early, so thanks for the early weekend!
Also, if you're unlucky enough to be using an IDE that doesn't always handle large codebase changes well (e.g., let's say... Xcode), then you've eliminated that problem too.
Some days you work with v1 and some days with v2, and sometimes with main. Sometimes fixes are quick, sometimes not. Sometimes you must switch the working branch while you are in the middle of doing something that is not quite finished.
If you need to change between v1, v2 or main, just change a directory. Done.
So for the above example, setting up this:
I.e. having a separate worktree for each long running branch makes working with the branches so much easier.Edit: formatting
Honestly, some images of Fossil's UI would be very nice.
One thought: What's now making Git super-powerful is that every IDE that I use has halfway-decent support for Git. I can view a diff of my changes and commit without leaving the IDE. Do any major IDEs integrate with Fossil?
You may find the article of some interest, since it summarizes one common use case for Fossil.
But more importantly, things like side-by-side screenshots of Gitlab / Github / Fossil of major features will also be immensely helpful. I'm thinking of things like pull requests, ticket trackers, ect.
> I feel like an SCM would have to be WAY better than git to make it worth using. The entire developer community is on git, so you are still going to have to know how to use git in order to access other open source projects. If you are already going to have to be using git for many things, why add a second SCM you have to learn to use?
If I'm having to give up CI, or hand-roll my own pipeline system completely from scratch, then that's just an unacceptable trade-off. For a personal toy project, fine. But this seems like ridiculous bikeshedding for a professional shop in the 2020's. "Without needing to check the manual every time"? Sheesh, there are really only a few Git commands that most developers ever have to run on a regular basis anyway, and usually an IDE abstracts those.
Theoretically, it might be easier to weave your own cloth and then tailor pants from scratch, if you use some novel synthetic fiber rather than cotton. But I don't want to weave my own cloth and tailor my own pants, so I wear cotton blue jeans.
I'm not sure exactly what you mean by "what you actually worked on". If you want the files that changed a git diff between the tip of your branch and merge base of the target branch is usually sufficient.
> and git log is A. not easy to consume
You can customize the log format to make it easier to consume
> B. unreliable since git has so many methods to rewrite history.
I'm not sure what that has to do with CI/CD. But if that is somehow a problem for you, then just don't allow rewriting history. Every git server software I'm aware of supports rejecting pushes that rewrite history.
That's how Git overthrew SVN. Cheap branching, robust conflict management, and offline workflows were killer features. Throw in Github, which is more accessible and lower friction than emailing patches and lurking on mailing lists, and SVN's fate was sealed.
I have actually searched for collisions by hashing several tens of millions of files with various hashes.
With shorter hashes I have seen collisions, but even with an 128-bit good hash there were no collisions, much less with an 160-bit hash.
Unless you hash many billions of things, the chances of SHA-1 collisions are negligible.
Which doesn't mean it's currently risky, I'm not sure how you'd turn a collision into an attack without leaning on external systems (like code review that approves by SHA, and allows you to push later). But if MD5's history is any clue, that will not be true in the long run.
The time to begin moving to a new algorithm was several years ago, when those collisions were demonstrated. Git is unambiguously lagging behind basic security practices here, though that's likely currently fine. The question is for how long that will remain true, and that's something that can only be answered after it has already become unsafe.
Or if I'm wrong about the timestamp being part of the computed checksum: add a space to your commit message. Very simple.
The malicious failure modes... I don't know. No doubt something is possible, particularly when you account for common surrounding-system usage patterns.
As an infosec engineer, this is a bit disingenuous. From a statistical perspective, you can pretty much assume that it's impossible to create colliding SHA-1 hashes.
In the intervening years we've discovered security flaws in SHA-1 that allow attackers to create collisions under certain circumstances. That's not great, and now we have ways to migrate repositories to SHA-256 hashes (although it's not yet the default).
But this decision wasn't "sneaky". Cryptographers everywhere routinely build systems under the assumption that hash collisions can't happen, because that's an explicit design goal of hash functions. If we ever find a way that this doesn't hold true, the answer isn't to design the system around the possibility of a collision, it's to switch to a better hash.
How long is it going to take Git to follow?
What is the exact scenario in which a hash collision would be dangerous? (Like, you give some random person push access to your repository and... I'm really getting lost here... they override some commit with a different commit with the same hash? And that's somehow worse than them just creating a new commit with a different hash, which you would notice for sure? And the only reason you won't notice their Evil Change is because they sneaked it in inside a hash collision?)
Nobody will be able to break Git's hold over the world except GitHub itself, unless they are able to disrupt GitHub entirely. The player in the best position to do so is Microsoft. They can sneakily launch a competing version (without cannibalizing their own product) within GitHub itself, allowing repos to be selectively "upgraded" to it, and even two-way-mirrored so that Git users can continue to use it until they're ready to migrate.
I think Git will relatively easy to disrupt on technological merits as we slowly (very slowly!) move away from old ways of doing things. The current development cycle where individual developers hack away at their local repo and then submit patches already seems antiquated; meanwhile, teams are collaborating in realtime in apps like Google Docs, Notion, Figma, Miro, etc. We have already started expecting our collaboration tools to be "live". Why shouldn't code be the same way?
The other trend we see is the need for code collaboration tools to become more integrated. Git is essentially a glorified file system that happens to have good undo and diffing tools, and the workflows around building, testing, project management, etc. are comparatively primitive for what we developers actually need. For example, right now I do commits locally, then push to a branch, create a PR, and wait for it to build and run tests, then look at the failures, and go back, do some more commits, and rinse and repeat. Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes?
In particular, we see tools winning over other tools when they reduce friction. I think that's where the next iteration of version control and code collaboration tools will find its way in.
Visual Studio Code Live Share is a precursor for this.
It's bad enough for anything but some quick notes, but it sounds like a nightmare for code.
>Why can't the build happen while I'm writing the code, so that I have instant feedback rather than having to go through these manual, multi-step processes?
Nobody stops you from auto saving and running a build every time a files change (I actually did this for my thesis in Latex). IMO this has nothing to do with Git.
As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality.
It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say.
>It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be.
I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.
jj's Automatic Rebase and rewriting history support look lovely ( https://github.com/martinvonz/jj#comprehensive-support-for-r... )
and "Conflicts can be recorded in commits", e.g. for starting resolving a merge at home, continuing in the afternoon at the co-working space, a different laptop.
`jj edit` and `describe` looks like things I'd use a lot.
Nice with Rust and Nix (Hi Martin I'm Magnus from Gbg btw :- ))
`jj st` — nice naming. I've named my scripts directory just 's', since, typing is not that fun
I do appreciate them being upfront about not supporting rebasing, as it saves me the time I might have otherwise wasted in trying it out.
Fossil was designed to support the SQLite workflow. Git was designed to support the Linux Kernel workflow. Both systems seem amazingly well-suited for the projects for which they were designed.
Should you use Fossil or Git on your project? I suppose that depends a lot on whether your project workflow more closely matches the Linux Kernel or SQLite. There are other considerations, but I think that is the main differentiator of the two systems.
Side note: I've had a lot of help writing Fossil over the past 15 years, and especially a lot of help on the documentation. The article being discussed by this thread originated with me, but has been extensively edited by others with different ideas about the advantages and disadvantages of Fossil vs. Git. See https://fossil-scm.org/home/finfo/www/fossil-v-git.wiki?ubg for a complete timeline of changes to that one file, color-coded by committer. (BTW: Can Git or GitHub generate such a timeline?) My color is brown. If you scroll through the history, you can see that most of the edits to the article are by others. Which is fine. Just don't attribute everything you read there to me.
Fossil doesn't support rebasing so the squashing isn't possible and I'm not sure the pull request concept is either. How do code reviews work with Fossil? Is this back to the svn days when everyone just made YOLO commits straight to trunk? I either don't get it or this seems like a huge step backwards.
It's probably possible to set up a pull/merge request workflow in fossil, but that isn't what it was designed for
Having said that what made me pause to take a second look (pardon the superficiality) was the involvement by Dr Richard Hipp (sqlite). I mean there has gotta be something to it right?
There's a good high level description by Richard Hipp of why they built it in this interview episode of Corecursive: https://corecursive.com/066-sqlite-with-richard-hipp/
Hmm but after having websearched for "fossil ticket site:news.ycombinator.com", not sure if I really want a built in ticket tracker. Also, seems Fossil remembers and redistributes all old revisions of tickets and comments — including typos and angry words or ... accidentally copyrighted material? someone might have added, not sure if I like that
Any thougts about Fossil's ticket tracker? (Anyone has used it?)