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.
> 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).
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.