# Deleted file is back - how to investigate? 5 messages from 2011-06-26 to 2011-06-26. Participants: Miklos Vajna, Christof Krüger, Andreas Schwab. Thread: https://gitlist.dev/t/27703 ## Miklos Vajna, 2011-06-26 10:32 Subject: Deleted file is back - how to investigate? Message-ID: <20110626103218.GQ30255@genesis.frugalware.org> URL: https://gitlist.dev/e/20110626103218.GQ30255%40genesis.frugalware.org ``` 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. ``` ## Christof Krüger, 2011-06-26 14:10 Subject: Re: Deleted file is back - how to investigate? Message-ID: <1309097423.11860.76.camel@oxylap> URL: https://gitlist.dev/e/1309097423.11860.76.camel%40oxylap In-Reply-To: <20110626103218.GQ30255@genesis.frugalware.org> ``` 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 ``` ## Miklos Vajna, 2011-06-26 20:25 Subject: Re: Deleted file is back - how to investigate? Message-ID: <20110626202532.GS30255@genesis.frugalware.org> URL: https://gitlist.dev/e/20110626202532.GS30255%40genesis.frugalware.org In-Reply-To: <1309097423.11860.76.camel@oxylap> ``` On Sun, Jun 26, 2011 at 04:10:23PM +0200, Christof Krüger 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. ``` ## Andreas Schwab, 2011-06-26 20:57 Subject: Re: Deleted file is back - how to investigate? Message-ID: URL: https://gitlist.dev/e/m2iprsxqdg.fsf%40igel.home In-Reply-To: <20110626202532.GS30255@genesis.frugalware.org> ``` Miklos Vajna 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." ``` ## Christof Krüger, 2011-06-26 21:12 Subject: Re: Deleted file is back - how to investigate? Message-ID: <1309122744.11860.121.camel@oxylap> URL: https://gitlist.dev/e/1309122744.11860.121.camel%40oxylap 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 " 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 ```