On Jan 13, 2009, at 9:40 PM, skillzero@xxxxxxxxx wrote:
I created a branch from master, did a commit (8e9fdd), then did 2 more
commits (11c59c and 7024d), then did another commit (2daf23). From
master, I did a commit (47bd1b) then cherry-pick'd 2 commits from the
branch (11c59c and 7024d). When merged the branch into master, I see
the 2 cherry-picked commits twice in the log (once from the original
cherry-pick's and again from the merge).
Before the cherry-picks, your repository looks like this
o-o (master: 47bd1b)
\
o-A-B-o (branch:2daf23)
A and B are the two commits you cherry-picked (11c59c and 7024d)
After the cherry-picks, the repo looks like this:
o-o-A'-B' (master)
\
o-A-B-o (branch:2daf23)
A and A' are different commits. Same with B and B'. If you check the
SHA1 of master at this point, it will NOT be 702fd... (B). Cherry
pick creates a new commit that (as far as git is concerned) is totally
unrelated.
After the merge, you get:
o-o-A'-B'-o (master)
\ /
o-A-B-o
Since git has no knowledge that the cherry-picked (A' B') commits are
related to their originals (A B), it displays both to you. If you
want, you can use the -x flag when you use "git cherry-pick" to add a
line that describes the original source of the patch in the new commit
which eases confusion when you look at the history, but will not stop
them from being displayed.
(The reason git will still display them is that the cherry-picked
commits may be different if there were conflicting changes on the
branches. Also, hiding those commits would give a false view of
history since the changes were actually added to the repository
twice. Using gitk or "git log --graph" will show the commits on two
different lines of development.)
I thought git would realize that master already had those 2 commits
and not add them again when merging?
The simplest method is to rebase branch after doing the cherry-picks.
This should only be done if your branch has not been published. From
after the cherry-picks:
o-o-A'-B' (master)
\
o-A-B-o (branch:2daf23)
"git rebase master branch" would give you
o-o-A'-B' (master)
\
o'-o' (branch)
Git should detect that the changes from A and B were already present
in master during the rebase and skip the commits.
~~ Brian Gernhardt
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
