From: Sitaram Chamarty Date: Wed, 03 Jun 2009 00:47:17 GMT Subject: Re: Am able to delete a file with no trace in the log Message-ID: <2e24e5b90906021747v327c9db1o16d03af5dcf50546@mail.gmail.com> In-Reply-To: On Wed, Jun 3, 2009 at 3:25 AM, Linus Torvalds wrote: > > > On Tue, 2 Jun 2009, Jeff King wrote: >> >> But it doesn't show up in "git log". I believe this is because the rule >> for what to show in a merge commit is "if content is exactly the same as >> one of the parents, it's not interesting". > > Correct. > > 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") "git merge -s ours" would do precisely the same thing, wouldn't it? That has happened to me before, and I noticed that git log does not show the deletion, but rationalised it as being because I had explicitly done a "-s ours". Fixing this would fix that (maybe more common) case too, and show that the merge commit removed the file.