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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 3, 2009, 01:20 UTC
Message-ID: <alpine.LFD.2.01.0906021811440.4880@localhost.localdomain>
In-Reply-To: <2e24e5b90906021747v327c9db1o16d03af5dcf50546@mail.gmail.com>

On Wed, 3 Jun 2009, Sitaram Chamarty wrote:

> 
> "git merge -s ours" would do precisely the same thing, wouldn't it?

Yes. It doesn't matter which way it goes - if a file is seen as being identical (and "none" very much counts) in one parent, it's not judged "interesting" from a merge patch standpoint, or even from a "git log" (aka "revision history") standpoint.

Show 6 quoted lines

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

The problem is that quite often, a merge that removes a file _is_ the correct thing when it was removed in one branch, and a merge that adds a file is even more common, and in no way special. We don't show the whole diff in a merge, because the whole diff is often nonsensical (ie so trivial that showing it all just hides the parts that are actually relevant).

So I'll have to think about it a bit more. We clearly don't generate good diffs for file deletion/creation in merges, and we should improve on it, but it's definitely not a trivial issue either.

		Linus