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

Linus Torvalds [off-list ref] writes:

On Tue, 2 Jun 2009, Junio C Hamano wrote:

quoted

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.