1

Say I have a git history like this:

A--B--C--D <master> \--E--F <topic1> \--G <topic2>

That is, I have two topic branches, where one feature depends upon another. In the meantime, work has been done on master, so I want to rebase topic1. This results in:

A--B--C--D <master> | \--E'--F' <topic1> \--E--F--G <topic2>

That is, topic1 was rebased but topic2 was not. I want to get to this:

A--B--C--D <master> \--E'--F' <topic1> \--G <topic2>

But if I simply do git rebase topic1 topic2, Git will try to replay commits E and F on top of E' and F', which will fail because they edit the same lines of the same files. So I have to run something unwieldy like this:

git rebase --onto topic1 <sha1-of-commit-F> topic2

... which requires doing a git log and copy-pasting something (using the mouse like some sort of loser!). I know this isn't exactly heartbreaking, but this usage pattern must be fairly common for Git. Can anyone think of a way to rebase topic1 and topic2 in one fell swoop?

Improve this question
4
  • 1
    According to the rebase man page, Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped). your proposed command should work fine. Commented Sep 18, 2015 at 13:32
  • Hmm... I didn't realise that. I may be confused about what's causing my rebases to fail. I'll investigated and come back to this question. Thanks Commented Sep 18, 2015 at 13:46
  • 1
    you might get conflicts when your E' or F' were merged with conflicts as the diff will change. Commented Sep 18, 2015 at 19:16
  • OK, I've realised that the reason this is happening (rather obviously, it now seems), is when I modify E' so it no longer introduces the same changes as E. It doesn't happen for every commit. The solutions seems to be to just use git rebase --skip in those cases. Commented Sep 21, 2015 at 10:02

2 Answers 2

Reset to default
4

Git 2.38 now has the --update-refs arg for rebase.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

As Nils_M pointed out in a comment, the rebase man page says Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).

The only reason Git would replay E and F during the rebase of topic2 onto topic1 is if E' or F' has been modified from their originals. In that case, when the rebase stops due the merge conflict, simply use git rebase --skip.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.