3 ms·

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.

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.

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.