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$ 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 .
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk