Deleted file is back - how to investigate?

Deleted file is back - how to investigate?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Deleted file is back - how to investigate?

[Christof Krüger]

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

Re: Deleted file is back - how to investigate?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

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

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: Deleted file is back - how to investigate?

[Andreas Schwab]

Miklos Vajna <vmiklos@frugalware.org> writes:

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

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

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Deleted file is back - how to investigate?

[Christof Krüger]

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