git merge after git cherry-pick?

Hi,

Still being a newbie...

On a branch, b, made off of master, I've made the commits b1, b2, b3 and b4.

Back on master, I need commit b1 and b3 immediately. So I:

$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"

Now, both b and master contain b1 and b3. How do I now create a log of "what remains to be merged from b to master", i.e. only b2 and b4? And how do I merge b2 and b4 to master, so master's log shows b1, b3, b2 and b4 and doesn't show b1 and b3 twice, which is what I get if I:

$ git merge b

after the cherry-picks above. Also I noticed, that if I merge master into b (to keep up-to-date with master) b1 and b3 are also mentioned twice.

I did notice that cherry-pick created new SHA1 IDs for the commits for b1 and b3 on master (as indeed man cherry-pick also says). Maybe cherry-pick is not the right tool for the job. Is there another way to "copy"/"merge" only b1 and b3 (but not b2 and b4) from b into master maintaining merge history and avoiding them being mentioned twice later?

At the time of writing b1-b4, I did not know that b1 and b3 would be needed separately, so I didn't put (b1 and b3) and (b2 and b4) on separate branches. I did notice though, that they weren't an intricate part of "the new feature". Is it required that I then do the work in separate branches?

I hope this is possible as I'm thrilled with git!

Peter

Peter Valdemar Mørch
http://www.morch.com

You could use 'git rebase' for that.

e.g. now the history of your master and b branches look like this:

  o---X---b1'---b3'---Y   master
   \
    b1---b2---b3---b4   b

The command 'git rebase master b' will then turn this history into the following:

  o---X---b1'---b3'---Y   master
                       \
                        b2---b4   b

After this 'git merge b' will do what you would like it to do.

Regards,
Gábor

*Exactly* what I was looking for. Now I know what rebase is for! Thanks.

Peter

Peter Valdemar Mørch
http://www.morch.com

You can use "git cherry master b" command (or just "git cherry master" if you are on branch 'b') to check which commits (based on patch id) on branch 'b are already present on branch 'master'.

Alternatively you can use "git log --left-right master...b" to check which comits are on which branch, although I think it wouldn't mark duplicated commits.

You can instead of merging branch 'b' into master rebase it on top of master.

This would create instead of the following history (for merge):

---*---b1'---b3'--------------M <-- master

       \                        /
        \-b1----b2----b3----b4-/           <-- b

the following

---*---b1'---b3'---b1'---b4' <-- master, b

       .                        
        ..b1....b2....b3....b4             <.. b@{1} (reflog)         

[cut]

HTH

Jakub Narebski
Poland
ShadeHawk on #git