{"thread":{"id":"45922","subject":"git log --follow after subtree merge","startedAt":"2017-05-10T14:47:23Z","lastAt":"2017-05-11T06:53:03Z","messageCount":5,"participants":["Jonny Gilchrist","Samuel Lijin","Jeff King","Konstantin Khomoutov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"319274","messageId":"CA+qhfwO4=1X9fNCW2PeKSgqUHV-z26qhvr_yXfz1QGApJ_roRQ@mail.gmail.com","threadId":"45922","inReplyTo":null,"subject":"git log --follow after subtree merge","fromName":"Jonny Gilchrist","fromEmail":"jonnygilchrist@gmail.com","sentAt":"2017-05-10T14:46:58Z","receivedAt":"2017-05-10T14:47:23Z","isPatch":false,"sender":{"key":"jonnygilchrist@gmail.com","avatar":null},"body":"Hi,\n\nAfter doing a subtree merge, using 'git log' and 'git log --follow' on\nfiles in the subtree show only the merge commit in which they were\nadded.\n\nAfter reading around I understand that the issue is that git log\n--follow doesn't track renames that occur during a merge.\n\nHas there been any work (or are there any plans) to allow git log\n--follow to work in this case? I couldn't find anything in the mailing\nlist archives aside from a couple of threads from 2011 explaining the\nissue.\n\nThanks,\nJ.\n"},{"id":"319290","messageId":"CAJZjrdX-oAP7GFcPJ_FVNCMuErF7DNkq97KhjwgBX_G5tGXoFg@mail.gmail.com","threadId":"45922","inReplyTo":"CA+qhfwO4=1X9fNCW2PeKSgqUHV-z26qhvr_yXfz1QGApJ_roRQ@mail.gmail.com","subject":"Re: git log --follow after subtree merge","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-05-10T19:15:23Z","receivedAt":"2017-05-10T19:16:15Z","isPatch":false,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist\n wrote:\n> Hi,\n>\n> After doing a subtree merge, using 'git log' and 'git log --follow' on\n> files in the subtree show only the merge commit in which they were\n> added.\n>\n> After reading around I understand that the issue is that git log\n> --follow doesn't track renames that occur during a merge.\n\nTry git log --follow -M. (You may also want to combine this with -l and/or -C).\n\n> Has there been any work (or are there any plans) to allow git log\n> --follow to work in this case? I couldn't find anything in the mailing\n> list archives aside from a couple of threads from 2011 explaining the\n> issue.\n>\n> Thanks,\n> J.\n"},{"id":"319323","messageId":"20170511063549.fniwyggsj7wffgf5@sigill.intra.peff.net","threadId":"45922","inReplyTo":"CAJZjrdX-oAP7GFcPJ_FVNCMuErF7DNkq97KhjwgBX_G5tGXoFg@mail.gmail.com","subject":"Re: git log --follow after subtree merge","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T06:35:49Z","receivedAt":"2017-05-11T06:35:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 10, 2017 at 02:15:23PM -0500, Samuel Lijin wrote:\n\n> On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist\n> wrote:\n> > Hi,\n> >\n> > After doing a subtree merge, using 'git log' and 'git log --follow' on\n> > files in the subtree show only the merge commit in which they were\n> > added.\n> >\n> > After reading around I understand that the issue is that git log\n> > --follow doesn't track renames that occur during a merge.\n> \n> Try git log --follow -M. (You may also want to combine this with -l and/or -C).\n\nYou shouldn't need to specify \"-M\" with --follow, as the diff done by\ntry_to_follow_renames() turns on rename (and copy) detection explicitly.\nI suspect the problem is that git-log does not do merge diffs at all by\ndefault, and you'd need \"-c\" or \"--cc\" (or maybe even \"-m\") to turn them\non.\n\nI wouldn't be surprised if there are other problems where that code path\nisn't quite ready to handle merge commits, though.\n\n-Peff\n"},{"id":"319325","messageId":"20170511064728.xvawwkmc26ld5jce@sigill.intra.peff.net","threadId":"45922","inReplyTo":"20170511063549.fniwyggsj7wffgf5@sigill.intra.peff.net","subject":"Re: git log --follow after subtree merge","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-05-11T06:47:28Z","receivedAt":"2017-05-11T06:47:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 11, 2017 at 02:35:49AM -0400, Jeff King wrote:\n\n> > > After doing a subtree merge, using 'git log' and 'git log --follow' on\n> > > files in the subtree show only the merge commit in which they were\n> > > added.\n> > >\n> > > After reading around I understand that the issue is that git log\n> > > --follow doesn't track renames that occur during a merge.\n> > \n> > Try git log --follow -M. (You may also want to combine this with -l and/or -C).\n> \n> You shouldn't need to specify \"-M\" with --follow, as the diff done by\n> try_to_follow_renames() turns on rename (and copy) detection explicitly.\n> I suspect the problem is that git-log does not do merge diffs at all by\n> default, and you'd need \"-c\" or \"--cc\" (or maybe even \"-m\") to turn them\n> on.\n> \n> I wouldn't be surprised if there are other problems where that code path\n> isn't quite ready to handle merge commits, though.\n\nHmm. It does seem to work out of the box in a simple example:\n\n git init repo\n cd repo\n \n seq 100 >one\n git add one\n git commit -m base\n \n echo foo >unrelated\n git add unrelated\n git commit -m unrelated\n \n git checkout -b side HEAD^\n git mv one two\n git commit -m rename\n \n git checkout master\n git merge --no-edit side\n \n git log --oneline --raw --follow two\n\nAnd it does not seem to need any special diff options like \"-c\" to\ntrigger it.\n\nIt may be that more complex cases fool it (perhaps history\nsimplification has an effect, or perhaps it's the old issue that\n--follow has a single global idea of the \"current\" filename, even though\nit may be traversing down multiple lines of history).\n\nJonny, is it possible for you to share the repo that shows the problem?\n\nIf not, it might be possible to demonstrate the problem with\n\"fast-export --anonymize\", though I think that won't work if the rename\nis accompanied by a change in the same commit (because it anonymizes\naway the relationship between two almost-identical files).\n\n-Peff\n"},{"id":"319326","messageId":"20170511065255.leesebylo4jyj45j@tigra","threadId":"45922","inReplyTo":"CA+qhfwO4=1X9fNCW2PeKSgqUHV-z26qhvr_yXfz1QGApJ_roRQ@mail.gmail.com","subject":"Re: git log --follow after subtree merge","fromName":"Konstantin Khomoutov","fromEmail":"kostix+git@007spb.ru","sentAt":"2017-05-11T06:52:55Z","receivedAt":"2017-05-11T06:53:03Z","isPatch":false,"sender":{"key":"kostix+git@007spb.ru","avatar":null},"body":"On Wed, May 10, 2017 at 02:15:23PM -0500, Samuel Lijin wrote:\n\n> On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist\n> wrote:\n> > Hi,\n> >\n> > After doing a subtree merge, using 'git log' and 'git log --follow' on\n> > files in the subtree show only the merge commit in which they were\n> > added.\n> >\n> > After reading around I understand that the issue is that git log\n> > --follow doesn't track renames that occur during a merge.\n> \n> Try git log --follow -M. (You may also want to combine this with -l and/or -C).\n> \n> > Has there been any work (or are there any plans) to allow git log\n> > --follow to work in this case? I couldn't find anything in the mailing\n> > list archives aside from a couple of threads from 2011 explaining the\n> > issue.\n\nPlease note that technicaly there wasn't any \"rename during merging\":\nthe subtree merge took the three object of the tip commit you were\nmerging and recorded in in the merge commit as appearing under another\ntree object -- identifying the directory which was used as the subtree\nprefix. The result is that the merge commit and the commits recorded\nafter it have the files of the merged-in history under that prefix, but\nthe merged-in history itself has them \"as is\".\n\nSince Git does not record renames (that is, the `git mv` command does\nnot record a rename either -- the file it \"moves\" merely \"reappears\" in\nthe next commit under a different name), there are two solutions to your\nproblem. The first one is to use the usual heuristics of rename/copy\ndetection at the time of the history traversal -- as suggested by\nSamuel.\n\nThe second one -- if you don't need the merged-in history to be kept\n\"pristine\" -- is to first run a `git filter-branch` command on it to\nrelocate the files in all the reachable commits it contains under the\nsame prefix which you have used for subtree merge and then do that\nsubtree merge.\n\nOf course, that only works if that history is \"yours\" and the merging is\nconsidered to be a one-off operation (that is, you won't be updating the\noriginal merged-in line of development).\n\n"}]}