Re: Strange behauviour on Cherry-Pick

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2012-03-09 at 15:11 +0100, Alfredo Palhares wrote:
> 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.
> 

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

> 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 

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

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

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

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]