Re: [PATCH] diff: handle NULL meta-info when spawning external diff

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 30, 2024, 16:29 UTC
Message-ID: <xmqqa5omdbte.fsf@gitster.g>
In-Reply-To: <20240130060658.GD166761@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

> The current behavior is somewhere in between, though. You get an "other"
> name passed to the external diff, but the metainfo argument makes no
> mention of a rename (it's either blank for an exact rename, or may
> contain an "index" line if there was a content change).
>
> I'm not sure anybody really cares that much either way, though. It's
> external diff, which I suspect hardly anybody uses, and those extra
> fields aren't even documented in the first place.

Oh, we probably should fix the documentation eventually, then.

But I agree that in this case, whatever stops the segfault would be good enough.

I am surprised to learn that this 8th hidden parameter dates back to 427dcb4b ([PATCH] Diff overhaul, adding half of copy detection., 2005-05-21), and it is more surprising that even before it happened, the external diff interface with 7 parameters was already documented, which happened with 03ea2802 ([PATCH 2/2] core-git documentation update, 2005-05-08). Before the addition of the copy detection, the presence of the "other" was how you learned if we saw a rename (because there was no copy, the only reason "other" is there was due to a rename). With copy detection added, extra bits of information needed to be passed and we started passing the xfrm_msg as well through the interface. At least, by dumping it to the end-user, an external diff driver could help the end-user tell if that "other" came from a rename or from a copy, even if it did not understand it itself.

And of course, after merely 6 weeks since the inception, Git did not have the "--no-index" mode (we did not even have a unified "git diff" frontend), so this was never a problem back then.