Re: Commit ID in exported Tar Ball

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: May 22, 2007, 23:44 UTC
Message-ID: <46538065.9080705@lsrfire.ath.cx>
In-Reply-To: <7vd50s79lg.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano schrieb:

Show 17 quoted lines

> 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.

Show 6 quoted lines

> 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é