On Thursday 2007 March 01 20:43, Johannes Schindelin wrote: > > Putting $Id$ $Rev$ in a git managed file would have far more meaning > > that it does in a CVS managed file. > > No. My point was that you do not even have to have an id. The hash of the > object is the id. I think you're thinking of these tags in too strict terms. You're right they aren't /needed/ you can query the version control system for the information. However, if you sent them out in a tarball to someone who didn't have or want to have your version control system, then it is much easier for them to be able to tell you the $Id$ field from the file itself than to generate the hash or send you a copy of the file. They're purely for information. As I've mentioned before, personally the only place I use them is in inkscape SVG files (thank the lord SVG's are ASCII), where I add a text field that appears on the diagram itself and I write $Id$ as the text. Then whenever I print that diagram out (which makes it much harder to hash), I will know which version of the file I'm looking at. This is the /only/ thing I miss from subversion. > This is obviously much better than the mess of CVS/SVN's file ids. There > is an option, even, to switch off key expansion, so you can have erroneous > ids. That just cannot happen with hashes. As I said, I don't think anyone ever imagines that these Id fields are absolute guarantees of correctness - nor does any version control system /ever/ read them and use them. They are there only as a convenience for the user. Obviously, I could just edit the $Id$ anyway if I wanted, so it obviously isn't absolute. > Of course, it does not give you any hint about when this file was current. > But there is no way to tell in distributed development _anyway_. You have > to look it up, when, and who, changed the file to the current state. 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? It's already nearly there in the form of git-describe. It's only purpose is to supply strings that describe the current revision. Well, so would $Id$, but for files instead. I don't see that keywords are the evil they're made out to be; they're for convenience, not for absolute truth. When some random printout of the source turns up, at least the $Id$ might give you a clue as to which version it is. If it doesn't, well you're no worse off. Here's another similar idea: generating copyright lines. Let's say we want to copyright every source file - that means writing "(C) Junio, (C) Johannes, etc" at the top of every file. Wouldn't it be nicer if we could put $Copyright$ in the file, then have some git-blame-like machinery fill in the copyrights automatically based on who's made contributions? e.g. git-blame refs.c | sort -f 2 | uniq -c -s 10 -w 10 | sort -nr Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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