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