On 12/24/2013 10:57 AM, Bjørn Roald wrote:
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
Then git merge --no-ff develop results in conflicts because master and develop diverged in March of 2006, and both have similar changes that git can't resolve.
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.
I'd be one of those people. At any rate, there are several solutions with different characteristics. Try them locally, and push the one you like. Peter