3 ms·
If you've ever lived in a world of stacked commits with develop on main (i.e. not gitflow, no feature branches), combined with code review for every commit, git
by barrkel 1y ago
If you've ever lived in a world of stacked commits with develop on main (i.e. not gitflow, no feature branches), combined with code review for every commit, git will soon start to aggravate you. Git doesn't make rebasing a chain or tree of commits pleasant. Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases, making them more repetitive and tedious than they should be. When you address comments on earlier commits in a chain, you need to rebase after. Git's affordances for rebasing aren't great.
And when you rebase, the commits lose their identity since commit hashes are content-addressed, despite having an identity in people's minds - a new revision of a commit under review is usually logically the same unit of change, but git doesn't have a way of expressing this.
jj, as I understand it, addresses these pains directly.
- 1718627440 1y ago> Git records merge resolutions and can reuse them, but it doesn't do the same thing for rebases Since when does rerere not work with rebase anymore?
- tcoff91 1y agoI think it does but rerere is not nearly as good as first class conflicts in jj
- 1718627440 1y agoOk, but by that measure, >> Git records merge resolutions isn't true either.
- Izkata 1y ago> Git doesn't make rebasing a chain or tree of commits pleasant. There's a semi-recent addition that makes it a single command, the --update-refs flag to rebase (along with the --rebase-merges flag, formerly called --preserve-merges).
- 1718627440 1y ago> Any branches that are checked out in a worktree are not updated in this way. Would be nice, if it would also have a flag to choose that behaviour.
- waych 1y agoFWIW git-branchless, an extension to git, addresses many of these points without leaving git.