{"thread":{"id":"9063","subject":"Re: Can someone explain this git-blame/git-rev behavior to me?","startedAt":"2007-07-16T16:38:56Z","lastAt":"2007-07-16T16:38:56Z","messageCount":1,"participants":["David Kastrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"47558","messageId":"867ip05mn3.fsf@lola.quinscape.zz","threadId":"9063","inReplyTo":null,"subject":"Re: Can someone explain this git-blame/git-rev behavior to me?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-16T16:38:56Z","receivedAt":"2007-07-16T16:38:56Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nOops, I accidentally sent the following mail in private.  So I have to\nforward back to the list (don't have the original):\n\n\n\nDavid Kastrup wrote:\n> \n> Johannes Sixt <J.Sixt@eudaptics.com> writes:\n> \n> > David Kastrup wrote:\n> \n> >> [nonsense not really related to the problem he has been seeing]\n> \n> > [Johannes replied with a reasonable analysis]\n> \n> Ok, scratch that.  I got completely confused.  Here is the gist of the\n> problem that kicked me, this time boiled down to the actually relevant\n> part:\n> \n> I am looking for a descendant of tags/v1.4.4-rc1~72 with regard to\n> contrib/emacs/vc-git.el by scanning the output of the first command\n> in the following pipeline:\n> \n> git-rev-list --parents HEAD ^tags/v1.4.4-rc1~72 -- vc-git.el|git-name-rev --stdin|fgrep tags/v1.4.4-rc1\n> \n> This gives:\n> 4de0f9f9b6ed1731de00b67952504e5a783f54a4 (tags/v1.5.0-rc0~31) 1259404c7e5cd88b7f6692986469cd20cbfacdad (tags/v1.4.4-rc1~71)\n> 1259404c7e5cd88b7f6692986469cd20cbfacdad (tags/v1.4.4-rc1~71) b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72) 0abc0260fa3419de649fcc1444e3d256a17ca6c7 (tags/v1.4.3.2~6)\n> \n> And this looks like it would tell us that tags/v1.4.4-rc1~72 has with\n> regard to vc-git.el a child tags/v1.4.4-rc1~71 and a grandchild of\n> tags/v1.5.0-rc0~31.\n> \n> Now if I instead do\n> git-rev-list --parents HEAD -- vc-git.el|git-name-rev --stdin|fgrep tags/v1.4.4-rc1\n> \n> 4de0f9f9b6ed1731de00b67952504e5a783f54a4 (tags/v1.5.0-rc0~31) b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72)\n> b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72) 474a90fef9ebcdedee041b2def4b9a98b94cd146 (tags/v1.4.3.2~8)\n> \n> I get to see that the child of tags/v1.4.4-rc1~72 is actually\n> tags/v1.5.0-rc0~31, skipping tags/v1.4.4-rc1~71 which presumably did\n> not change vc-git.el.\n> \n> So the ^tags/v1.4.4-rc1~72 specification caused an additional mention\n> of tags/v1.4.4-rc1~71 even though, with regard to vc-git.el, it would\n> be equivalent to tags/v1.4.4-rc1~72.\n> \n> So is there a way I can get the information of the second call without\n> the performance loss of going through the entire history?\n\nYou better send the question again, this time to the list. I'm certainly\nnot the one who can answer this or even solve it.\n\nIt seems that there is an unwanted interaction between --parents and\nhistory simplification at the edge commits. I don't think that there\nwill be an easy solution.\n\n-- Hannes\n\n\n\n\n\nSo anybody has an idea how to go about this?\n\n-- \nDavid Kastrup\n"}]}