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:

> On Tue, 2 Jun 2009, Junio C Hamano wrote:
>> 
>> 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.
>
> It's not REV_TREE_NEW, but the other way around, ie when the commit has no 
> contents but the parent _does_ have contents, maybe we shouldn't then look 
> at another parent and say "no content", and then match that other parent 
> (resulting in no difference).
>
> IOW, we are in the situation where one parent gets REV_TREE_SAME, but gets 
> it for a totally pointless reason, namely that neither that parent nor the 
> eventual merge has anything at all in that path. In that case, we simplify 
> towards the parent that results in the smallest diff - which in this case 
> is "nothing there at all".
>
> Now, that is often the _right_ thing to do, since if it was meant to be 
> deleted in that branch, then we'll eventually hit the delete commit, and 
> see it as a nice removal. But it does make it really hard to see this case 
> of "unintentional delete"

I realize that "--simplify-merges" would show that kind of deletion.

E.g. "git log --graph --oneline -- git-clone.sh" shows that the scripted
version ceased to exist at 8434c2f (Build in clone, 2008-04-27), but with
the option, b84c343 (Merge branch 'db/clone-in-c', 2008-05-25) merged the
deletion to the mainline, but while doing so we lost two updates to the
scripted version since the "Build in clone" topic forked.