Strange behauviour on Cherry-Pick

Hello, 

I have a repository[1] with my home files that i keep track off on my machines. Until now ive been having everything in the same branch across all the computers, but now i have a machine that requires diferences on some files.

So what i did i branched out and keep control the commits i want to the other branch trough cherry-picking.

So there's how i did it.

  Create the new branch
  $ git checkout -b boobierack 
  Start by removing files i dont need in this machine (one of the reasons  i will not merge this branch)
  $ git rm files
  $ git commit -m "remove files"
  Now editing things i only need here
  $ vim file
  $ git commit -m "Edit file to feature X work in this machine"
  Now i have some sweet weechat configs in this machine i want to committ
  $ git add .weecchat/conffiles
  $ git commit -m "Add swet weechat configs"
  I also added tmux
  ...
  Now i added some sup config files i only need in this branch
  $ git add .sup/whateves
  $ git commit -m "Add sup configs"
  Push branch up
  $ git push origin boobierack

On another computer:
  I wanted that tmux config but i didn't want to merge the branch, so i cherry picked the commit 
  (Maybe this is not the best way to this use case, if so i am open to sugestions, but keep reading
  because i want to know why this is happening ) 
  Since cherry pick gets the diff introduced by that commit, i think using it woulbe nice.
  $ git pull origin
  On branch master
  $ git cherry-pick refspectotmuxcommit
  Maybe those weechat config would be handy in another computers
  $ git cherry-pick refscectoweechatconfigs
  Pushed the commits
  $ git push origin
  Everything seemed ok both on master[2] and boobierack[3] branches

Back to the boobierack machine:
  Pull the commits before adding more stuff
  $ git pull origin 
  remote: Counting objects: 20, done.
  remote: Compressing objects: 100% (13/13), done.
  remote: Total 18 (delta 2), reused 18 (delta 2)
  Unpacking objects: 100% (18/18), done.
  From github.com:masterkorp/Home-files
   * branch            HEAD       -> FETCH_HEAD
   Merge made by recursive.

  I got like... OK ? 
  On branh boobierack
  $ git log --pretty=format:'''%h : %s''' --date-order --graph -n 6
  *   4d7b2e8 : Merge github.com:masterkorp/Home-files into boobierack
  |\  
  | * 9937a0a : Fancier tmux
  * | 811355b : Add sup config files
  * | 9de92a2 : Fancier tmux
  | * aac85ac : Add weechat config files
  * | 90a6162 : Add weechat config files

  And master branch was untouched, i read on recursive merging on man page, but 
  i can't even understand why is git using that method in the first place, since 
  the hashes are diferent and git doesn't care about the diff when fetching iirc.

  Any help would be deeply apreciated.

[1] https://github.com/masterkorp/Home-files [2] https://github.com/masterkorp/Home-files/commits/master [3] https://github.com/masterkorp/Home-files/commits/boobierack

-- Regards, Alfredo Palhares

On Fri, 2012-03-09 at 15:11 +0100, Alfredo Palhares wrote:

[cherry-pick two commits from 'boobierack' into 'master']

The master branch was untouched because you didn't tell git to do anything with it.

The diffs between branches don't matter when fetching, but this is only part of what you are doing here. Pull is fetch + merge and as you specified a remote and no branch, it took the remote's default branch, which seems to be 'master', and merged it into your current branch. What you show is precisely what one would expect to see. Those two commits that you cherry-picked are on each branch (or rather, their equivalents) and then you have a merge between that remote and branch 'boobierack' which you were on when you told git to merge origin's default branch.

This however doesn't seem to be what you were trying to do. What were you trying to achieve with the pull? It seems to make sense that you'd want to merge the master branch, as you yourself said that it had changes that would never get merged back to 'master'.

   cmn