8 ms·

I'm surprised git caught on despite mercurial being much superior (hadn't heard of fossil before). Git has the following shortcomings which are major (some shar

by fxfan 8y ago

I'm surprised git caught on despite mercurial being much superior (hadn't heard of fossil before). Git has the following shortcomings which are major (some shared by other VCS too) 1) UI- terrible, terrible UI 2) Unncessarily complex data model 3) Doesn't scale well to large repos (until Microsoft's VFS- windows only) (and many others...)

rco8786 8y ago
> Unncessarily complex data model The git data model is certainly complex, but I'd be curious to hear why you think it's 'unnecessarily' so. I often try and drum up a new SCM in my head and the data model gets pretty complex every time.
sigzero 8y ago
Fossil is made by the same gentleman (D. Richard Hipp) that gave us SQLite.
- gjvc 8y ago
  $ fossil init wibble project-id: c8d025508afd55c31cebedfe244a3b62f39fb6eb server-id: 8b340295f8268f742f91c5e972195efc0c6e578f admin-user: gjvc (initial password is "c5d7ba") $ file wibble wibble: SQLite 3.x database (Fossil repository), last written using SQLite version 3026000
- jpeeler 8y ago
  Yes indeed, and he comments here as "SQLite".
ethelward 8y ago
To give a personal, subjective point of view of why I switched from hg to git: - hg was horribly slow compared to git; - I love the branchs model used in git to let several persons work on different parts of the same project, and I could never find a satisfactory equivalent using hg idiomatisms. It is true that hg has a far better UI in general, but Magit fixes this problem for me.
- sirn 8y ago
  To add more praises about Magit: I would really love to use other DVCS, especially Fossil because it has built-in issue tracker and Wiki and all, but to be unable to use Magit with Fossil is a bigger drawback for me to make a switch. At this point, I can basically do most of Git commands in Magit with just muscle memory; say, stage everything in the tree, commit amend, reset author and dates, then force push (I know) to remote I would just press with evil-magit: <SPC>gsSc-Racp-fpy (<SPC>gs for invoking Magit, S to stage everything, c to enter commit mode, -R set the reset author flag, a amend commit, p enter push mode, -f set the force flag, p push to origin, y confirm force push) It may sounds complicated, but the Magit UI is discoverable, and once you're used to it you can do anything without even looking at the UI...
- rkangel 8y ago
  The UI thing is more than superficial though. Yes, the command line is horribly inconsistent (and that can be fixed with Magit), but the real issue is that if you want to do anything non-trivial you have to understand how git works - what the object model is, how refs work etc. I used mercurial successfully, quite heavily, and I couldn't tell you much about how it's implemented.
Chyzwar 8y ago
1) It is not beginners friendly but for day to day dev you only need to understand few commands. 2) Data model brings speed that was not possible before. git won VCS space because of sheer performance. 3) Scale just fine. Just windows have a really bad filesystem and Windows codebase is the pathologic case.
- fxfan 8y ago
  I am not a beginner and not trying to boast but pretty smart and experienced. The problem is that the edge cases that come up have solutions which need to be looked up- not derived from understanding. And when you're scared of data loss, its a very frustrating situation
  - palerdot 8y ago
    Interesting ... One sane thing about git is, it is very difficult to lose data. You have to work out of your way to lose data like delete your local and remote histories. Even if that is the case, if someone else has branched meanwhile, it can be restored without any fuss.
    - pseudalopex 8y ago
      Git makes it difficult to lose committed data. It's easy to lose uncommitted changes. Also, someone can know that changes are in the reflog but not how to recover them without making a bigger mess.
      - mewse 8y ago
        That's a really interesting criticism to make. Can you specify a version control system which doesn't make it easy to lose uncommitted changes?
        rejschaap 8y ago
        The other half of the story is that git also makes it easy to commit.
