{"thread":{"id":"9058","subject":"Can someone explain this git-blame/git-rev behavior to me?","startedAt":"2007-07-16T10:43:26Z","lastAt":"2007-07-17T09:57:09Z","messageCount":5,"participants":["David Kastrup","Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"47529","messageId":"86sl7oaasx.fsf@lola.quinscape.zz","threadId":"9058","inReplyTo":null,"subject":"Can someone explain this git-blame/git-rev behavior to me?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-16T10:43:26Z","receivedAt":"2007-07-16T10:43:26Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nTry the following (assuming you have a clone of the git master):\n\ngit-blame tags/v1.4.2-rc1~87 -- contrib/emacs/vc-git.el | grep b5dd\nb5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 164) (defun vc-git-print-log (file &optional buffer)\nb5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 167) (vc-do-command buffer 'async \"git\" name \"rev-list\" \"--pretty\" \"HEAD\" \"--\")))\nb5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 169) (defun vc-git-diff (file &optional rev1 rev2 buffer)\nb5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 170) (let ((name (file-relative-name file))\nb5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 171) (buf (or buffer \"*vc-diff*\")))\nb5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 173) (vc-do-command buf 0 \"git\" name \"diff-tree\" \"-p\" rev1 rev2 \"--\")\nb5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 174) (vc-do-command buf 0 \"git\" name \"diff-index\" \"-p\" (or rev1 \"HEAD\") \"--\"))\n\nOk, now do\n\ngit-name-rev b5dd9d20\nb5dd9d20 tags/v1.4.2-rc1~88\n\nSo what is it I am doing wrong here? The problem I have is that in\nEmacs, one can go to the \"next version\" in an annotated file, and I\nget stuck in a loop here, since tags/v1.4.2-rc1~88 delivers\n\ngit-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin\n\nd87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92)\n\nSo we have tags/v1.4.2-rc1~87 listed as successor again, so I get into\na loop of blame.\n\nIs there something I don't understand about merges?\n\nFWIW,\ngit-fsck --unreachable b5dd9d20\ngit-fsck --unreachable d87b90e47f\ndo not return anything.\n\n\n-- \nDavid Kastrup\n"},{"id":"47545","messageId":"469B71A5.D5299A80@eudaptics.com","threadId":"9058","inReplyTo":"86sl7oaasx.fsf@lola.quinscape.zz","subject":"Re: Can someone explain this git-blame/git-rev behavior to me?","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-07-16T13:24:53Z","receivedAt":"2007-07-16T13:24:53Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"David Kastrup wrote:\n> git-name-rev b5dd9d20\n> b5dd9d20 tags/v1.4.2-rc1~88\n> \n> So what is it I am doing wrong here? The problem I have is that in\n> Emacs, one can go to the \"next version\" in an annotated file, and I\n> get stuck in a loop here, since tags/v1.4.2-rc1~88 delivers\n> \n> git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin\n> \n> d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92)\n> \n> So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into\n> a loop of blame.\n> \n> Is there something I don't understand about merges?\n\nrev-list --parents list both the commit and its parent(s). If you are\nonly interested in the parents, ignore the first SHA1 on the line.\n\n-- Hannes\n"},{"id":"47592","messageId":"85lkdgm67z.fsf@lola.goethe.zz","threadId":"9058","inReplyTo":"469B9843.835B5356@eudaptics.com","subject":"Re: Can someone explain this git-blame/git-rev behavior to me?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-16T20:41:36Z","receivedAt":"2007-07-16T20:41:36Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Sixt writes:\n\n> David Kastrup wrote:\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>\n> It seems that there is an unwanted interaction between --parents and\n> history simplification at the edge commits. I don't think that there\n> will be an easy solution.\n\nAfter some testing, it would appear that indeed the --parents option\ncauses the problematic behavior. I find this surprising since\n--parents should not have an effect on which lines are getting\ndisplayed, should it? It should just make those lines that _are_\ngetting displayed longer.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"47604","messageId":"7v7ip02b81.fsf@assigned-by-dhcp.cox.net","threadId":"9058","inReplyTo":"86sl7oaasx.fsf@lola.quinscape.zz","subject":"Re: Can someone explain this git-blame/git-rev behavior to me?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-16T23:13:50Z","receivedAt":"2007-07-16T23:13:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin\n>\n> d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92)\n>\n> So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into\n> a loop of blame.\n\nWithout the final name-rev, it reads:\n\nd87b90e4... b5dd9d20... 280242d1...\n\nWithout the --parent option, you get only d87b90e4...; the\noption tells the command to additionally give you the (virtual)\nparents in the simplified history on the same line as well.\n\nNow, true parents of d87b90e4 are b5dd9d20 and 00449f99; the\nformer changes the path you are interested in, but the latter\ndoes not. Which means in this history:\n\n $ git show-branch d87b90e4 00449f99 280242d1\n ! [d87b90e4] Merge branch 'js/fmt-merge-msg'\n ! [00449f99] Make git-fmt-merge-msg a builtin\n ! [280242d1] send-email: do not barf when Term::ReadLine does not\n ---\n - [d87b90e4] Merge branch 'js/fmt-merge-msg'\n ++ [00449f99] Make git-fmt-merge-msg a builtin\n + [b5dd9d20] Fix print-log and diff compatibility with recent vc\n + [b5dd9d20~1] git-svn: avoid fetching files outside of the URL w\n + [b5dd9d20~2] Improve git-peek-remote\n + [b5dd9d20~3] t8001-annotate: fix a bash-ism in this test\n +++ [280242d1] send-email: do not barf when Term::ReadLine does not\n\nthe true history of a side branch forked at 280242d1 to 00449f99\nis simplified away, and 00449f99 is replaced with the boundary\ncommit 280242d1:\n\n 00449f99 d87b90e4\n o--( branch that does not change the path) ---*\n / /\n ---o----------o----------o----------o------------*\n 280242d1 b5dd9d20~3 b5dd9d20~2 b5dd9d20~1 b5dd9d20\n\n\nNote that 280242d1 is reachable from v1.4.2-rc1~88, so the\ntraversal does not go beyond it (as you said --not $that).\n"},{"id":"47624","messageId":"863aznz72i.fsf@lola.quinscape.zz","threadId":"9058","inReplyTo":"7v7ip02b81.fsf@assigned-by-dhcp.cox.net","subject":"Re: Can someone explain this git-blame/git-rev behavior to me?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-17T09:57:09Z","receivedAt":"2007-07-17T09:57:09Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> David Kastrup writes:\n>\n>> git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin\n>>\n>> d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92)\n>>\n>> So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into\n>> a loop of blame.\n>\n> Without the final name-rev, it reads:\n>\n> d87b90e4... b5dd9d20... 280242d1...\n>\n> Without the --parent option, you get only d87b90e4...;\n\nNo. Without the --parents option, I get\n\n076a10c7282a08f783a28c1b64d0e114a3fe3d39\n\nwhich is what I would think correct, as opposed to the output with\n--parents option. Have you actually tried this?\n\n-- \nDavid Kastrup\n"}]}