1

I have branch B coming out of Branch A. Branch A has updates, let's call this state A'. I rebase branch B on top of it and resolve conflicts, let's call this state B'. More changes on A make it A'', and now I need to rebase again: rebase B' on top of A''.

But at this point, I get conflicts that I resolved already, with lines that do not exist not in A'' nor in B'. For some reason, Git seems to resurrect and apply conflicts from lines that come from A and B.

I've already seen answers to a similar question pointing to rerere but have additional questions.

My questions are:

  1. What is the point of getting these old conflicts and needing to resolve them again, or turning on rerere?
  2. If I hadn't turned on rerere when I resolved the conflicts in the first time, is there any way at all to not have to resolve the conflicts again? They were pretty nasty.
Idan
  • 5,365
  • 5
  • 24
  • 28
  • When you say "Branch A has updates", do you mean that it has new commits on top of the old state, or that its history has been rewritten since you forked your branch B from it? – j6t Mar 15 '21 at 07:00
  • Ruling out the obvious: you are intentionally keeping branch B's behavior out of branch A, correct? i.e. intentionally avoiding merge? – schumacher574 Mar 15 '21 at 07:11
  • To answer you second question: yes, you can do that retrain `rerere` on an already done conflict resolution: [check here](https://stackoverflow.com/questions/9253046/git-reword-without-resolving-merge-conflicts-again/45664714#45664714) and [here](https://stackoverflow.com/a/4155237/6577998). For question 1: the point is that `rerere` can "see" how you resolved these conflicts so it remembers them, otherwise it won't know about them. – mnestorov Mar 15 '21 at 14:16
  • Thanks for the comments. While I'm still not sure exactly what's going on, I realized I can solve the issue by running `git rebase -i`, and picking only the latest commit which is the new commit in branch B. For some reason, git by default also picks older commits from branch A and rebases them on top of themselves? If someone can explain what's exactly going on and why does it work like that, I can then accept their answer. – Idan Mar 16 '21 at 01:58
  • @schumacher574 correct, I'm separating my feature to a few branches because we have a culture of small PRs. – Idan Mar 16 '21 at 02:01
  • If you have only one commit in B that is not also in A *and* `git rebase` rebases more than just that commit, *then* the history of A has been rewritten. Complain with your upstream who manages A. They should be less rude to the consumers of their branch, or provide help how to deal with history rewrite situations. – j6t Mar 16 '21 at 07:08
  • A is also my branch in this instance! `master->A->B`, this is called a [pr-train](https://github.com/realyze/pr-train), with the intention of making the smaller PRs easier to review. But from time to time I need to either rebase A on master to get the latest changes, or to add changes I forgot to add to A after creating B. (that logically live in A). Do you know of an easier way to manage this? – Idan Mar 16 '21 at 09:36
  • The `git rebase -i` approach that you mention is probably the most accessible. There is also `git rebase --onto A A@{1.hour.ago} B`, but it's a bit more fiddly. – j6t Mar 16 '21 at 16:49

0 Answers0