CODEWITHSUNDEEP
gitrebase
flowit
flowit

Reputation: 1442

git: rebase branch onto its rebased parent

The initial situation is very straightforward. Having a feature_1 branch that is actively developed, and, branched from HEAD, a feature_2 branch.

A-B: feature_1
   \ C: feature_2

Let's imagine commit A added a new file, commit B appended a line to that file and C appended another line. So the changes are all in one file and close to each other.

While working on feature_2, a new version of feature_1 is force pushed: A-B': feature where commit B was amended (for example to fix a typo).

I want to have this fix in branch feature_2 which I'm working on in parallel, so I rebase: git checkout feature_2 && git rebase -i feature_1. The goal is:

A-B': feature_1
   \ C': feature_2

The interactive (just to see what's happening behind the scenes) rebase menu gives me two commits to work with: B (the old one) and C.

First option: I just pick both of them. In this case there will be a conflict picking B and another conflict picking C. But basically it's the same conflict I have to resolve twice.

Second option: Having in this easy example the background knowledge that B is completely superseeded by B' which is already in feature_1 I can just drop B from the rebase menu and only have to resolve the conflict when rebasing C.

The second option works for such small fixes and a really small number of commits but imagine there was a big refactoring in feature_1 spanning over dozens of commits. The risk of dropping an important change by accident would be quite high.

Is there another way to limit the amout of conflict resolving I have to do here?

Upvotes: 1

Views: 146

Answers (1)

j6t
j6t

Reputation: 13627

Since you know that B was replaced by B', the correct solution is to drop B from the rebase instruction sheet. Then you have to resolve only the conflict that arises when C is placed on top of B' (if any).

Note that there is no "risk of dropping an important change by accident" when you proceed in this way: if something was dropped, then only because B was morphed into B' by someone else (and there must have been a reason to do that).

If your upstream (feature_1) spans over more than one commit, then let's assume you have just fetched the new upstream with git fetch. Then you can do "the right thing" with

git checkout feature_2
git rebase --onto origin/feature_1 origin/feature_1@{1}

That is, you say that you want to transplant your feature branch on top of origin/feature_1 (the new one), but you know that it branched off from the previous version (@{1}) of that branch.

Upvotes: 1

Related Questions