rndgermandude 8y ago
I dread every time I have to use hg (and when I can use the git bindings for it). And I was using hg before I was using git. git has a terrible UI, granted, but I find the hg UI pretty terrible too. I really hate their approach to branching (tho that is remedied these days with e.g. bookmarks to some extent). Speaking of data model, I find gits model to be a lot saner. I REALLY hate that hg spams my disk with tons and tons of files within the .hg directory. Ever cloned e.g. the mozilla hg repos? ugh. Bonus points for their fancy name escaping mechanism in those files, which had me run into "path too long" issues on windows boxes a couple of times already.
- cryptonector 8y ago
  Mercurial's bookmarks tend to get into a bad state for me. With Git it's trivial to fix things. With Mercurial I just can't figure anything out, and I think that's because Mercurial tries so hard to hide how things work and to tell me how I should do my work.
setquk 8y ago
4) lots of foot guns I would rather like a new option which was designed as a VCS from day one, that is user friendly and fast. Fossil is actually nearly there (I used it for a bit for some private projects)
donatj 8y ago
> 2) Unncessarily complex data model Hmm? It’s just a directed graph of SHA1s under the hood. Seems pretty simple to me once you understand that. My understanding was that Hg’s data model is actually way more complicated with more pointers. As everyone else is chiming in, the reason git won was speed. I haven’t used mercurial in a few years but at the time when I was looking to replace SVN, git did everything seconds faster than Hg which made it the clear winner.
- SQLite 8y ago
  Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_git_is_needlessly_complex https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...
  - jtms 8y ago
    All these concepts are extremely useful in practice. I do not see them in any way as “needlessly” complex. Difficult to learn... maybe, but not just for the hell of it.
  - BeetleB 8y ago
    Other than the staging area, hg has all of these.
  - cryptonector 8y ago
    The Git index is one of its most powerful features. Try doing a `git add -e` sometime. You get to do a bunch of work in the workspace then split it up usefully at commit time.
- pmoriarty 8y ago
  "the reason git won was speed" It wasn't just speed, it was also that the Linux kernel was developed under git, that Linus created git, and the existence of github, which a lot of people liked. After a while, it also just developed a critical mass where the attitude of people/companies that weren't using it almost inevitably became one of "everybody else is using git, so we should too".
rkangel 8y ago
Git won over Mercurial simply due to Github. There were some other minor contributing factors - association with Linus, speed - but they are insignificant compared to how popular Gihub was (for good reason) and therefore how many people were exposed to git. The Mercurial alternatives like bitbucket just didn't have the same spread, and we got stuck with year after year of teaching new people a difficult interface.
- kasey_junk 8y ago
  It’s even more specialized than that git one because github made public repos free & private repos paid. Bitbucket did the reverse. If not for that difference we’d all think of git as that bizarre source control Linus makes the Linux devs use.
- georgyo 8y ago
  Git won the war before GitHub existed. More projects were switching to git than hg. GitHub was then mirroring open source projects git repos without asking. (Which I think is fine, but ruffled some feathers back then) GitHub could have easily been hghub, but they targeted git because it was already winning.
  - pseudalopex 8y ago
    Git was more popular for C, Perl, and Ruby. Mercurial was more popular for Java and Python. It was far ahead on Windows. Google and Atlassian bet on Mercurial well after GitHub existed. The idea that only one could win would have been strange to a lot of people at the time.
- sys_64738 8y ago
  Linus definitely helped and he pretty much killed cvs (not the drug chain).
  - war1025 8y ago
    You mean git killed SVN right? SVN killed CVS in my understanding.
Illniyar 8y ago
It is rare that adaption has anything to do with the strength of the technology involved. Usually the winners are those that are early to market, are adapted early by industry leaders and/or have better marketing. In this case the reason is most definitely the fact that it used in Linux, easily one of the biggest open source projects ever. I would wager a guess that if Mercurial was created earlier, Git would probably never have been created, let alone be adapted for Linux.
- pseudalopex 8y ago
  Mercurial and Git started around the same time. Linus was concerned that Mercurial was similar enough to BitKeeper that BitMover might threaten anyone who worked on it or at least anyone who had used BitKeeper.
