Re: [PATCH 1/2] Teach git-describe to display distances from tags.
- From
Junio C Hamano <junkio@cox.net>
- Date
- Jan 25, 2007, 21:42 UTC
- Message-ID
- <7v7ivaailb.fsf@assigned-by-dhcp.cox.net>
- In-Reply-To
- <7vmz46ajcq.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
Show 32 quoted lines
>> ---
>> 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
430And it does not seem to be always "minus 3" either.