Jeff King <p...@peff.net> writes:
> I think the merge will produce the results you are looking for. This
> would have to be configurable, though, as it is a regression for
> existing users of "union", which would want the duplicate-line
> suppression (or maybe not; it will only catch such duplicates at the
> beginning and end of the conflict hunk, so maybe it is sane to always
> ask "union" to keep all lines).
The original use-case example of "union" was to merge two shopping
lists (e.g. I add "bread" and "orange juice" to remind me that we
need to buy these things, while my wife adds "bread" and "butter").
We do not necessarily want to end up with a shopping list to buy two
loaves of bread. When the user verifies and fixes up the result, we
can keep the current behaviour and those who want to re-dup can add
one back, or we can change the behaviour to leave the duplicates and
those who do not want to see duplicates can remove them manually.
Given that the caveat you quoted already tells the user to verify
the result and not to use it without understanding its implications,
I think it technically is fine either way (read: keeping duplicates
is not a clearly superiour solution). So let's leave it as-is.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html