Re: Commit ID in exported Tar Ball

From: Junio C Hamano <junkio@cox.net>
Date: May 22, 2007, 22:54 UTC
Message-ID: <7vd50s79lg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46536E32.6000202@lsrfire.ath.cx>

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

Show 9 quoted lines

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

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();

 (2) teach ident substitution to expand "$commit$" to
     sprintf("$commit: %40s $", sha1_to_hex(commit_in_focus[])),
     and unexpand "$commit: .* $".

 (3) have git-archive set commit_in_focus[] before letting the
     convert_to_working_tree do its work.

 (4) later, we _might_ teach a single tree read-tree to also set
     up commit_in_focus[], so that:

	$ rm -f .git/index
        $ git checkout -f HEAD

     would expand "$commit$" in blobs.

This obviously have a lot of problems once we start adding the commit_in_focus[] to more random programs. Even two-tree read-tree case would behave in an unexpected way for an uninitiated person, if you do something like:

	$ git checkout master
        $ git checkout next

I am CC'ing Linus because he would literally hate me suggesting the above.