From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Tue, 22 May 2007 23:44:37 GMT
Subject: Re: Commit ID in exported Tar Ball
Message-ID: <46538065.9080705@lsrfire.ath.cx>
In-Reply-To: <7vd50s79lg.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano schrieb:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> 
>> OK, so here's a first shot at the mentioned parser.  It only understands
>> @@COMMITID@@ and @@@@, but it's easily extendible.  The internals of
>> git-describe would need to be converted to library functions, preferably
>> offering every piece of version info separately (see thread "[PATCH]
>> Make sure an autogenerated version has at least four parts" for why).
>>
>> Before doing that, we should determine if this is the way to, though.
>>
>> René
> 
> Hmmm.  I am torn.
> 
> It almost feels as if we'd better bite the bullet and do more
> insane things in ident substitution, instead of introducing this
> apparent syntax inconsistency between "$id$" and "@@COMMITID@@".

$Id$ (and $commit$) is reversible, @@COMMITID@@ is not.  That means you
can create a synthetic file byte for byte with @@COMMITID@@ (and its not
yet implemented brethren), but you can't do that with $Id$ -- it's
impossible to get rid of the dollar signs.

I'm not attached to any particular syntax.  It all started with
@@VERSION@@ from git.spec.in, which should not be implemented 1:1 anyway
(we'd need to be able to use arbitrary separators between version parts
to support different ways of ordering version numbers).

We could use $ to indicate reversible substitutions as before and @
(instead of @@) for one-way substitutions.  I can't think of any other
use than in archives, though.  It sure would be very confusing to have
such a conversion happen on checkout -- you'd need to use git-cat-file
to see the real file contents.

> That is, we could (I am not seriously proposing to do this, as I
> expect this will lead to a lot of insanity at the end):
> 
>  (1) introduce "const unsigned char commit_in_focus[20]",
>      globally available to git suite, and clear it at the
>      beginning of main();

Ugh.  Requiring another global variable doesn't smell like good design.

By the way, we already have a similar, but very different syntax: the
one format_commit_message in commit.c.  It's a one-way conversion, too.
 Maybe we should copy the relevant pieces like %H and %h from there..

Do we want git-archive specific one-way conversions that are capable of
creating files like git.spec?  Or is this just a shiny toy hypnotizing
me? 8-)

René