{"thread":{"id":"41426","subject":"[BUG] git-log: tracking deleted file in a repository with multiple \"initial commit\" histories","startedAt":"2016-02-16T20:24:42Z","lastAt":"2016-02-18T22:27:13Z","messageCount":5,"participants":["Brian Norris","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"278384","messageId":"20160216202442.GH21465@google.com","threadId":"41426","inReplyTo":null,"subject":"[BUG] git-log: tracking deleted file in a repository with multiple \"initial commit\" histories","fromName":"Brian Norris","fromEmail":"computersforpeace@gmail.com","sentAt":"2016-02-16T20:24:42Z","receivedAt":"2016-02-16T20:24:42Z","isPatch":false,"sender":{"key":"computersforpeace@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2268082?v=4"},"body":"Hi,\n\nI'm not sure if this is a known behavior or a new bug report. I at least\ncouldn't find anyone mentioning this exact problem.\n\nI'm using a git repository that has multiple \"inital commits\" (i.e., a\nfew different directory trees were imported via svn-to-git as different\nbranches) whose histories have been merged together to the single master\nbranch, and the file I want to track is both added and removed in only\none of those lineages. When I try to do:\n\n  $ git log -- <file>\n\non the deleted file in the master branch, I get no history. But if I\ncheckout the particular sub-tree of the merge history, then git-log\nreturns the appropriate history.\n\nFor specifics, I'm looking at this repo:\n\n  https://chromium.googlesource.com/chromiumos/platform2\n\nand this file:\n\n  init/iptables.conf\n\nwhich is added in this commit:\n\n  882271d255f4 Still more platform modules.\n\nand deleted here:\n\n  65a8de6f85b8 chromeos-init: Remove firewall upstart jobs from platform/init\n\nand whose branch of history is merged in via the following merge commit:\n\n  8f4314b70b78 Move 'src/platform/init' to 'src/platform2'\n\n.\n\nTest 1:\n\n  $ git checkout 8f4314b70b78\n  $ git log -- init/iptables.conf\n  ## No output\n\nTest 2:\n\n  $ git checkout 8f4314b70b78^2\n  $ git log -- init/iptables.conf\n  ## See proper history\n\nThe behavior of Test 1 seems like a bug to me. Thoughts?\n\nRegards,\nBrian\n"},{"id":"278386","messageId":"20160216204557.GB27484@sigill.intra.peff.net","threadId":"41426","inReplyTo":"20160216202442.GH21465@google.com","subject":"Re: [BUG] git-log: tracking deleted file in a repository with multiple \"initial commit\" histories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-16T20:45:57Z","receivedAt":"2016-02-16T20:45:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 16, 2016 at 12:24:42PM -0800, Brian Norris wrote:\n\n> I'm not sure if this is a known behavior or a new bug report. I at least\n> couldn't find anyone mentioning this exact problem.\n> \n> I'm using a git repository that has multiple \"inital commits\" (i.e., a\n> few different directory trees were imported via svn-to-git as different\n> branches) whose histories have been merged together to the single master\n> branch, and the file I want to track is both added and removed in only\n> one of those lineages. When I try to do:\n> \n>   $ git log -- <file>\n> \n> on the deleted file in the master branch, I get no history. But if I\n> checkout the particular sub-tree of the merge history, then git-log\n> returns the appropriate history.\n\nSee the section on History Simplification in git-log. But basically,\nwhen you specify a pathspec, git does not traverse side branches that\nhad no effect on the given pathspec.\n\nSo imagine we are walking backwards through history and showing each\ncommit, and we hit a merge where the content at that path is at some\nsha1 X. We see on one side of the merge that the parent was also at X,\nand on the other it was at Y. We do not bother following the commits\ndown the second parent at all. Perhaps it touched the file and perhaps\nit did not, but it does not matter, as the merge threw away anything it\ndid in favor of the first parent.\n\nYours is a special case where the final result is \"deleted\". So there is\na merge where one side had already deleted it, and the other side had\nsome content, but the merge chose the deletion.\n\nIf you want to see the full history, you can with \"--full-history\"\n(there are some other simplification possibilities, but I don't think\nany of them are interesting for your particular case).\n\nIf you want to find the merge in question, something like:\n\n  git log --graph --full-history -m --oneline --raw -- init/iptables.conf\n\nwould work. In your case, it's probably:\n\n  8f4314b Move 'src/platform/init' to 'src/platform2'\n\n-Peff\n"},{"id":"278390","messageId":"20160216212429.GA39536@google.com","threadId":"41426","inReplyTo":"20160216204557.GB27484@sigill.intra.peff.net","subject":"Re: [BUG] git-log: tracking deleted file in a repository with multiple \"initial commit\" histories","fromName":"Brian Norris","fromEmail":"computersforpeace@gmail.com","sentAt":"2016-02-16T21:24:29Z","receivedAt":"2016-02-16T21:24:29Z","isPatch":false,"sender":{"key":"computersforpeace@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2268082?v=4"},"body":"On Tue, Feb 16, 2016 at 03:45:57PM -0500, Jeff King wrote:\n> See the section on History Simplification in git-log. But basically,\n> when you specify a pathspec, git does not traverse side branches that\n> had no effect on the given pathspec.\n\nThanks for the pointer. Is this done primarily for performance reasons,\nor for UI simplicity (e.g., to avoid some kinds of double-counting)?\nSeems like it generates unintuitive behaviors, but if it's helping block\nother unintuitive behaviors, then maybe it can't be resolved easily.\n\nFWIW, I quite often use git-log to look at the history of a deleted\nfile. Seems like a pretty big hole if the default behavior is going to\nprune away the entire history of the file.\n\n[...]\n\n> If you want to see the full history, you can with \"--full-history\"\n> (there are some other simplification possibilities, but I don't think\n> any of them are interesting for your particular case).\n\n--full-history gives me what I want (I'll admit, I didn't read through\nall the other \"History Simplification\" documentation). Can I make this\nthe default somehow?\n\nBrian\n"},{"id":"278400","messageId":"20160216222942.GA9014@sigill.intra.peff.net","threadId":"41426","inReplyTo":"20160216212429.GA39536@google.com","subject":"Re: [BUG] git-log: tracking deleted file in a repository with multiple \"initial commit\" histories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-02-16T22:29:42Z","receivedAt":"2016-02-16T22:29:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Feb 16, 2016 at 01:24:29PM -0800, Brian Norris wrote:\n\n> On Tue, Feb 16, 2016 at 03:45:57PM -0500, Jeff King wrote:\n> > See the section on History Simplification in git-log. But basically,\n> > when you specify a pathspec, git does not traverse side branches that\n> > had no effect on the given pathspec.\n> \n> Thanks for the pointer. Is this done primarily for performance reasons,\n> or for UI simplicity (e.g., to avoid some kinds of double-counting)?\n> Seems like it generates unintuitive behaviors, but if it's helping block\n> other unintuitive behaviors, then maybe it can't be resolved easily.\n\nBoth, I think. Try looking at \"--full-history\" and you will see that it\nhas a lot of cruft that is probably not that interesting. But\nsimplifying further (e.g., with \"--simplify-merges\") doesn't tell much\nof the whole story (or maybe it does; we do see the final deletion\nthere, which is the end state).\n\nBut it's been a long time since I've thought hard on simplification like\nthis. Most of these issues were resolved many years ago; you'd have to\ndig in the list archives to get the full story.\n\n> FWIW, I quite often use git-log to look at the history of a deleted\n> file. Seems like a pretty big hole if the default behavior is going to\n> prune away the entire history of the file.\n\nIt doesn't normally. What happened is that you had two parallel\nhistories, and the final state of the file could be explained by\nfollowing the simpler of the two histories (the one where it never\nexisted in the first place).\n\n> > If you want to see the full history, you can with \"--full-history\"\n> > (there are some other simplification possibilities, but I don't think\n> > any of them are interesting for your particular case).\n> \n> --full-history gives me what I want (I'll admit, I didn't read through\n> all the other \"History Simplification\" documentation). Can I make this\n> the default somehow?\n\nNo, but you can make an alias that includes it.\n\n-Peff\n"},{"id":"278588","messageId":"20160218222713.GA50021@google.com","threadId":"41426","inReplyTo":"20160216222942.GA9014@sigill.intra.peff.net","subject":"Re: [BUG] git-log: tracking deleted file in a repository with multiple \"initial commit\" histories","fromName":"Brian Norris","fromEmail":"computersforpeace@gmail.com","sentAt":"2016-02-18T22:27:13Z","receivedAt":"2016-02-18T22:27:13Z","isPatch":false,"sender":{"key":"computersforpeace@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2268082?v=4"},"body":"On Tue, Feb 16, 2016 at 05:29:42PM -0500, Jeff King wrote:\n> On Tue, Feb 16, 2016 at 01:24:29PM -0800, Brian Norris wrote:\n> \n> > On Tue, Feb 16, 2016 at 03:45:57PM -0500, Jeff King wrote:\n> > > See the section on History Simplification in git-log. But basically,\n> > > when you specify a pathspec, git does not traverse side branches that\n> > > had no effect on the given pathspec.\n> > \n> > Thanks for the pointer. Is this done primarily for performance reasons,\n> > or for UI simplicity (e.g., to avoid some kinds of double-counting)?\n> > Seems like it generates unintuitive behaviors, but if it's helping block\n> > other unintuitive behaviors, then maybe it can't be resolved easily.\n> \n> Both, I think. Try looking at \"--full-history\" and you will see that it\n> has a lot of cruft that is probably not that interesting. But\n\nI wasn't seeing the \"cruft\" at first, but now I see. It appears, BTW,\nthat 'git log --full-history -- <path>' gives vastly different commits\nthan 'git log --full-history --graph -- <path>'. (The latter has a lot\nmore \"cruft\" about unrelated merges.) That seems like a weird\ninconsistency...\n\n> simplifying further (e.g., with \"--simplify-merges\") doesn't tell much\n> of the whole story (or maybe it does; we do see the final deletion\n> there, which is the end state).\n\ngit log --full-history --simplify-merges -- init/iptables.conf\nand\ngit log --full-history --simplify-merges --graph --oneline -- init/iptables.conf\n\ngive good results for me, showing every commit that actually modifies\nthe file, AFAICT.\n\n> > FWIW, I quite often use git-log to look at the history of a deleted\n> > file. Seems like a pretty big hole if the default behavior is going to\n> > prune away the entire history of the file.\n> \n> It doesn't normally.\n\nThat doesn't really change my statement.\n\n> What happened is that you had two parallel\n> histories, and the final state of the file could be explained by\n> following the simpler of the two histories (the one where it never\n> existed in the first place).\n\nI (sort of) understand what happened. But I disagree that it's a good\ndefault. It's obviously not what the user is asking for.\n\n> > > If you want to see the full history, you can with \"--full-history\"\n> > > (there are some other simplification possibilities, but I don't think\n> > > any of them are interesting for your particular case).\n> > \n> > --full-history gives me what I want (I'll admit, I didn't read through\n> > all the other \"History Simplification\" documentation). Can I make this\n> > the default somehow?\n> \n> No, but you can make an alias that includes it.\n\nSure.\n\nThanks for the help!\n\nBrian\n"}]}