Can someone explain this git-blame/git-rev behavior to me?

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 wrote:

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 <dak@gnu.org> writes:

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).

Junio C Hamano <gitster@pobox.com> writes:

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?

Johannes Sixt <J.Sixt@eudaptics.com> writes:

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.