Re: [boost] [git] Mercurial? easy merging in svn, how about git/hg?

Subject: Re: [boost] [git] Mercurial? easy merging in svn, how about git/hg?
From: Martin Geisler (mg_at_[hidden])
Date: 2012-04-01 06:09:02

Frank Birbacher <bloodymir.crap_at_[hidden]> writes:

> Hi!
>
> Am 29.03.12 22:18, schrieb Martin Geisler:
>> Blocking changes is harder because we always use three-way merges
>> instead of re-playing patches. If you know that you don't need a
>> particular changeset again, then you can back it out. This is just
>> a way of applying the reverse patch from that changeset.
>>
>> +x    +y    -x a --- b --- c --- d --- f
>
> Ok, this means removing the changes from a branch. But what for the
> following: consider a stable and a development branch, just as in your
> example. Bugfixes go to stable and features go to development. Once in
> a week someone merges the stable branch into dev to bring all bugfixes
> into dev. Now someone fixes a bug on stable which shall be fixed
> differently on dev, here shown as z and z':
>
>   dev:    ... a --- b --- c --- d --- z'
>                    /           /
>   stable: ... --- x --------- y --- z
>
> The z and z' are logically the same fix, but syntactically they are
> different. With svn you could block z from being merged into dev
> (effective when the merge will happen sometime in the future.) With a
> three-way merge this seems not easily possible. A merge from will
> reproduce the z in dev (ancestor is y currently.) So you will have to
> produce a new common ancestor of dev and stable right on the spot,
> meaning to do a merge and somehow remove z from it.
>
> You might ask why can z and z' be different in the first place. Well,
> it may be the coding on dev has changed due to new library functions,
> new compiler capabilities, or new design of something.

Yeah, this situation is not uncommon with long-lived branches where a
bugfix in version 1.x looks quite different when you forward-port it to
the 2.x and 3.x series.

With Git or Mercurial you do the merge of z' and z and then resolve the
conflicts in favour of z'. There's no direct way to block a changeset
from "flowing" into a given branch -- since changesets don't "flow"
anywhere when you merge.

With a simple scenario like the above it's not a big problem: you merge
stable into dev after every one or two changes on stable. So you can do
the merge, revert back to dev and then port the bugfix by hand:

  hg update dev
  hg merge stable
  hg revert --all --rev dev
  # now do the bugfix by hand
  hg commit -m "merge with stable, hand-ported bugfix #123"

The advantage of doing a such a "dummy merge" where you throw away all
changes from the other branch is that you record the merge in the
history. So future three-way merges will not re-merge this change.

-- 
Martin Geisler
Mercurial links: http://mercurial.ch/