Junio C Hamano <gitster@xxxxxxxxx> writes:
> I am mildly against "merge-file --union" in the first place. The part I
> actually liked in [2/3] was the removal of postprocessing.
Actually I take the first sentence back. The --union option given to
merge-file is comparable to --ours/--theirs that let you (a Porcelain
writer using the command) access the ll-merge machinery to resolve
conflicts in favor of one side on contents stored in an arbitrary
temporary filename (or even outside a git repository). So as a feature
I think addition of "union" is in line with what we already have.
But I at the same time I think that we could add the feature while making
existing --ours/--theirs options redundant (and deprecatable if we want to
in the longer term), if the attributes mechanism is made available to us
(e.g. add "--attribute-path=<use attributes for this path>" option, and/or
perhaps add "--attributes=<use this set of attributes>" option) directly
from the command line.
I doubt "checkout --union" is a good idea, though. Its --ours/--theirs
options do not have anything to do with merge (it specifies _what_ to
checkout, not _how_), and the comparison I made in the previous paragraph
for merge-file does not apply.
It however is plausible that in a scenario where:
(1) you ran "git merge" (or anything that results in conflicts) and got a
conflict; and
(2) you know using other ll-merge backend, perhaps a custom one you have
that is accessible via ll-merge, would have produced a better result.
it might be useful if you can say "forget this failed auto-merge; attempt
the same merge for the path but using this different ll-merge backend".
I don't think that feature belongs to "checkout", though.
--
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