From: Junio C Hamano <junkio@cox.net>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] Teach git-describe to display distances from tags.
Date: Thu, 25 Jan 2007 13:42:56 -0800 [thread overview]
Message-ID: <7v7ivaailb.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7vmz46ajcq.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Thu, 25 Jan 2007 13:26:29 -0800")
Junio C Hamano <junkio@cox.net> writes:
>> ---
>> builtin-describe.c | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/builtin-describe.c b/builtin-describe.c
>> index e7b8f95..d8ff621 100644
>> --- a/builtin-describe.c
>> +++ b/builtin-describe.c
>> @@ -189,7 +189,8 @@ static void describe(const char *arg, int last_one)
>> sha1_to_hex(gave_up_on->object.sha1));
>> }
>> }
>> - printf("%s-g%s\n", all_matches[0].name->path,
>> + printf("%s-%i-g%s\n", all_matches[0].name->path,
>> + all_matches[0].depth,
>> find_unique_abbrev(cmit->object.sha1, abbrev));
>>
>> if (!last_one)
>
> Two comments.
>
> - This is purely style, but we seem to prefer %d instead of %i
> elsewhere in the code (three existing offenders are
> builtin-describe.c, receive-pack.c and sha1_file which we may
> want to clean up for consistency).
>
> - How much damage are we talking about with this patch to
> People's existing scripts? I expect they all extract the
> hash from last -g (because they cannot rely on particular
> convention in tagnames), but I am also worried if people are
> expecting everything that comes before the last -g is the
> whole tag.
Actually there is a third one and a half.
- We need to update the documentation to say what this new
number means.
It's some number close to the number of revs since the named
tag, but not exactly.
$ git describe --debug 65ebe634 2>&1 | head -4
searching to describe 65ebe634
annotated 251 v2.6.20-rc5
annotated 427 v2.6.20-rc4
annotated 594 v2.6.20-rc3
$ git rev-list v2.6.20-rc5..65ebe634 | wc -l
254
$ git rev-list v2.6.20-rc4..65ebe634 | wc -l
430
And it does not seem to be always "minus 3" either.
next prev parent reply other threads:[~2007-01-25 21:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 17:39 [PATCH 1/2] Teach git-describe to display distances from tags Shawn O. Pearce
2007-01-25 21:26 ` Junio C Hamano
2007-01-25 21:37 ` Shawn O. Pearce
2007-01-25 21:42 ` Junio C Hamano [this message]
2007-01-25 21:49 ` Shawn O. Pearce
2007-01-25 23:32 ` Nicolas Pitre
2007-01-26 0:13 ` Junio C Hamano
2007-01-26 8:52 ` Francis Moreau
2007-01-26 9:00 ` Junio C Hamano
2007-01-26 9:39 ` Francis Moreau
2007-01-26 9:51 ` Shawn O. Pearce
2007-01-26 10:36 ` Andy Parkins
2007-01-26 14:28 ` [PATCH] If abbrev is set to zero in git-describe, don't add the unique suffix Andy Parkins
2007-01-26 13:33 ` [PATCH 1/2] Teach git-describe to display distances from tags Jakub Narebski
2007-01-26 19:37 ` Matthias Lederhofer
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=7v7ivaailb.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.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.