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
