Re: [PATCH v2] fetch: remove fetch_if_missing=0
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 8, 2019, 07:40 UTC
- Message-ID
- <xmqqmud6n7e5.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <xmqqr22inagr.fsf@gitster-ct.c.googlers.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 11 quoted lines
> An interesting thing is that c32ca691c2^2 that moved the assignment > to this big red switch variable around causes 3-way merge to fail in > a miserable way. The "moving around" would involve removing from > the same location as the rebased patch below removes, plus adding > the assignment elsewhere, so "both sides removed the assignment from > this hunk, so take that" would correctly leave the original assignment > we see in the second hunk above removed, but fails to notice that > the assignment made elsewhere (the result of "moving around" patch) > is no longer needed, because "c32ca691c2^2 added one and this change > does not do anything there, so take the addition" cleanly resolves > to an incorrect merge result.
Total tangent. One frustrating thing is that we do this a bit better at the tree level merge. After read-tree does three-way merge at the tree level, what is passed to the merge-recursive machinery has "side A added" and "side A removed" left unresolved, so that the post-processing phase could try to match them up and say "aha, side A moved that path elsewhere while side B just removed, which is a conflict".
I wish if xdiff/xmerge.c could learn a similar trick, but the necessary change feels quite involved, error prone and too magical.