5 ms·

It's not fair to complain about how hard a tool is to use without comparing it to the alternatives. If git is a failure as claimed then the alternatives should

It's not fair to complain about how hard a tool is to use without comparing it to the alternatives. If git is a failure as claimed then the alternatives should be better, no? We have a list of known version control software [0], how many of these are better than git and how many are worse? I've heard Mercurial and Fossil are pretty good but I still haven't been pressured to give them a try. However, most of that list is filled with software people hated enough to ditch for git. I think it's very likely that git is solving a problem hard enough that it can't be simplified much further. If it can be simplified, I would expect to hear a growing minority of users pushing for people to switch to the next system. [0]: https://en.wikipedia.org/wiki/Comparison_of_version-control_software https://en.wikipedia.org/wiki/Comparison_of_version-control_...

guitarbill 6y ago
Mercurial sounds great, and ostensibly has less foot cannons... unless you use Mercurial Queues. I've learned to live with git, just like I have with English. It isn't perfect, but a lingua franca is useful, and it isn't so bad. If git is the worst part of your CI/CD workflow, that's a pretty good problem to have.
- bsder 6y ago
  And "Mercurial Queues" primarily exists because of people incessantly bitching about the lack of "git rebase" in Mercurial. So, what does that say about the original feature from git that implementing it created a ton of footguns into a revision control system that didn't have them before?
  - nemetroid 6y ago
    The original feature doesn’t have footguns, so what does it say? I’m genuinely curious.
  - atq2119 6y ago
    Considering that rebasing is a crucial feature of version control, it seems to say that there is inherent complexity in distributed version control. By virtue of being honest about the problem space and giving central importance to the inherent concepts, Git is probably the best existing solution, even if it's not necessarily the best possible solution.
    - bsder 6y ago
      > Considering that rebasing is a crucial feature of version control "Rebasing" is NOT a crucial feature. "Commit history" being immutable is an equally valid axiom. "Rebase" is an architectural feature of git that matches the organization structure of the Linux kernel (individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus) by virtue of Conway's Law. I would posit that most development teams would be much better served never squashing commit messages. Too many groups incur the complexity of rebase without having any reason for doing so.
      - guitarbill 6y ago
        MQ is not just rebase. for example, it's a common way to integrate with code review tools. you might want to put out several commits as one CR (to make reviewing easier). then you want to fix up some feedback, i.e. rewrite history (note this also doesn't necessarily mean squashing when merging into the main branch). i think it's fair to say the committed history shouldn't change (even just on the main branch), and most (?) git servers support this. but ignoring the need for this/ignoring the distributed nature of version control will lead to hacks like MQ. rebase is flexible and allows this.
      - atq2119 6y ago
        > individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus This is not how Linux kernel development works. Instead, once a series of patches has been reviewed and accepted by the first maintainer, there will be no more rebasing -- the commits will eventually flow into Linus' copy via pull requests that are reflected in the DAG as merge commit. The point here is that the kernel actually does code review, and commits often go through several versions before being accepted. That's where `git rebase` comes in, because as a developer, you need it during this revision process as you amend and fixup the individual commits of the patch series that you're working on. Of course, if you don't do proper code reviews on your projects, and/or you're sloppy with how changes make it into the code base, then you may get away without using `git rebase`. That may be acceptable for smaller projects, or perhaps for larger projects that are easier to test; and larger commercial projects may be able to afford the cost of papering over the inefficiencies that come with a sloppy review and development process. But it's just not feasible for something like the Linux kernel, and so `git rebase` really is essential.
- altfredd 6y ago
  In my experience, descriptions of the so-called "foot cannons" within Git are exaggerated by people, who don't understand Git and didn't use it much. It is virtually impossible to lose data, committed to Git. Between reflog, lazy garbage collection and ability to grep history for strings there is literally no way to corner yourself. I have never lost anything after years of using Git. Meanwhile, I have lost data at least once with most conventional filesystems and storage mediums: f2fs, ext4, ntfs, hard drives, SSDs, CDs, VHS tapes... Incidentally, when I tried to use Mercurial once (because the job demanded it) and immediately went for Mercurial Queues, the bug in implementation of Queues caused me to actually lose some data (an insignificant amount, but still!). Unstable internal storage format + implementing history editing via third-party tool = bad news.
eindiran 6y ago
Notably Mercurial and Fossil are also distributed; they differ a bit in how complex they are, what they allow you to do, which tools are bundled in, etc, but ultimately any of the DVCSes is going to be lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes. Regarding your point about git being unable to be further simplified, I think Mercurial demonstrates that that isn't true; it sacrifices some coverage of the edge cases to get a significantly simpler interface.
- jjav 6y ago
  > lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes git and mercurial both came out at the same time, April 2005. But neither was the first distributed scs by a very long shot. There was of course bitkeeper (which motivated git) and Sun's teamware was there all of the 90s. Surely several others.
  - fanf2 6y ago
    There was GNU arch / tla https://en.wikipedia.org/wiki/GNU_arch https://en.wikipedia.org/wiki/GNU_arch and monotone https://en.wikipedia.org/wiki/Monotone_(software) https://en.wikipedia.org/wiki/Monotone_(software)