jeltz 8y ago
The simple data model is the best part of git so I have no idea what you are referring to. I do not see how one could make it any simpler and still use it to implement a DVCS. The main reasons I picked Git over Mercurial were the data model and the performance.
kyrra 8y ago
Re 2: HG doesn't have a published data model. I believe they have created 2 or 3 models at this point so far, but I happens under the hood. They can do this as there is only 1 implementation of HG, so no need to worry about compatible as much.
dan-robertson 8y ago
I think git and hg are both pretty bad in different ways. Both have pretty terrible UI but so long as one uses magit, git comes out way on top. The data models are different and suffer different problems. A main issue with git is that it is stupid about file copies and renames. An issue with hg is that it doesn’t work well with long running forked histories (i.e. like git branches) because it stores the set of revisions of a file as a list of blocks of “complete file” or “diff from previous version in this list” Both have scaling problems to large repos and algorithm/data structure problems which cause too many operations to be e.g. O(size of history) at least. I suppose this is better than Darcs’ model of “commit on Friday and hopefully it will be done by Monday.” If hg we’re naturally good at scaling than e.g. Facebook wouldn’t be putting so much effort into trying to make it scale (e.g. using inotify instead of looking throughout the tree for changes (which I think shouldn’t count as any vcs gains from this), having a mergeless history, rewriting a ton of hg in rust (git was always partly in C and there is now also libgit2)). The thing that makes me most sad about hg is the lack of a really good (ie good and emacs-based) ui. I’m all for different vc systems being developed and I think it would be good to see some real innovation potentially break up the current git-hg hegemony. I think there are lots of good things about fossil (e.g. using an actual database that is going to scale well and avoid data corruption instead of using a specialised data structure that is hard to change and likely not so corruption resistant or battle tested or scalable but maybe let’s your data structure be “faster” for certain operations) Another interesting vc system being developed at the moment is pijul which can be simply described as “like darcs but fast and more likely to be correct”. It feels a bit like it’s fitting in with the current trend of CRDTs, although it’s core data structure is not a CRDT as that would imply that all merges have some deterministic resolution (ie merge conflicts do not happen) and that is not the case, instead files are allowed to be merged into a first-class conflicted state which can then be resolved by later patches.
- u801e 8y ago
  > A main issue with git is that it is stupid about file copies and renames. Could you elaborate on this? As far as I know, file copies and renames will still use the same blob, but the tree referencing the blob can reference it using a different path in the case of a rename or reference it more than once in the case of a copy.
zaarn 8y ago
Git has the advantage of being the right kind of terrible. If you only push commits to a branch and use GUI tools like Github or Gitea for merging, chances are you're never going to be exposed to anything more complicated than 'add; commit; push'. Even merging isn't that terrible and while still being painful, git makes it somewhat clear what you want. The problem is; if you want people to use something else, you need to improve over git in the areas that matter to most people (ie, 'add; commit; push'). Git is terrible but just good enough that improvement over that terrible will be hard to accept for the mainstream.
jtms 8y ago
>Unnecessarily complex data model I have been using git since it was released and have never needed to think about its underlying data model in order to accomplish dev tasks. Also I suspect that any complexity in the data model was quite necessary to implement its api and features in a performant way.
cryptonector 8y ago
I'm not sure any VCS scales well to huge repos, and the MSFT work in this space is truly amazing. I love, for example, their use of a Bloom filter to make git blame fast! I actually like the git UI. Like many git power users, I've come to terms with a subset of the UI that I know how to use very well. The thinness of Git's abstractions lets me think of complex VCS operations as I do when reading or writing code. If the cognitive load is too high, you can always just use a merge-heavy workflow and stop thinking about the mechanics, but I recommend instead to understand the mechanics. The data model in Git is hardly more complex than Fossil's or Mercurial's, and it's copy-on-write all the way, which makes it very safe (think ZFS).
markmark 8y ago
"git caught on despite mercurial being much superior" mercurial wasn't superior.

