Shawn O. Pearce schrieb: > Ren?? Scharfe <rene.scharfe@xxxxxxxxxxxxxx> 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é - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
