5 ms·

I do stacked PRs at work, they work great until someone suggests an invasive change in a PR lower down in the stack. Does anyone have ideas on how to deal with

by avl999 4y ago

I do stacked PRs at work, they work great until someone suggests an invasive change in a PR lower down in the stack. Does anyone have ideas on how to deal with merge conflicts in this type of flow? For example let's say I have the following stack of PRs PR1 -> PR2 -> PR3 -> PR4 The reviewer reviews and suggests a change in PR1, this change causes a merge conflict in PR2 and therefore in PR3 and PR4 as well. And then you have to go in manually resolve the exact same merge conflict all the way through you PR stack in each of the PRs. This gets annoying and hard to work with. Does anyone have a better way of dealing with this pattern of merge conflict? I've tried using git rerere which in theory sounds helpful but doesn't seem to do anything when I strike this issue.

fire 4y ago
huh, shouldn't solving the conflict to pr2 create a merge commit that then also solves the conflict in 3 and 4?
- travisb 4y ago
  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.
  - xerxes901 4y ago
    I think this is something git rerere is supposed to help with
  - anderskaseorg 4y ago
    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.
kqr 4y ago
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.
arxanas 4y ago
The linked tool git-branchless handles this pretty well (https://github.com/arxanas/git-branchless 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.
- avl999 4y ago
  Thanks this looks interesting, I will definitely give it a shot.
imron 4y ago
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-commits/ https://www.aleksandrhovhannisyan.com/blog/atomic-git-commit...
WookieRushing 4y ago
Mercurial solves this 90% of the way with hg absorb: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/ 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.
- krobelus 4y ago
  The equivalent to "hg absorb" for Git is https://github.com/torbiak/git-autofixup https://github.com/torbiak/git-autofixup

by avl999 4y ago

fire 4y ago

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

travisb 4y ago
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.
- xerxes901 4y ago
  I think this is something git rerere is supposed to help with
- anderskaseorg 4y ago
  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.

kqr 4y ago

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.

arxanas 4y ago

The linked tool git-branchless handles this pretty well (https://github.com/arxanas/git-branchless 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.

avl999 4y ago
Thanks this looks interesting, I will definitely give it a shot.

imron 4y ago

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-commits/ https://www.aleksandrhovhannisyan.com/blog/atomic-git-commit...

WookieRushing 4y ago

Mercurial solves this 90% of the way with hg absorb: https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-changes-in-mercurial-4.8/ 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.

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