All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: David Greaves <david@dgreaves.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>, git@vger.kernel.org
Subject: Re: setlocalversion wasn't producing git labels for bisect
Date: Sat, 30 Aug 2008 13:07:56 -0700	[thread overview]
Message-ID: <7vbpzagtb7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <48B9A2C7.3080001@dgreaves.com> (David Greaves's message of "Sat, 30 Aug 2008 20:43:03 +0100")

David Greaves <david@dgreaves.com> writes:

> Running
>   git name-rev --tags HEAD
> gives the output
>   HEAD tags/v2.6.27-rc4~44^2
>
> This isn't matched by setlocalversion regexp so it makes it harder to make deb-pkg/install/grub/reboot/remove
>
> Of course if this patch is accepted it is going to make life complicated when bisecting around it.
> Maybe git should behave as the man page suggests and have the ^X before the ~nnn? (maybe it has been fixed already)

Sorry, I don't understand what you are trying to fix here.

Your head can be reached by going 44 generations back (following the first
parent chain) from v2.6.27-rc4, which is a merge commit, and then taking
its second parent.  IOW the name-rev output you quoted represents this
history:

                                  v2.6.27-rc4
       ----o---o---o---....---o---o
          /^                  ^
         / v2.6.27-rc4~44     v2.6.27-rc4~1
        o
        ^ Your HEAD

Swapping ^X and ~nnn changes the meaning completely.  v2.6.27-rc4^2~44 is
the 44 generation ancestor of the second parent of -rc4, but v2.6.27-rc4
is *NOT* a merge and it does not have the second parent.

>   http://www.kernel.org/pub/software/scm/git/docs/v1.5.6.5/git-name-rev.html
> shows an example:
>   33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99^0~940

This says

    v0.99 is a tag, and dereference it (^0) to get to the commit that
    points at it, and then the commit in question (33db5f) is its 940th
    generation ancestor.

We used to explicitly say "it is a tag and dereference it" by adding ^0
but since Feb 2007 we stopped doing so because taking its 940th parent
can only be done to a commit, so v0.99~940 and v0.99^0~940 are equivalent.

We should fix the documentation, though.

  reply	other threads:[~2008-08-30 20:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-30 19:43 setlocalversion wasn't producing git labels for bisect David Greaves
2008-08-30 20:07 ` Junio C Hamano [this message]
2008-08-30 20:11 ` [PATCH] Fix example in git-name-rev documentation Junio C Hamano
2008-09-01 11:07   ` Johannes Schindelin
2008-08-31 10:15 ` [Regression] Re: setlocalversion wasn't producing git labels for bisect David Greaves
2008-08-31 10:15   ` David Greaves

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=7vbpzagtb7.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=david@dgreaves.com \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.