{"thread":{"id":"27703","subject":"Deleted file is back - how to investigate?","startedAt":"2011-06-26T10:32:18Z","lastAt":"2011-06-26T21:12:24Z","messageCount":5,"participants":["Miklos Vajna","Christof Krüger","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"170547","messageId":"20110626103218.GQ30255@genesis.frugalware.org","threadId":"27703","inReplyTo":null,"subject":"Deleted file is back - how to investigate?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2011-06-26T10:32:18Z","receivedAt":"2011-06-26T10:32:18Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"Hi,\n\nIn our public development repo I removed a file in the past, and I guess\nwith one of the recent merges we got it back. It looks a bit strange:\n\n$ git clone http://frugalware.org/git/pub/frugalware/frugalware-current\n$ git checkout 96b33e0\n\nThe ogle-gui directory is there:\n\n$ git ls-files|grep ogle-gui\nsource/xapps-extra/ogle-gui/FrugalBuild\n\nBut in case I run git log:\n\n$ git log --full-history --name-status -- source/xapps-extra/ogle-gui\n\nThe latest listed commit is the one that deletes it. So how can I see\nwhich commit introduced the file again? (FWIW, we're merging with the\nnormal recursive strategy, ideally thing special.)\n\nThanks.\n"},{"id":"170549","messageId":"1309097423.11860.76.camel@oxylap","threadId":"27703","inReplyTo":"20110626103218.GQ30255@genesis.frugalware.org","subject":"Re: Deleted file is back - how to investigate?","fromName":"Christof Krüger","fromEmail":"git@christof-krueger.de","sentAt":"2011-06-26T14:10:23Z","receivedAt":"2011-06-26T14:10:23Z","isPatch":false,"sender":{"key":"git@christof-krueger.de","avatar":null},"body":"Hi,\n\nIn this particular case, it seems that the offending commit is indeed a\nmerge commit (a5f45ee4). But it rather looks like user error and not a\ngit bug to me. When I checkout its first parent (a5e830ee) and merge\nits second parent (93b01c6c) myself, I get some conflicts, but the\nogle-gui file stays deleted.\n\nAs to how to detect what pulled the file back in:\nI added --graph to your command line which implies parent rewriting.\nThis includes merges and should give you some information about the\n\"topology\" of the history graph, leaving out irrelevant commits\nin-between. I wouldn't call myself a history simplification exptert, so\nthere might still be cases where this does not help, but in this case it\nindeed shows the offending merge commit.\n\nRegards,\n Chris\n"},{"id":"170556","messageId":"20110626202532.GS30255@genesis.frugalware.org","threadId":"27703","inReplyTo":"1309097423.11860.76.camel@oxylap","subject":"Re: Deleted file is back - how to investigate?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2011-06-26T20:25:32Z","receivedAt":"2011-06-26T20:25:32Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, Jun 26, 2011 at 04:10:23PM +0200, Christof Krüger wrote:\n> In this particular case, it seems that the offending commit is indeed a\n> merge commit (a5f45ee4). But it rather looks like user error and not a\n> git bug to me. When I checkout its first parent (a5e830ee) and merge\n> its second parent (93b01c6c) myself, I get some conflicts, but the\n> ogle-gui file stays deleted.\n> \n> As to how to detect what pulled the file back in:\n> I added --graph to your command line which implies parent rewriting.\n> This includes merges and should give you some information about the\n> \"topology\" of the history graph, leaving out irrelevant commits\n> in-between. I wouldn't call myself a history simplification exptert, so\n> there might still be cases where this does not help, but in this case it\n> indeed shows the offending merge commit.\n\nHi Chris,\n\nGreat, --graph indeed lists two merge commits, and if I check the tree\nobjects manually, I can see which one introduced the file. But I still\ndon't really understand --name-status why don't show the addition of\nthose files, given that I hoped this counts as an \"evil merge\".\n\nThanks.\n"},{"id":"170558","messageId":"m2iprsxqdg.fsf@igel.home","threadId":"27703","inReplyTo":"20110626202532.GS30255@genesis.frugalware.org","subject":"Re: Deleted file is back - how to investigate?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2011-06-26T20:57:31Z","receivedAt":"2011-06-26T20:57:31Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Miklos Vajna writes:\n\n> Great, --graph indeed lists two merge commits, and if I check the tree\n> objects manually, I can see which one introduced the file. But I still\n> don't really understand --name-status why don't show the addition of\n> those files, given that I hoped this counts as an \"evil merge\".\n\nThe file is unchanged wrt. to the first parent, so it is\n\"uninteresting\".\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"170559","messageId":"1309122744.11860.121.camel@oxylap","threadId":"27703","inReplyTo":"20110626202532.GS30255@genesis.frugalware.org","subject":"Re: Deleted file is back - how to investigate?","fromName":"Christof Krüger","fromEmail":"git@christof-krueger.de","sentAt":"2011-06-26T21:12:24Z","receivedAt":"2011-06-26T21:12:24Z","isPatch":false,"sender":{"key":"git@christof-krueger.de","avatar":null},"body":"On So, 2011-06-26 at 22:25 +0200, Miklos Vajna wrote:\n> Hi Chris,\n> \n> Great, --graph indeed lists two merge commits, and if I check the tree\n> objects manually, I can see which one introduced the file. But I still\n> don't really understand --name-status why don't show the addition of\n> those files, given that I hoped this counts as an \"evil merge\".\n\nAs I understand it, --name-status doesn't play any role in choosing the\ncommits that are interesting for the \"git log \" command.\n\nTo speak in the terminology used in the history simplification section\nof \"man git\": What you want is to show all commits that are NOT\nTREESAME to _at least_ one parent, whereas git gives you only commits\nthat are NOT TREESAME to ANY parent.\n \nFrom my current understanding of history simplification, I don't see any\nway to directly achieve this. The default mode does not include merge\ncommits if at least one parent is TREESAME. The --full-history option\nonly changes which parents are followed, but doesn't change whether a\nmerge is included or not. Parent rewriting unconditionally includes all\nmerges, even the ones that are TREESAME wrt all parents.\n\nSo do i conclude correctly, that this is a missing feature in git? Is\nthere something I have overlooked?\n\nRegards,\n Chris\n"}]}