On Fri, 2 Mar 2007, Andy Parkins wrote: > What about this though: > * Tag a release > * Export the working tree into a fresh directory > * Edit each source file to put the hash of the tagged revision into > every file. > * Edit the makefile to include the tag hash in the released version > * tar it up > * Release > It's such a mundane, useless waste of time to edit the hash in by hand - why > can't the version control system do it? Actually, how about doing keyword expansion just like the new CRLF handling? Have the text filter replace $Id...$ with $Id$ going into the database, and $Id$ with $Id <info>$ coming out of the database. The info could even include the commit (although that might be confusing for files that you haven't changed since you checked them out, and when you checked them out, they weren't changed in that commit; the commit would be a sort of arbitrary choice among commits that have that file). It seems to me like keywords fit the pattern we now have (with CRLF-conversion) of data which isn't tracked, but is present in working directory files. In the CRLF case, it's a constant character (CR), but there's no reason we couldn't have the non-canonical form depend on more information. (And we'd beat CVS/SVN for accuracy: if keyword substitution isn't on, nothing appears in $Id$ tags, rather than being left with something inaccurate). -Daniel *This .sig left intentionally blank* - 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