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

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:21

David Kastrup [off-list ref] 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).

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

From: David Kastrup <hidden>
Date: 2016-06-15 22:43:21

Junio C Hamano [off-list ref] writes:
David Kastrup [off-list ref] writes:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help