On Wed, Jun 3, 2009 at 3:25 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html