Re: Am able to delete a file with no trace in the log

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 4, 2009, 06:57 UTC
Message-ID: <7v63fc1o72.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.01.0906031547480.4880@localhost.localdomain>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 7 quoted lines

> And doing good diffs for a merge is _hard_. The "--cc" thing is supremely 
> useful - it's just that it's useful for data conflicts, not for metadata 
> issues.
>
> It's in fact somewhat dubious if you actually want to see the file removal 
> as a _diff_ in a merge, exactly because it's so verbose and yet often so 
> uninteresting (ie the removal may well be intentional).

Thinking about this a bit more, a "good" diff for merge that catches this kind of "broken merge" would likely require redoing a merge when you ask for a diff.

Earlier, in my "Here is a crude attempt" patch, I mentioned that the merges in the beginning part of the output are uninteresting while the one that merges "Build-in git-clone" is interesting (and "crude attempt" was not useful because it shows both).

The reason? The uninteresting ones match mechanical merge result, while the interesting one does not. For example, 17d778e (the first one in the output --- an uninteresting one) is a merge between 5e97f46 and 450f437; the former branch removes the path in question (git-clone.sh) compared to their merge base, while the latter does not change it, hence the mechanical resolution to remove the path matches what the final merge records. On the other hand, b84c343 (Merge branch 'db/clone-in-c') merges 0dbaa5b (modifies "git-clone.sh" since the merge base) and b50c846 (removes) and the mechanical merge results in a conflict.

I think the original example can be handled in the same way. A side branch created a new file since the merge base, but a merge lost the file by mistake. The recorded result does not resemble the mechanical merge result and we can flag it by detecting this condition (that is, if we wanted to --- I do not think we want to spend cycles to recreate a merge while traversing the history with "log --stat" by default).