by fxfan 8y ago

rco8786 8y ago

> Unncessarily complex data model The git data model is certainly complex, but I'd be curious to hear why you think it's 'unnecessarily' so. I often try and drum up a new SCM in my head and the data model gets pretty complex every time.

sigzero 8y ago

Fossil is made by the same gentleman (D. Richard Hipp) that gave us SQLite.

gjvc 8y ago
$ fossil init wibble project-id: c8d025508afd55c31cebedfe244a3b62f39fb6eb server-id: 8b340295f8268f742f91c5e972195efc0c6e578f admin-user: gjvc (initial password is "c5d7ba") $ file wibble wibble: SQLite 3.x database (Fossil repository), last written using SQLite version 3026000
jpeeler 8y ago
Yes indeed, and he comments here as "SQLite".

ethelward 8y ago

To give a personal, subjective point of view of why I switched from hg to git: - hg was horribly slow compared to git; - I love the branchs model used in git to let several persons work on different parts of the same project, and I could never find a satisfactory equivalent using hg idiomatisms. It is true that hg has a far better UI in general, but Magit fixes this problem for me.

sirn 8y ago
To add more praises about Magit: I would really love to use other DVCS, especially Fossil because it has built-in issue tracker and Wiki and all, but to be unable to use Magit with Fossil is a bigger drawback for me to make a switch. At this point, I can basically do most of Git commands in Magit with just muscle memory; say, stage everything in the tree, commit amend, reset author and dates, then force push (I know) to remote I would just press with evil-magit: <SPC>gsSc-Racp-fpy (<SPC>gs for invoking Magit, S to stage everything, c to enter commit mode, -R set the reset author flag, a amend commit, p enter push mode, -f set the force flag, p push to origin, y confirm force push) It may sounds complicated, but the Magit UI is discoverable, and once you're used to it you can do anything without even looking at the UI...
rkangel 8y ago
The UI thing is more than superficial though. Yes, the command line is horribly inconsistent (and that can be fixed with Magit), but the real issue is that if you want to do anything non-trivial you have to understand how git works - what the object model is, how refs work etc. I used mercurial successfully, quite heavily, and I couldn't tell you much about how it's implemented.

Chyzwar 8y ago

1) It is not beginners friendly but for day to day dev you only need to understand few commands. 2) Data model brings speed that was not possible before. git won VCS space because of sheer performance. 3) Scale just fine. Just windows have a really bad filesystem and Windows codebase is the pathologic case.

fxfan 8y ago
I am not a beginner and not trying to boast but pretty smart and experienced. The problem is that the edge cases that come up have solutions which need to be looked up- not derived from understanding. And when you're scared of data loss, its a very frustrating situation
- palerdot 8y ago
  Interesting ... One sane thing about git is, it is very difficult to lose data. You have to work out of your way to lose data like delete your local and remote histories. Even if that is the case, if someone else has branched meanwhile, it can be restored without any fuss.
  - pseudalopex 8y ago
    Git makes it difficult to lose committed data. It's easy to lose uncommitted changes. Also, someone can know that changes are in the reflog but not how to recover them without making a bigger mess.
    - mewse 8y ago
      That's a really interesting criticism to make. Can you specify a version control system which doesn't make it easy to lose uncommitted changes?
      - rejschaap 8y ago
        The other half of the story is that git also makes it easy to commit.

rndgermandude 8y ago

