Re: Memory overrun in http-push.c

From: Andy Parkins <andyparkins@gmail.com>
To: git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Eygene Ryabinkin <rea-git@codelabs.ru>,
	Junio C Hamano <junkio@cox.net>, Alex Riesen <raa.lkml@gmail.com>
Subject: Re: Memory overrun in http-push.c
Date: Thu, 1 Mar 2007 19:31:30 +0000	[thread overview]
Message-ID: <200703011931.32170.andyparkins@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0703011941020.22628@wbgn013.biozentrum.uni-wuerzburg.de>

On Thursday 2007, March 01, Johannes Schindelin wrote:

> Got it.
>
> So, in a very real sense, we have file ids. Even tree ids. And commit
> ids.

Absolutely.  Moreso than CVS/SVN.  Putting $Id$ $Rev$ in a git managed 
file would have far more meaning that it does in a CVS managed file.

Actually, $Id$ covers the file hash; $Rev$ covers the commit hash.  I 
wonder if the tree id would be useful to finish the set?

The reason it's so hard to do is because putting the file id in the file 
would change the file, and hence its Id.  Ouch.  However, I reckon the 
upcoming gitattributes stuff is going to have no trouble keeping the 
file contents stable from git's point of view and yet let you 
mangle/unmangle the contents with this keyword stuff.

Actually once gitattributes exists we almost have to have a $Id$, the 
hash of the working directory file isn't stable because it might have 
had it's line endings mangled.  On the other hand we could argue that 
git-hash-object should have unmangling options anyway.

Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com