From: "René Scharfe" <rene.scharfe@lsrfire•ath.cx>
To: git@vger•kernel.org
Cc: git@vger•kernel.org, Junio C Hamano <junkio@cox•net>,
Frank Lichtenheld <frank@lichtenheld•de>,
Johan Herland <johan@herland•net>,
Thomas Glanzmann <thomas@glanzmann•de>,
Michael Gernoth <simigern@cip•informatik.uni-erlangen.de>
Subject: Re: Commit ID in exported Tar Ball
Date: Mon, 21 May 2007 21:54:48 +0200 [thread overview]
Message-ID: <4651F908.2000608@lsrfire.ath.cx> (raw)
In-Reply-To: <20070521060231.GI3141@spearce.org>
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é
next prev parent reply other threads:[~2007-05-21 19:56 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-17 16:38 Commit ID in exported Tar Ball Thomas Glanzmann
2007-05-17 16:57 ` Johan Herland
2007-05-17 17:11 ` Frank Lichtenheld
2007-05-17 17:14 ` Thomas Glanzmann
2007-05-17 17:28 ` Johan Herland
2007-05-18 22:09 ` [PATCH] git-archive: convert archive entries like checkouts do René Scharfe
2007-05-18 22:27 ` Daniel Barkalow
2007-05-18 22:58 ` René Scharfe
2007-05-19 20:22 ` Commit ID in exported Tar Ball René Scharfe
2007-05-19 21:00 ` Junio C Hamano
2007-05-19 21:39 ` A Large Angry SCM
2007-05-20 0:15 ` René Scharfe
2007-05-20 11:20 ` René Scharfe
2007-05-20 3:57 ` Shawn O. Pearce
2007-05-20 11:20 ` René Scharfe
2007-05-21 6:02 ` Shawn O. Pearce
2007-05-21 12:09 ` Petr Baudis
2007-05-21 19:54 ` René Scharfe [this message]
2007-05-22 22:26 ` René Scharfe
2007-05-22 22:54 ` Junio C Hamano
2007-05-22 23:44 ` René Scharfe
2007-05-23 5:22 ` Shawn O. Pearce
2007-05-20 11:20 ` René Scharfe
2007-05-20 16:10 ` Thomas Glanzmann
2007-05-20 16:28 ` Brian Gernhardt
2007-05-20 16:30 ` Thomas Glanzmann
2007-05-21 6:19 ` Peter Baumann
2007-05-21 6:24 ` Thomas Glanzmann
2007-05-21 6:29 ` Shawn O. Pearce
2007-05-21 6:37 ` Thomas Glanzmann
2007-05-21 6:53 ` Shawn O. Pearce
2007-05-21 7:00 ` Thomas Glanzmann
2007-05-21 6:56 ` Brian Gernhardt
2007-05-21 7:02 ` Thomas Glanzmann
2007-05-17 17:48 ` Frank Lichtenheld
2007-05-17 18:05 ` Johan Herland
2007-05-17 17:02 ` Kristian Høgsberg
2007-05-17 17:13 ` Thomas Glanzmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4651F908.2000608@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire$(echo .)ath.cx \
--cc=frank@lichtenheld$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=johan@herland$(echo .)net \
--cc=junkio@cox$(echo .)net \
--cc=simigern@cip$(echo .)informatik.uni-erlangen.de \
--cc=thomas@glanzmann$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox