Re: Fw: Merge conflict

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> ----- Original Message ----- 
> From: "Phil Holmes" <address@hidden>
> To: "Devel" <address@hidden>
> Sent: Sunday, January 05, 2014 12:19 PM
> Subject: Merge conflict
>
>
>> I'm trying to create a 2.19.0 build and running into merge
>> conflicts. Following the CG, I've done:
>>
>> git fetch
>> git checkout release/unstable
>> git merge origin/master
>>
>> This creates a number of merge conflicts: changes.tely is an obvious
>> one. Is there something that can be simply done to sort the
>> conflicts out?
>>
>> --
>> Phil Holmes
>
>
> Forwarding from a different email address.

Well, we released 2.17.97 from the stable branch, but the release
process still used release/unstable.  It has a number of reverts in it
compared to the unstable branch.  We don't want _any_ of that in 2.19.0.

We basically have two options:

a) reset release/unstable and recreate it from scratch
b) do a dummy merge that "resolves" everything in favor of being 2.19.0

The dummy merge will give us sort of a linear history in
release/unstable.  It will not help much otherwise.  It has the
advantage that people's own checkouts of release/unstable will not look
conflicting.  But I think that our "continuity" requirements for
release/unstable are probably not as hard as "master".

All in all, I think the best compromise is to rewind to the branch-off
point, like

git fetch
git checkout release/unstable
git reset --hard origin/release/unstable
git merge origin/master

However, this would do a fast forward anyway.  So I think I'll just bump
release/unstable to master.  And then you can do

git fetch
git checkout release/unstable
git reset --hard origin/release/unstable
git merge origin/master # should be a noop or fast forward

and then continue from there.

-- 
David Kastrup