"Phil Holmes" <[email protected]> writes: > ----- Original Message ----- > From: "Phil Holmes" <[email protected]> > To: "Devel" <[email protected]> > 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
