* Can someone explain this git-blame/git-rev behavior to me?
@ 2007-07-16 10:43 David Kastrup
2007-07-16 13:24 ` Johannes Sixt
2007-07-16 23:13 ` Junio C Hamano
0 siblings, 2 replies; 6+ messages in thread
From: David Kastrup @ 2007-07-16 10:43 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can someone explain this git-blame/git-rev behavior to me?
2007-07-16 10:43 Can someone explain this git-blame/git-rev behavior to me? David Kastrup
@ 2007-07-16 13:24 ` Johannes Sixt
[not found] ` <86ps2s736g.fsf@lola.quinscape.zz>
2007-07-16 23:13 ` Junio C Hamano
1 sibling, 1 reply; 6+ messages in thread
From: Johannes Sixt @ 2007-07-16 13:24 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Can someone explain this git-blame/git-rev behavior to me?
2007-07-16 10:43 Can someone explain this git-blame/git-rev behavior to me? David Kastrup
2007-07-16 13:24 ` Johannes Sixt
@ 2007-07-16 23:13 ` Junio C Hamano
2007-07-17 9:57 ` David Kastrup
1 sibling, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2007-07-16 23:13 UTC (permalink / raw)
To: David Kastrup; +Cc: git
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).
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Can someone explain this git-blame/git-rev behavior to me?
2007-07-16 23:13 ` Junio C Hamano
@ 2007-07-17 9:57 ` David Kastrup
0 siblings, 0 replies; 6+ messages in thread
From: David Kastrup @ 2007-07-17 9:57 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can someone explain this git-blame/git-rev behavior to me?
@ 2007-07-16 16:38 David Kastrup
0 siblings, 0 replies; 6+ messages in thread
From: David Kastrup @ 2007-07-16 16:38 UTC (permalink / raw)
To: git
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-07-17 9:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-16 10:43 Can someone explain this git-blame/git-rev behavior to me? David Kastrup
2007-07-16 13:24 ` Johannes Sixt
[not found] ` <86ps2s736g.fsf@lola.quinscape.zz>
[not found] ` <469B9843.835B5356@eudaptics.com>
2007-07-16 20:41 ` David Kastrup
2007-07-16 23:13 ` Junio C Hamano
2007-07-17 9:57 ` David Kastrup
-- strict thread matches above, loose matches on Subject: below --
2007-07-16 16:38 David Kastrup
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).