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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux