Re: Commit ID in exported Tar Ball

From: Shawn O. Pearce <spearce@spearce.org>
Date: May 21, 2007, 06:02 UTC
Message-ID: <20070521060231.GI3141@spearce.org>
In-Reply-To: <46502EF7.6000708@lsrfire.ath.cx>

Ren?? Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:

Show 13 quoted lines

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