I dread every time I have to use hg (and when I can use the git bindings for it). And I was using hg before I was using git. git has a terrible UI, granted, but I find the hg UI pretty terrible too. I really hate their approach to branching (tho that is remedied these days with e.g. bookmarks to some extent). Speaking of data model, I find gits model to be a lot saner. I REALLY hate that hg spams my disk with tons and tons of files within the .hg directory. Ever cloned e.g. the mozilla hg repos? ugh. Bonus points for their fancy name escaping mechanism in those files, which had me run into "path too long" issues on windows boxes a couple of times already.

cryptonector 8y ago
Mercurial's bookmarks tend to get into a bad state for me. With Git it's trivial to fix things. With Mercurial I just can't figure anything out, and I think that's because Mercurial tries so hard to hide how things work and to tell me how I should do my work.

setquk 8y ago

4) lots of foot guns I would rather like a new option which was designed as a VCS from day one, that is user friendly and fast. Fossil is actually nearly there (I used it for a bit for some private projects)

donatj 8y ago

> 2) Unncessarily complex data model Hmm? It’s just a directed graph of SHA1s under the hood. Seems pretty simple to me once you understand that. My understanding was that Hg’s data model is actually way more complicated with more pointers. As everyone else is chiming in, the reason git won was speed. I haven’t used mercurial in a few years but at the time when I was looking to replace SVN, git did everything seconds faster than Hg which made it the clear winner.

SQLite 8y ago
Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_git_is_needlessly_complex https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...
- jtms 8y ago
  All these concepts are extremely useful in practice. I do not see them in any way as “needlessly” complex. Difficult to learn... maybe, but not just for the hell of it.
- BeetleB 8y ago
  Other than the staging area, hg has all of these.
- cryptonector 8y ago
  The Git index is one of its most powerful features. Try doing a `git add -e` sometime. You get to do a bunch of work in the workspace then split it up usefully at commit time.
pmoriarty 8y ago
"the reason git won was speed" It wasn't just speed, it was also that the Linux kernel was developed under git, that Linus created git, and the existence of github, which a lot of people liked. After a while, it also just developed a critical mass where the attitude of people/companies that weren't using it almost inevitably became one of "everybody else is using git, so we should too".

rkangel 8y ago

Git won over Mercurial simply due to Github. There were some other minor contributing factors - association with Linus, speed - but they are insignificant compared to how popular Gihub was (for good reason) and therefore how many people were exposed to git. The Mercurial alternatives like bitbucket just didn't have the same spread, and we got stuck with year after year of teaching new people a difficult interface.

kasey_junk 8y ago
It’s even more specialized than that git one because github made public repos free & private repos paid. Bitbucket did the reverse. If not for that difference we’d all think of git as that bizarre source control Linus makes the Linux devs use.
georgyo 8y ago
Git won the war before GitHub existed. More projects were switching to git than hg. GitHub was then mirroring open source projects git repos without asking. (Which I think is fine, but ruffled some feathers back then) GitHub could have easily been hghub, but they targeted git because it was already winning.
- pseudalopex 8y ago
  Git was more popular for C, Perl, and Ruby. Mercurial was more popular for Java and Python. It was far ahead on Windows. Google and Atlassian bet on Mercurial well after GitHub existed. The idea that only one could win would have been strange to a lot of people at the time.
sys_64738 8y ago
Linus definitely helped and he pretty much killed cvs (not the drug chain).
- war1025 8y ago
  You mean git killed SVN right? SVN killed CVS in my understanding.

Illniyar 8y ago

It is rare that adaption has anything to do with the strength of the technology involved. Usually the winners are those that are early to market, are adapted early by industry leaders and/or have better marketing. In this case the reason is most definitely the fact that it used in Linux, easily one of the biggest open source projects ever. I would wager a guess that if Mercurial was created earlier, Git would probably never have been created, let alone be adapted for Linux.

pseudalopex 8y ago
Mercurial and Git started around the same time. Linus was concerned that Mercurial was similar enough to BitKeeper that BitMover might threaten anyone who worked on it or at least anyone who had used BitKeeper.

jeltz 8y ago

