I wish I had a better answer for you but my go-to solution as of late has been the pragmatic "I agree. Do you mind if I fix that in a later PR to avoid spending too much time on it?"

If you've built up some trust with your team, they shouldn't have a problem with it.

The linked tool git-branchless handles this pretty well (https://github.com/arxanas/git-branchless, I'm the author). You basically run `git checkout <branch>`, `git commit --amend`, and then `git restack`. This will rebase all dependent branches. As long as you're not using merge commits, you won't have to resolve the same conflict more than once. (It will also warn you up front whether or not merge conflicts will need to be resolved; you can pass `--merge` to start merge conflict resolution.)

To rebase your commit stack on top of the main branch, use `git sync` instead of `git merge`. Merge commits often make it so that you have to resolve conflicts multiple times.

Thanks this looks interesting, I will definitely give it a shot.

The best way I’ve found is to use atomic commits [0], or put simply have each commit do a single logical thing.

For example don’t mix formatting changes and logic changes in a single commit, or don’t fix two separate things and lump them together in the same commit.

It takes a bit of practice to figure out what constitutes a logical thing - you don’t want them too small otherwise it results in lot of noise, and you don’t want them too large otherwise it defeats the main purpose of using them.

A good rule of thumb is to avoid words like ‘and’ in your commit subject line e.g. if your commit message subject contains wording like ‘Do this thing and that thing’, you’d probably be better off having two commits ‘Do this thing’ + ‘Do that thing’.

This doesn’t fix the problem entirely, but I’ve found that using atomic commits greatly reduces merge conflicts when rebasing, and when there are conflicts they are usually easier to manage and don’t result in as many follow on merge conflicts.

0: https://www.aleksandrhovhannisyan.com/blog/atomic-git-commit...

Mercurial solves this 90% of the way with hg absorb: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...

Its extremely close to magic. You make all the requested changes on the PR4 and type hg absorb and it'll figure out which commit in your stack each change belongs to.

I've used this to work on lots of stacks 20 commits deep in mercurial.

The equivalent to "hg absorb" for Git is https://github.com/torbiak/git-autofixup

huh, shouldn't solving the conflict to pr2 create a merge commit that then also solves the conflict in 3 and 4?

It sounds like the OP might be using a rebase workflow. Such a workflow creates many repetitive conflicts because there is no merge commit to record the resolution point.

Using a rebase workflow with stacked/cascaded PRs is an anti-pattern that trips up people used to other git workflows where the history depth is effectively only one level deep instead of arbitrarily deep as in stacked/cascaded PRs.

You can tell git what the resolution point is using `git rebase --onto`. This can help avoid situations where Git gives extra conflicts form trying to reapply an old version of your change on top of a new version of the same change. You can also use `git rebase --skip` if you recognize that you’ve ended up in this situation.

I think this is something git rerere is supposed to help with