Re: Memory overrun in http-push.c

[Andy Parkins <andyparkins@gmail.com>]

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@gmail.com