On 03/29/2010 11:00 PM, xor wrote:
> I thought I had:
> - used "git fetch git://bombe-repository-uri identicon" to get bombe's 
> identicon branch
> - used "git merge identicon" to merge it to master
> - used git fetch to get saces' branch (called saces aswell)
> - used git cherrypick to cherrypick commits from saces' branch
> 

ahhh i see the problem. since Bombe's identicon branch was ahead of master,
when you did "git merge", git automatically resolved this as a fast-forward,
and moved the master branch pointer on top of the "identicon" branch pointer,
instead of doing a merge-by-recursive[1] commit.

the first time i did this, it threw me off too. git should only do this when
pulling from the tracking repo, IMO.

to avoid this in future, use "git merge --no-ff"

you can also do this in one single step with "git pull --no-ff
git://bombe-repository-uri identicon"

> And I would like to know how I should have done it because the same 
> operations 
> have to be done for Freetalk... there are bombe and saces branches there 
> aswell...
> 

just remember to --no-ff, and it'll work properly.

>> This effectively cancels all the work on the master branch from feb 16 to
>>  feb 26. Was this intended? If you can't fix it I can, but I'll need to
>>  make some forced pushes.
> 
> No :(
> Why does it? :(

actually, never mind, it's OK. i got confused myself too. the history will look
even weirder when Bombe starts working on the identicon branch again, but that
doesn't matter too much i suppose.

X

[1] man git-merge:

FAST-FORWARD MERGE
       Often the current branch head is an ancestor of the named commit. This
is the most common case especially when
       invoked from git pull: you are tracking an upstream repository, you have
committed no local changes, and now
       you want to update to a newer upstream revision. In this case, a new
commit is not needed to store the
       combined history; instead, the HEAD (along with the index) is updated to
point at the named commit, without
       creating an extra merge commit.

       This behavior can be suppressed with the --no-ff option.


Reply via email to