3 ms·

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 o

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.

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.