Re: [PATCH 4/7] merge-ort: capture and print ll-merge warnings in our preferred fashion
- From
Jeff King <peff@peff.net>
- Date
- Sep 28, 2021, 22:39 UTC
- Message-ID
- <YVOZty9D7NRbzhE5@coredump.intra.peff.net>
- In-Reply-To
- <ce95b82fc492d48fa6022df424f9a303a1c70ad4.1630376800.git.gitgitgadget@gmail.com>
On Tue, Aug 31, 2021 at 02:26:37AM +0000, Elijah Newren via GitGitGadget wrote:
Show 20 quoted lines
> From: Elijah Newren <newren@gmail.com> > > Instead of immediately printing ll-merge warnings to stderr, we save > them in our output strbuf. Besides allowing us to move these warnings > to a special file for --remerge-diff, this has two other benefits for > regular merges done by merge-ort: > > * The deferral of messages ensures we can print all messages about > any given path together (merge-recursive was known to sometimes > intersperse messages about other paths, particularly when renames > were involved). > > * The deferral of messages means we can avoid printing spurious > conflict messages when we just end up aborting due to local user > modifications in the way. (In contrast to merge-recursive.c which > prematurely checks for local modifications in the way via > unpack_trees() and gets the check wrong both in terms of false > positives and false negatives relative to renames, merge-ort does > not perform the local modifications in the way check until the > checkout() step after the full merge has been computed.)
Yeah, this is a good example of why having ll_merge() print warnings in the first place is probably wrong. If you buy my argument that ll_merge() should be returning an enum, then this code becomes IMHO even nicer, as you can generate your own sensible message in the caller.
-Peff