Junio C Hamano schrieb: > René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes: > >> OK, so here's a first shot at the mentioned parser. It only understands >> @@COMMITID@@ and @@@@, but it's easily extendible. The internals of >> git-describe would need to be converted to library functions, preferably >> offering every piece of version info separately (see thread "[PATCH] >> Make sure an autogenerated version has at least four parts" for why). >> >> Before doing that, we should determine if this is the way to, though. >> >> René > > Hmmm. I am torn. > > It almost feels as if we'd better bite the bullet and do more > insane things in ident substitution, instead of introducing this > apparent syntax inconsistency between "$id$" and "@@COMMITID@@". $Id$ (and $commit$) is reversible, @@COMMITID@@ is not. That means you can create a synthetic file byte for byte with @@COMMITID@@ (and its not yet implemented brethren), but you can't do that with $Id$ -- it's impossible to get rid of the dollar signs. I'm not attached to any particular syntax. It all started with @@VERSION@@ from git.spec.in, which should not be implemented 1:1 anyway (we'd need to be able to use arbitrary separators between version parts to support different ways of ordering version numbers). We could use $ to indicate reversible substitutions as before and @ (instead of @@) for one-way substitutions. I can't think of any other use than in archives, though. It sure would be very confusing to have such a conversion happen on checkout -- you'd need to use git-cat-file to see the real file contents. > That is, we could (I am not seriously proposing to do this, as I > expect this will lead to a lot of insanity at the end): > > (1) introduce "const unsigned char commit_in_focus[20]", > globally available to git suite, and clear it at the > beginning of main(); Ugh. Requiring another global variable doesn't smell like good design. By the way, we already have a similar, but very different syntax: the one format_commit_message in commit.c. It's a one-way conversion, too. Maybe we should copy the relevant pieces like %H and %h from there.. Do we want git-archive specific one-way conversions that are capable of creating files like git.spec? Or is this just a shiny toy hypnotizing me? 8-) 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