The simple data model is the best part of git so I have no idea what you are referring to. I do not see how one could make it any simpler and still use it to implement a DVCS. The main reasons I picked Git over Mercurial were the data model and the performance.

kyrra 8y ago

Re 2: HG doesn't have a published data model. I believe they have created 2 or 3 models at this point so far, but I happens under the hood. They can do this as there is only 1 implementation of HG, so no need to worry about compatible as much.

dan-robertson 8y ago

I think git and hg are both pretty bad in different ways. Both have pretty terrible UI but so long as one uses magit, git comes out way on top. The data models are different and suffer different problems. A main issue with git is that it is stupid about file copies and renames. An issue with hg is that it doesn’t work well with long running forked histories (i.e. like git branches) because it stores the set of revisions of a file as a list of blocks of “complete file” or “diff from previous version in this list” Both have scaling problems to large repos and algorithm/data structure problems which cause too many operations to be e.g. O(size of history) at least. I suppose this is better than Darcs’ model of “commit on Friday and hopefully it will be done by Monday.” If hg we’re naturally good at scaling than e.g. Facebook wouldn’t be putting so much effort into trying to make it scale (e.g. using inotify instead of looking throughout the tree for changes (which I think shouldn’t count as any vcs gains from this), having a mergeless history, rewriting a ton of hg in rust (git was always partly in C and there is now also libgit2)). The thing that makes me most sad about hg is the lack of a really good (ie good and emacs-based) ui. I’m all for different vc systems being developed and I think it would be good to see some real innovation potentially break up the current git-hg hegemony. I think there are lots of good things about fossil (e.g. using an actual database that is going to scale well and avoid data corruption instead of using a specialised data structure that is hard to change and likely not so corruption resistant or battle tested or scalable but maybe let’s your data structure be “faster” for certain operations) Another interesting vc system being developed at the moment is pijul which can be simply described as “like darcs but fast and more likely to be correct”. It feels a bit like it’s fitting in with the current trend of CRDTs, although it’s core data structure is not a CRDT as that would imply that all merges have some deterministic resolution (ie merge conflicts do not happen) and that is not the case, instead files are allowed to be merged into a first-class conflicted state which can then be resolved by later patches.

u801e 8y ago
> A main issue with git is that it is stupid about file copies and renames. Could you elaborate on this? As far as I know, file copies and renames will still use the same blob, but the tree referencing the blob can reference it using a different path in the case of a rename or reference it more than once in the case of a copy.

zaarn 8y ago

Git has the advantage of being the right kind of terrible. If you only push commits to a branch and use GUI tools like Github or Gitea for merging, chances are you're never going to be exposed to anything more complicated than 'add; commit; push'. Even merging isn't that terrible and while still being painful, git makes it somewhat clear what you want. The problem is; if you want people to use something else, you need to improve over git in the areas that matter to most people (ie, 'add; commit; push'). Git is terrible but just good enough that improvement over that terrible will be hard to accept for the mainstream.

jtms 8y ago

>Unnecessarily complex data model I have been using git since it was released and have never needed to think about its underlying data model in order to accomplish dev tasks. Also I suspect that any complexity in the data model was quite necessary to implement its api and features in a performant way.

cryptonector 8y ago

I'm not sure any VCS scales well to huge repos, and the MSFT work in this space is truly amazing. I love, for example, their use of a Bloom filter to make git blame fast! I actually like the git UI. Like many git power users, I've come to terms with a subset of the UI that I know how to use very well. The thinness of Git's abstractions lets me think of complex VCS operations as I do when reading or writing code. If the cognitive load is too high, you can always just use a merge-heavy workflow and stop thinking about the mechanics, but I recommend instead to understand the mechanics. The data model in Git is hardly more complex than Fossil's or Mercurial's, and it's copy-on-write all the way, which makes it very safe (think ZFS).

markmark 8y ago

"git caught on despite mercurial being much superior" mercurial wasn't superior.