Re: Commit ID in exported Tar Ball

["Shawn O. Pearce" <spearce@spearce.org>]

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'm not sure how the git-gui version file fits in.  I guess it's just a
> special case and doesn't need git-archive support?

Well, if you look at git-gui's own version script it really just
wants to do `git-describe` like git.git's script, but it cannot as
when its hosted in git.git `git-describe` gives us back Git's version
number, not git-gui's version number.  So we get cute and look for
the merge commit, and take the second parent, and describe that.
That's (by convention of how Junio works) always a true git-gui
commit.

In other words, git-gui.git gets a little whacky when Junio
distributes it in git.git.  git-gui really needs to become
a subproject.  When that happens its git-describe will become
much easier.

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

-- 
Shawn.