Jeff King <peff@xxxxxxxx> writes: > 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.
