Re: Add a "git-describe" command

From: Junio C Hamano <junkio@cox.net>
Date: Dec 28, 2005, 00:42 UTC
Message-ID: <7v7j9q3vdu.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0512241409300.14098@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 17 quoted lines

> The problem is not that it generates GIT_VERSION wrong. The problem is 
> two-fold:
>  - it should notice when "git-describe" doesn't exist, and fall back on 
>    the old less-than-descriptive behaviour
>  - it doesn't do dependencies correctly (ie it should now make "git" 
>    depend on the version number, but it doesn't, so it doesn't re-build 
>    git after a commit/pull)
>
> but at least it shows the _idea_ of using git-describe.
>
> With this I get
>
> 	[torvalds@g5 git]$ git --version
> 	git version v1.0.4-g6e9961d6
>
> which I think is better than "1.0.GIT" which doesn't say anything about 
> what the _actual_ version was.

I do not think 1.0.GIT is a good name either, so obviously there is a room for improvement.

One problem with git-describe is that getting tags is a concious user action, and you need to do "git fetch --tags" from time to time in order to see the v1.0.4-g6e9961d6 name. It could well say v1.0.3-g6649c466 if the end user has built on top of otherwise fully up-to-date maint branch without fetching v1.0.4 nor v1.0.5 tags, so when we learn that the v1.0.3-g6649c466 does not work for an end-user, it would not help us to look for regression between v1.0.3 and v1.0.4. All it tells us is that it is not older than v1.0.3, and it may well be the v1.0.5 without any local modification.