From: Junio C Hamano <gitster@pobox.com>
To: David Kastrup <dak@gnu.org>
Cc: git@vger.kernel.org
Subject: Re: Can someone explain this git-blame/git-rev behavior to me?
Date: Mon, 16 Jul 2007 16:13:50 -0700 [thread overview]
Message-ID: <7v7ip02b81.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <86sl7oaasx.fsf@lola.quinscape.zz> (David Kastrup's message of "Mon, 16 Jul 2007 12:43:26 +0200")
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).
next prev parent reply other threads:[~2007-07-16 23:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2007-07-17 9:57 ` David Kastrup
-- strict thread matches above, loose matches on Subject: below --
2007-07-16 16:38 David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v7ip02b81.fsf@assigned-by-dhcp.cox.net \
--to=gitster@pobox.com \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).