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

[Junio C Hamano <gitster@pobox.com>]

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

> 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).