Deleted file is back - how to investigate?

Hi,

In our public development repo I removed a file in the past, and I guess with one of the recent merges we got it back. It looks a bit strange:

$ git clone http://frugalware.org/git/pub/frugalware/frugalware-current $ git checkout 96b33e0

The ogle-gui directory is there:

$ git ls-files|grep ogle-gui source/xapps-extra/ogle-gui/FrugalBuild

But in case I run git log:

$ git log --full-history --name-status -- source/xapps-extra/ogle-gui

The latest listed commit is the one that deletes it. So how can I see which commit introduced the file again? (FWIW, we're merging with the normal recursive strategy, ideally thing special.)

Thanks.

Hi,

In this particular case, it seems that the offending commit is indeed a merge commit (a5f45ee4). But it rather looks like user error and not a git bug to me. When I checkout its first parent (a5e830ee) and merge its second parent (93b01c6c) myself, I get some conflicts, but the ogle-gui file stays deleted.

As to how to detect what pulled the file back in: I added --graph to your command line which implies parent rewriting. This includes merges and should give you some information about the "topology" of the history graph, leaving out irrelevant commits in-between. I wouldn't call myself a history simplification exptert, so there might still be cases where this does not help, but in this case it indeed shows the offending merge commit.

Regards,
  Chris

On Sun, Jun 26, 2011 at 04:10:23PM +0200, Christof Krüger <git@christof-krueger.de> 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".

Thanks.

Miklos Vajna <vmiklos@frugalware.org> writes:

The file is unchanged wrt. to the first parent, so it is "uninteresting".

Andreas.

On So, 2011-06-26 at 22:25 +0200, Miklos Vajna wrote:

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