-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 01.04.12 12:09, schrieb Martin Geisler:
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:
This means the person to do the fix has to do a merge, too. This means to educate everyone on the team to do proper merges, right? Ok, merging should be part of daily work, especially with hg/git, but this is not true for development teams in general.
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.
Correct. But it is a somewhat more complex workflow compared to a svn blocking merge. So a disadvantage of git/hg compared to svn. A rather strong one IMHO, but maybe not for boost development. Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk94yJAACgkQhAOUmAZhnmpO8QCbB3gm1bK9/80niqrqAAH4qtEO 3Z4AnR71YI+Fb/3SaSWBPavZn0IMETUF =QcXh -----END PGP SIGNATURE-----