Rebase autoskip patches that are already in upstream

By jopi... on January 25, 2014 19:25 (imported from Google Code)

---

What steps will reproduce the problem?

1. Commit something -> commit a
2. Email commit a as patch to be patched upstream
3. Upstream does another commit that touches the same line as commit a did -> commit b
4. You do another commit -> commit c

It is now like this:

   a-c     you  

x-y-<
z-a'-b upstream

4. Now do a fetch&rebase

What is the expected output?
No conflicts and your branch will look like this:
x-y-z-a'-b-c
(Commit a is automatically skipped)

What do you see instead?
x-y-z-a'-b-a''
And then you must resolve a conflict.

Please provide any additional information below.

Commit a was already patched (or cherry-picked) upstream. Because it was not merged the usual way it is not the same commit (it has a different commit-id). So when you rebase, it tries to apply commit a on the upstream branch where commit a was already applied (a'). This can cause conflicts when there was also commit b, based on commit a' that touches the same lines as commit a' did.
To confuse the user even more, when you try to resolve the conflicts, you will see the changes of commit b (their changes) under 'mine' or 'local' and the changes of commit a (users changes) under 'remote' or 'theirs'. (That is because the rebase dialog is also used to cherry-pick upstream changes to your branch)

There's another possibility that commit b was actually commit b' also coming from an emailed or cherry-picked patch from you (the user). When you try to resolve the conflict it will then look like the change is trying to revert something (coming from commit a) that you just changed in commit b (but now actually commit b').

• Proposed fix:
  git pull --rebase doesn't have this problem (most of the time). That is because it automatically skips commits with a patch-id (note, not commit-id) that are already in upstream.
  In the rebase dialog, the same can simply be achieved by executing:
  git cherry <upstream> HEAD
  Commit-id's prefixed with a '-' are the ones that should be skipped. So it would be great when the rebase dialog would automatically preset those commits to 'skip'