Re: Memory overrun in http-push.c

On Thursday 2007 March 01 20:43, Johannes Schindelin wrote:

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.

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.

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