Jeff King <peff@xxxxxxxx> writes:
> My situation was two long-running branches, "stable" and "devel",
> both of which were worked on by many developers. One person was in
> charge of integration and branch management. They wanted "stable" to
> get the contents of "devel" (which were now ready for release), ignoring
> any small fixes that had been done on "stable" (since they had all been
> moved over to "devel" previously, but in subtly different ways that
> would create conflicts). And "git reset" was not an option, because they
> wanted to keep the history of "stable" in case those fixes needed to be
> looked at later.
I sense a slightly broken workflow here, whether the "-s theirs" strategy
is used or the merge is done in the other direction using "-s ours"
strategy.
Remember, when you create a merge commit between one history and another,
you are making this statement:
I have looked at the tree state and the development history behind
both of these commits, and came up with this tree, which I believe
suits the purpose of _my_ history better than either of them.
That is why, after making such a merge with "git merge other", you won't
see any output from "git log ..other", which asks "what do I have yet to
merge?" Everything that was included in other is now in your history and
there is nothing you have to worry about having left out anymore.
So if you suspect that the sutuation "in case those fixes needed to be
looked at later" ever arises, such a merge should *not* be recorded as a
proper merge on the 'stable' branch, because at that point when you are
doing that "-s theirs" merge (and this applies equally to the case where
you make "-s ours" merge as well), you actually have not looked at "those
fixes" closely enough to make the above statement with confidence.
Having said that, that "looking back in history" can easily be done if you
mark such a "Use '-s theirs' for expediency" merge as potentially an iffy
one in its commit log message somewhere. Later if you actually hit
issues, you can locate such a merge commit, and inspect the output from
"git log $commit^2..$commit^1". You would see those fixes the "devel"
history did not have in the "stable" branch when such a merge was made.
So the above is not a fundamental objection to the approach, and that is
why I said "slightly broken". With a proper explanation between the right
use case (I think what you outlined is an example of good practice) and
the wrong use case (for example, the one described in $gmane/89024, the
whole thing after 'I think "-s theirs" is even worse.', not just the part
that was quoted in $gmane/89178), I think it is Ok to have "-s theirs"
strategy in our toolset.
Even though having said all of the above, I would actually prefer such a
"pull all of the devel down to stable" be done with this workflow instead:
(1) go to 'devel';
(2) merge all of 'stable';
(3) look at the result and prove it is perfect;
(4) go to 'stable';
(5) merge 'devel'.
The last step would be a fast-forward, and you do not need "-s theirs"
anywhere in this procedure. Step (2) can be helped with "-s ours" (which
have the same issue I discussed above), but the result is checked before
it hits the 'stable' (presumably more precious branch), which is
conceptually a big difference. This is where the existing asymmetry
between theirs and ours comes from.
Incidentally, this is how 'maint' skips to tip of 'master' after a new
major version is released, but 'maint' is merged up into 'master' often
enough that we rarely need to even use "ours" strategy.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
