Re: Commit ID in exported Tar Ball

["René Scharfe" <rene.scharfe@lsrfire.ath.cx>]

Shawn O. Pearce schrieb:
> 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?

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