Re: git apply vs. renamed files index mismatch

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2008, 14:45 UTC
Message-ID: <7vtzcp8jk0.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080909100628.GA15298@oksana.dev.rtsoft.ru>

Anton Vorontsov <avorontsov@ru.mvista.com> writes:

Show 5 quoted lines

> Now consider the following patch (modified by hand: it should say
> +foo, but I changed it to +bar).
> ...
> The "index ..." stuff says that there are no changes and it is
> pure rename, but obviously there is a change.

Ah, I see what you mean.  But in general, it is not obvious at all.

If you have the identical preimage (recorded on the LHS of the index line) or the patch reproduces the postimage in full (i.e. "create a new file"), you *could* notice. It's an interesting idea from git person's point of view (i.e. "would be fun to implement"), but I doubt it would be useful in practice, because:

 (1) You often do not have the identically matching preimage;

 (2) More importantly, it is not unusual for people to *edit* the patch in
     their MUA (think of typofixes), after getting it out of git.

 (3) Even more importantly, even if you notice there is some difference,
     you cannot produce the postimage by only looking at the hash (this is
     obvious -- otherwise by definition you broke SHA-1), so you cannot
     tell *how* the patch was modified.

What is of much more practical value to learn here in the context of this topic would be that after accepting such a patch that does not use -M (so that non-git people can use patch(1) to apply), a git person can still verify the result with "git show -M" to see what changes other than a pure rename was made by the patch.