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

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

[David Kastrup]

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

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

[Johannes Sixt]

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

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

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 125 bytes --]


Oops, I accidentally sent the following mail in private.  So I have to
forward back to the list (don't have the original):


[-- Attachment #2: Type: message/rfc822, Size: 2671 bytes --]

From: Johannes Sixt <J.Sixt@eudaptics.com>
To: David Kastrup <dak@gnu.org>
Subject: Re: Can someone explain this git-blame/git-rev behavior to me?
Date: Mon, 16 Jul 2007 18:09:39 +0200
Message-ID: <469B9843.835B5356@eudaptics.com>

David Kastrup wrote:
> 
> Johannes Sixt <J.Sixt@eudaptics.com> writes:
> 
> > David Kastrup wrote:
> 
> >> [nonsense not really related to the problem he has been seeing]
> 
> > [Johannes replied with a reasonable analysis]
> 
> Ok, scratch that.  I got completely confused.  Here is the gist of the
> problem that kicked me, this time boiled down to the actually relevant
> part:
> 
> 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?

You better send the question again, this time to the list. I'm certainly
not the one who can answer this or even solve it.

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.

-- Hannes


[-- Attachment #3: Type: text/plain, Size: 66 bytes --]



So anybody has an idea how to go about this?

-- 
David Kastrup

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

[David Kastrup]

Johannes Sixt <J.Sixt@eudaptics.com> 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

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

[Junio C Hamano]

David Kastrup <dak@gnu.org> 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?

[David Kastrup]

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

> David Kastrup <dak@gnu.org> 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