jen20 6y ago
BitKeeper solves the same problems as Git with a _far_ more sane user interface. My personal opinion is that it's best in class. The thing Git has going for it (over BitKeeper or really anything else) is GitHub. If we had something like BitHub that were widely used instead, I don't think I would bother with Git for anything except contributions to projects using it, despite being a fairly advanced Git user through necessity.
- yencabulator 6y ago
  The thing Git has going over BitKeeper is that people are allowed to use Git. Larry revoked the license of some key developers, and if he hadn't done that, Git wouldn't probably even exist.

guitarbill 6y ago

Mercurial sounds great, and ostensibly has less foot cannons... unless you use Mercurial Queues. I've learned to live with git, just like I have with English. It isn't perfect, but a lingua franca is useful, and it isn't so bad. If git is the worst part of your CI/CD workflow, that's a pretty good problem to have.

bsder 6y ago
And "Mercurial Queues" primarily exists because of people incessantly bitching about the lack of "git rebase" in Mercurial. So, what does that say about the original feature from git that implementing it created a ton of footguns into a revision control system that didn't have them before?
- nemetroid 6y ago
  The original feature doesn’t have footguns, so what does it say? I’m genuinely curious.
- atq2119 6y ago
  Considering that rebasing is a crucial feature of version control, it seems to say that there is inherent complexity in distributed version control. By virtue of being honest about the problem space and giving central importance to the inherent concepts, Git is probably the best existing solution, even if it's not necessarily the best possible solution.
  - bsder 6y ago
    > Considering that rebasing is a crucial feature of version control "Rebasing" is NOT a crucial feature. "Commit history" being immutable is an equally valid axiom. "Rebase" is an architectural feature of git that matches the organization structure of the Linux kernel (individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus) by virtue of Conway's Law. I would posit that most development teams would be much better served never squashing commit messages. Too many groups incur the complexity of rebase without having any reason for doing so.
    - guitarbill 6y ago
      MQ is not just rebase. for example, it's a common way to integrate with code review tools. you might want to put out several commits as one CR (to make reviewing easier). then you want to fix up some feedback, i.e. rewrite history (note this also doesn't necessarily mean squashing when merging into the main branch). i think it's fair to say the committed history shouldn't change (even just on the main branch), and most (?) git servers support this. but ignoring the need for this/ignoring the distributed nature of version control will lead to hacks like MQ. rebase is flexible and allows this.
    - atq2119 6y ago
      > individual maintainers squash the detail of the commits as it passes up through developer->Maintainer A->Uber Maintainer B->Super Uber Maintainer C->Linus This is not how Linux kernel development works. Instead, once a series of patches has been reviewed and accepted by the first maintainer, there will be no more rebasing -- the commits will eventually flow into Linus' copy via pull requests that are reflected in the DAG as merge commit. The point here is that the kernel actually does code review, and commits often go through several versions before being accepted. That's where `git rebase` comes in, because as a developer, you need it during this revision process as you amend and fixup the individual commits of the patch series that you're working on. Of course, if you don't do proper code reviews on your projects, and/or you're sloppy with how changes make it into the code base, then you may get away without using `git rebase`. That may be acceptable for smaller projects, or perhaps for larger projects that are easier to test; and larger commercial projects may be able to afford the cost of papering over the inefficiencies that come with a sloppy review and development process. But it's just not feasible for something like the Linux kernel, and so `git rebase` really is essential.
altfredd 6y ago
In my experience, descriptions of the so-called "foot cannons" within Git are exaggerated by people, who don't understand Git and didn't use it much. It is virtually impossible to lose data, committed to Git. Between reflog, lazy garbage collection and ability to grep history for strings there is literally no way to corner yourself. I have never lost anything after years of using Git. Meanwhile, I have lost data at least once with most conventional filesystems and storage mediums: f2fs, ext4, ntfs, hard drives, SSDs, CDs, VHS tapes... Incidentally, when I tried to use Mercurial once (because the job demanded it) and immediately went for Mercurial Queues, the bug in implementation of Queues caused me to actually lose some data (an insignificant amount, but still!). Unstable internal storage format + implementing history editing via third-party tool = bad news.

eindiran 6y ago

Notably Mercurial and Fossil are also distributed; they differ a bit in how complex they are, what they allow you to do, which tools are bundled in, etc, but ultimately any of the DVCSes is going to be lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes. Regarding your point about git being unable to be further simplified, I think Mercurial demonstrates that that isn't true; it sacrifices some coverage of the edge cases to get a significantly simpler interface.

jjav 6y ago
> lightyears ahead of the pre-Git (pre-Mercurial? I'm not sure which came first) client-server VCSes git and mercurial both came out at the same time, April 2005. But neither was the first distributed scs by a very long shot. There was of course bitkeeper (which motivated git) and Sun's teamware was there all of the 90s. Surely several others.
- fanf2 6y ago
  There was GNU arch / tla https://en.wikipedia.org/wiki/GNU_arch https://en.wikipedia.org/wiki/GNU_arch and monotone https://en.wikipedia.org/wiki/Monotone_(software) https://en.wikipedia.org/wiki/Monotone_(software)

jen20 6y ago

BitKeeper solves the same problems as Git with a _far_ more sane user interface. My personal opinion is that it's best in class. The thing Git has going for it (over BitKeeper or really anything else) is GitHub. If we had something like BitHub that were widely used instead, I don't think I would bother with Git for anything except contributions to projects using it, despite being a fairly advanced Git user through necessity.

yencabulator 6y ago
The thing Git has going over BitKeeper is that people are allowed to use Git. Larry revoked the license of some key developers, and if he hadn't done that, Git wouldn't probably even exist.