Re: Commit ID in exported Tar Ball

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: May 21, 2007, 19:54 UTC
Message-ID: <4651F908.2000608@lsrfire.ath.cx>
In-Reply-To: <20070521060231.GI3141@spearce.org>

Shawn O. Pearce schrieb:

Show 16 quoted lines

> Ren?? Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>> Shawn O. Pearce schrieb:
>>> git-describe is more human-friendly than a SHA-1...
>> Yes, and the Makefile does even more than that: it adds a version file,
>> a spec file and another version file for git-gui.
>>
>> The first two are probably useful for most projects that actually do
>> versioned releases.  We could have a simple parser that reads a
>> template, replaces @@VERSION@@ with a git-describe output string and
>> adds the result as a synthetic file to the archive.  It's not exactly
>> trivial -- e.g., how to specify git-describe options, template file and
>> synthetic name, all in one command line parameter? -- but it's doable.
> 
> Maybe something just as simple as allowing the user to specify a
> shell script in-tree that we unpack and run for them?  That script
> prints to stdout the content of the file to include.

I doubt executing a shell script is simple. :-D You'd possibly get different results on different platforms (dare I mention Windows?).

The template system I mentioned would be a kind of scripting language itself, but in this case we define its syntax and can guarantee consistency everywhere git runs. And since it would only have four types of tokens (@@VERSION@@, @@COMMITID@@, @@@@ and string literals) it could be fast and simple.

We could implement it as a checkout converter, preferably one that is only applied by git-archive. Then we'd rename git.spec.in to git.spec, assign the "specfile" attribute to it and let git-archive replace the string @@VERSION@@ with git-describe's output. git-checkout would not expand the special strings, so you can simply edit and version the file as you can do with git.spec.in now. Michael would have a file containing only @@COMMITID@@ to solve his original problem. Make sense?

Show 5 quoted lines

> So now we're also really talking about, what should git-archive
> do for a subproject?  Sometimes you really do want to repackage
> and redistribute the subproject as part of the superproject's
> tarball. Sometimes you don't.  I think in the case of git.git and
> git-gui.git we want to include the subproject.  ;-)

Oh, yes, subprojects. git-archive currently exports them as empty directories. Using tar's append command you could simply build the project+subproject archive in the Makefile. That wouldn't work well with gitweb, though. Perhaps a --include-subproject=<path> option is needed?

René