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

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Jun 3, 2009, 00:47 UTC
Message-ID: <2e24e5b90906021747v327c9db1o16d03af5dcf50546@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.01.0906021439030.4880@localhost.localdomain>

On Wed, Jun 3, 2009 at 3:25 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 19 quoted lines

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