duplicate commits after git rebase -i HEAD~10

duplicate commits after git rebase -i HEAD~10

[Mathieu Malaterre]

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 !

-- 
Mathieu

Re: duplicate commits after git rebase -i HEAD~10

[Jeff King]

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

>   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.

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

Re: duplicate commits after git rebase -i HEAD~10

[Gavin Guo]

The first one:

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

The second:

>  git checkout tmp-branch M^
>  git merge your-branch
>  git rebase --onto tmp-branch M master
>  git branch -d tmp-branch

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