From: Christof Krüger <git@christof-krueger.de>
Date: Sun, 26 Jun 2011 21:12:24 GMT
Subject: Re: Deleted file is back - how to investigate?
Message-ID: <1309122744.11860.121.camel@oxylap>
In-Reply-To: <20110626202532.GS30255@genesis.frugalware.org>

On So, 2011-06-26 at 22:25 +0200, Miklos Vajna wrote:
> Hi Chris,
> 
> Great, --graph indeed lists two merge commits, and if I check the tree
> objects manually, I can see which one introduced the file. But I still
> don't really understand --name-status why don't show the addition of
> those files, given that I hoped this counts as an "evil merge".

As I understand it, --name-status doesn't play any role in choosing the
commits that are interesting for the "git log <path>" command.

To speak in the terminology used in the history simplification section
of "man git":  What you want is to show all commits that are NOT
TREESAME to _at least_ one parent, whereas git gives you only commits
that are NOT TREESAME to ANY parent.
 
From my current understanding of history simplification, I don't see any
way to directly achieve this. The default mode does not include merge
commits if at least one parent is TREESAME. The --full-history option
only changes which parents are followed, but doesn't change whether a
merge is included or not. Parent rewriting unconditionally includes all
merges, even the ones that are TREESAME wrt all parents.

So do i conclude correctly, that this is a missing feature in git? Is
there something I have overlooked?

Regards,
  Chris