Re: Can someone explain this git-blame/git-rev behavior to me?
- From
David Kastrup <dak@gnu.org>
- Date
- Jul 16, 2007, 20:41 UTC
- Message-ID
- <85lkdgm67z.fsf@lola.goethe.zz>
- In-Reply-To
- <469B9843.835B5356@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
Show 36 quoted lines
> 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