Re: [boost] [git][multi_index] help merging from develop

Subject: Re: [boost] [git][multi_index] help merging from develop
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-24 11:57:03

On 12/24/2013 05:46 PM, Peter A. Bigot wrote:
> On 12/24/2013 10:24 AM, Bjørn Roald wrote:
>> On 12/24/2013 03:19 PM, Joaquin M Lopez Munoz wrote:
>>> Yes, I want the master branch to be exactly the same aas the branch
>>> develop stands now.
>>
>> Then just try it again.
>>
>> git checkout master
>> git tag bad-merge  # for the paranoid needing an easy way to get back!
>> git reset --hard 3239677c40b6e15d1bb49675cabb077460333538
>> git merge --no-ff develop
>> ... check you got what you want
>> git tag -d bad-merge  # for the paranoid that now has calmed down
>
> I don't believe that will work; 3239677 (current master) already has
> develop recorded as being present, so you get:
>
>    llc[431]$ git merge --no-ff develop
>    Already up-to-date.
>
> without any change.

Right, my bad, the reset should have been to the commit before
git reset --hard 802543fd948b5cf41460addf2260693f08cf7f8d

Since git-merge does not have a "-s theirs"
> parameter, the following does work:
>
>   git checkout -b hack develop
>   git merge master -s ours \
>      -m 'Merge to sync develop and master preferring develop'
>   git checkout master
>   git merge hack
>   git branch -d hack
>   git checkout develop
>   git merge master
>
> That last two merges are fast-forward, which is fine in this case.
> Check the results before you push (in fact, check the results after each
> step so you understand what it's doing).

I am  sure this will work as well, but to me it is more complicated and 
it will leave the bad commit in history, which I am sure some will argue 
it should.  In case that is required I would just tag it as bad-merge 
and push the tag. Thus keeping it out of sight but allowing the .

--
Bjørn