# Can someone explain this git-blame/git-rev behavior to me? 5 messages from 2007-07-16 to 2007-07-17. Participants: David Kastrup, Johannes Sixt, Junio C Hamano. Thread: https://gitlist.dev/t/9058 ## David Kastrup, 2007-07-16 10:43 Subject: Can someone explain this git-blame/git-rev behavior to me? Message-ID: <86sl7oaasx.fsf@lola.quinscape.zz> URL: https://gitlist.dev/e/86sl7oaasx.fsf%40lola.quinscape.zz ``` Try the following (assuming you have a clone of the git master): git-blame tags/v1.4.2-rc1~87 -- contrib/emacs/vc-git.el | grep b5dd b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 164) (defun vc-git-print-log (file &optional buffer) b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 167) (vc-do-command buffer 'async "git" name "rev-list" "--pretty" "HEAD" "--"))) b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 169) (defun vc-git-diff (file &optional rev1 rev2 buffer) b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 170) (let ((name (file-relative-name file)) b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 171) (buf (or buffer "*vc-diff*"))) b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 173) (vc-do-command buf 0 "git" name "diff-tree" "-p" rev1 rev2 "--") b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 174) (vc-do-command buf 0 "git" name "diff-index" "-p" (or rev1 "HEAD") "--")) Ok, now do git-name-rev b5dd9d20 b5dd9d20 tags/v1.4.2-rc1~88 So what is it I am doing wrong here? The problem I have is that in Emacs, one can go to the "next version" in an annotated file, and I get stuck in a loop here, since tags/v1.4.2-rc1~88 delivers git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92) So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into a loop of blame. Is there something I don't understand about merges? FWIW, git-fsck --unreachable b5dd9d20 git-fsck --unreachable d87b90e47f do not return anything. -- David Kastrup ``` ## Johannes Sixt, 2007-07-16 13:24 Subject: Re: Can someone explain this git-blame/git-rev behavior to me? Message-ID: <469B71A5.D5299A80@eudaptics.com> URL: https://gitlist.dev/e/469B71A5.D5299A80%40eudaptics.com In-Reply-To: <86sl7oaasx.fsf@lola.quinscape.zz> ``` David Kastrup wrote: > git-name-rev b5dd9d20 > b5dd9d20 tags/v1.4.2-rc1~88 > > So what is it I am doing wrong here? The problem I have is that in > Emacs, one can go to the "next version" in an annotated file, and I > get stuck in a loop here, since tags/v1.4.2-rc1~88 delivers > > git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin > > d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92) > > So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into > a loop of blame. > > Is there something I don't understand about merges? rev-list --parents list both the commit and its parent(s). If you are only interested in the parents, ignore the first SHA1 on the line. -- Hannes ``` ## David Kastrup, 2007-07-16 20:41 Subject: Re: Can someone explain this git-blame/git-rev behavior to me? Message-ID: <85lkdgm67z.fsf@lola.goethe.zz> URL: https://gitlist.dev/e/85lkdgm67z.fsf%40lola.goethe.zz In-Reply-To: <469B9843.835B5356@eudaptics.com> ``` Johannes Sixt writes: > David Kastrup wrote: >> >> I am looking for a descendant of tags/v1.4.4-rc1~72 with regard to >> contrib/emacs/vc-git.el by scanning the output of the first command >> in the following pipeline: >> >> git-rev-list --parents HEAD ^tags/v1.4.4-rc1~72 -- vc-git.el|git-name-rev --stdin|fgrep tags/v1.4.4-rc1 >> >> This gives: >> 4de0f9f9b6ed1731de00b67952504e5a783f54a4 (tags/v1.5.0-rc0~31) 1259404c7e5cd88b7f6692986469cd20cbfacdad (tags/v1.4.4-rc1~71) >> 1259404c7e5cd88b7f6692986469cd20cbfacdad (tags/v1.4.4-rc1~71) b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72) 0abc0260fa3419de649fcc1444e3d256a17ca6c7 (tags/v1.4.3.2~6) >> >> And this looks like it would tell us that tags/v1.4.4-rc1~72 has with >> regard to vc-git.el a child tags/v1.4.4-rc1~71 and a grandchild of >> tags/v1.5.0-rc0~31. >> >> Now if I instead do >> git-rev-list --parents HEAD -- vc-git.el|git-name-rev --stdin|fgrep tags/v1.4.4-rc1 >> >> 4de0f9f9b6ed1731de00b67952504e5a783f54a4 (tags/v1.5.0-rc0~31) b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72) >> b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72) 474a90fef9ebcdedee041b2def4b9a98b94cd146 (tags/v1.4.3.2~8) >> >> I get to see that the child of tags/v1.4.4-rc1~72 is actually >> tags/v1.5.0-rc0~31, skipping tags/v1.4.4-rc1~71 which presumably did >> not change vc-git.el. >> >> So the ^tags/v1.4.4-rc1~72 specification caused an additional mention >> of tags/v1.4.4-rc1~71 even though, with regard to vc-git.el, it would >> be equivalent to tags/v1.4.4-rc1~72. >> >> So is there a way I can get the information of the second call without >> the performance loss of going through the entire history? > > It seems that there is an unwanted interaction between --parents and > history simplification at the edge commits. I don't think that there > will be an easy solution. After some testing, it would appear that indeed the --parents option causes the problematic behavior. I find this surprising since --parents should not have an effect on which lines are getting displayed, should it? It should just make those lines that _are_ getting displayed longer. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ``` ## Junio C Hamano, 2007-07-16 23:13 Subject: Re: Can someone explain this git-blame/git-rev behavior to me? Message-ID: <7v7ip02b81.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7ip02b81.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <86sl7oaasx.fsf@lola.quinscape.zz> ``` David Kastrup writes: > git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin > > d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92) > > So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into > a loop of blame. Without the final name-rev, it reads: d87b90e4... b5dd9d20... 280242d1... Without the --parent option, you get only d87b90e4...; the option tells the command to additionally give you the (virtual) parents in the simplified history on the same line as well. Now, true parents of d87b90e4 are b5dd9d20 and 00449f99; the former changes the path you are interested in, but the latter does not. Which means in this history: $ git show-branch d87b90e4 00449f99 280242d1 ! [d87b90e4] Merge branch 'js/fmt-merge-msg' ! [00449f99] Make git-fmt-merge-msg a builtin ! [280242d1] send-email: do not barf when Term::ReadLine does not --- - [d87b90e4] Merge branch 'js/fmt-merge-msg' ++ [00449f99] Make git-fmt-merge-msg a builtin + [b5dd9d20] Fix print-log and diff compatibility with recent vc + [b5dd9d20~1] git-svn: avoid fetching files outside of the URL w + [b5dd9d20~2] Improve git-peek-remote + [b5dd9d20~3] t8001-annotate: fix a bash-ism in this test +++ [280242d1] send-email: do not barf when Term::ReadLine does not the true history of a side branch forked at 280242d1 to 00449f99 is simplified away, and 00449f99 is replaced with the boundary commit 280242d1: 00449f99 d87b90e4 o--( branch that does not change the path) ---* / / ---o----------o----------o----------o------------* 280242d1 b5dd9d20~3 b5dd9d20~2 b5dd9d20~1 b5dd9d20 Note that 280242d1 is reachable from v1.4.2-rc1~88, so the traversal does not go beyond it (as you said --not $that). ``` ## David Kastrup, 2007-07-17 09:57 Subject: Re: Can someone explain this git-blame/git-rev behavior to me? Message-ID: <863aznz72i.fsf@lola.quinscape.zz> URL: https://gitlist.dev/e/863aznz72i.fsf%40lola.quinscape.zz In-Reply-To: <7v7ip02b81.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > David Kastrup writes: > >> git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin >> >> d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92) >> >> So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into >> a loop of blame. > > Without the final name-rev, it reads: > > d87b90e4... b5dd9d20... 280242d1... > > Without the --parent option, you get only d87b90e4...; No. Without the --parents option, I get 076a10c7282a08f783a28c1b64d0e114a3fe3d39 which is what I would think correct, as opposed to the output with --parents option. Have you actually tried this? -- David Kastrup ```