duplicate commits after git rebase -i HEAD~10

Hi,

  I am trying to understand what I did wrong in my git rebase and
eventually I would like to repair my mistakes. Basically after a git
rebase, I ended up with duplicate *identical* commits. One was on the
master branch and one was on a local branch which was merge to master.

$ git log --graph
...
| * commit 662be6a57a6a64840ba0f1b29d422ab6b129ff04
| | Author:
| | Date:   Fri Dec 3 15:27:10 2010 +0100
| |
| |     BUG: 122 Work toward a better framework for Java wrapping testing
| |
* | commit 1f639b9fd6c04eb48a69d84749bb30d7dd816382
| | Author:
| | Date:   Fri Dec 3 15:42:16 2010 +0100
| |
| |     BUG: 122 Work toward a better framework for Java wrapping testing
| |

Is there a way to properly merge identical commit back together ?

Thanks !

On Fri, Dec 03, 2010 at 04:04:53PM +0100, Mathieu Malaterre wrote:

They're not quite identical. They may make the same logical change, but they are based on different history.

The mistake you made is to rebase commits that have been published on another branch. Generally you would throw away the "originals" after rebasing, but in this case, the master branch already knows about them (due to the merge), so that may not be an option.

How you proceed with fixing it depends on what your history looks like, and how much of it you are willing to rewrite. From your description, your history looks something like:

             F----G <-- original branch
            /      \
  ...A--B--C--D--E--M <-- master
            \
             F'--G' <-- rebased branch

where F' is the commit matching F, and so forth. Due to merge M, master contains the commits from the original branch, but your newly rebased branch has the matching ones.

If you have not actually published the merged value of master to anyone else, and you have not built anything on top of master, then it is safe to redo that merge, like:

  git checkout master
  git reset --hard HEAD^
  git merge your-branch

If you have built on top of master, you can still redo the merge, but you would then need to replay those new commits on top of the new merge:

 # make a new branch at master just before the merge; you will have to
 # find the commit id of the merge via "git log" or gitk
 git checkout tmp-branch M^

 # now redo the merge, using the rebased commits
 git merge your-branch

 # and now we rebase master, using just the commits from _after_ the
 # merge, on top of our re-done merge
 git rebase --onto tmp-branch M master

 # the rebase command leaves us on "master" as a side effect; we can now
 # delete tmp-branch
 git branch -d tmp-branch

If you have published your merged master for others to build on top of, then you probably don't want to rewrite it, as it will cause pain for others. Just live with the commits you've published, and redo your changes as new commits on top. To restore the state of your-branch to what it was before the rebase, look in the reflog ("git log -g your-branch"), then reset it ("git checkout your-branch; git reset --hard your-branch@{1}" (or whatever reflog entry looks to be correct)).

You may want to also look at this thread, which shows a similar problem, and in which I drew a lot more pictures, which may help explain:

  http://article.gmane.org/gmane.comp.version-control.git/161823

-Peff

The first one:

The second:

I don't exactly know what the difference between the two methods to solve the duplicate problem. Why if there is already a built under master need to use the second solution? It seems the same to me to solve the problem.

Gavin Guo