Stefan Fuhrmann wrote: > In Berlin, Julian raised the question how relevant the criss-cross > merge case actually. I think I found a reasonable merge policy > where those cases become the norm rather than an exception. > > Most people seem to do what one might call "unqualified" catch-up > merges, i.e. "merge everything up to HEAD" regardless of HEAD's > state with respect to stability, features, side-effects etc. > > From a process perspective, it seems much more prudent to > do "qualified" merges like "merge from /trunk up to the last > fully tested nightly build revision" and "merge from branch up > to the point that I think is safe".
Yes, that makes sense. > In both directions, there will > be changes between the catch-up source from A to B and > the merge commit form B to A (and vice versa). I don't quite follow that last sentence. > Even if it was > the same person doing the merge in both directions, this > situation could not be avoided. So, in a bit more detail, the situation is like this: A = /trunk Tested versions * * A o---o---o---o---o---o---o---o---o---o---o---o---o \ \____ / \ ____\ __/ \ / \ B o---o---o---o---o---o---o---o---o---o---o Safe versions * * 1 2 3 Sequence of events: 1. Nightly testing. 2. Catch up branch from latest stable trunk. 3. Reintegrate branch to trunk, from latest tested version of branch. That sort of scenario? - Julian > Am I missing something or is that analysis correct? If it is, > criss-cross issues should be about as common as conflicts > themselves (depending on the relative size of to-be-merged > to not-yet-to-be-merged history).
