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

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

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

Show 9 quoted lines

> What happens is that "git log" with a filename will always simplify the 
> history to the side that matches. And yes, "matching" can and does include 
> "doesn't exist in child, doesn't exist in parent"
>
> Now, I admit that in this case the matching heuristic is dubious, and 
> maybe we should consider "does not exist in result" to not match any 
> parent. We already think that "all new" is special ("REV_TREE_NEW" vs 
> "REV_TREE_DIFFERENT"), so maybe we should think that "all deleted" is also 
> special ("REV_TREE_DEL")

Sorry, but I do not quite understand this comment. REV_TREE_NEW can be treated differently from REV_TREE_DIFFERENT but that only happens if you know about --remove-empty option, and no scripted (and later converted to C) Porcelain uses that option by default.

Also, and more on the topic of simplification, if one parent matches the child (i.e. REV_TREE_SAME), the merge history is simplified by discarding other parents, regardless of the nature of their differences, be they REV_TREE_NEW or REV_TREE_DIFFERENT, so in that sense we do not even special case REV_TREE_NEW at all for the purpose of merge simplification.