Re: A shortcoming of the git repo format

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 27, 2005, 20:56 UTC
Message-ID: <Pine.LNX.4.58.0504271352110.18901@ppc970.osdl.org>
In-Reply-To: <426FF8C4.8080809@zytor.com>

On Wed, 27 Apr 2005, H. Peter Anvin wrote:

> 
> I know that.  However, is that going to be true for all versions of the 
> repository format over all time?  If so, the repository format is brittle.

I agree, it's brittle by design, exactly because I think it's very important not to allow any variations.

HOWEVER, that's where "convert-cache" comes in. Any one particular format may be brittle, but if we accept that, and just say "we can upgrade by converting the cache", then we should be ok. IOW, we can change from one brittle format with 160-bit SHA1 names to _another_ brittle format with 256-bit SHA1 (or other) names.

> My point was that with a syntactic delimiter, one can write a tool that 
> doesn't necessarily know everything about every tag, including future 
> tags which may not have been invented when the tool was written.

Now, I kind of agree with that, but not on a "object level".

But exactly because the object level is "brittle by design", and because I the way to fix that is convert-cache (which may do _big_ changes to the format), I really don't think that the objects should ever be looked at except with very precise tools.

But when it comes to "higher-level information", I agree with you 100%.

For example, this _is_ actually why I wanted pasky to change the format of "git log" (now cg-log). Exactly so that the output of that isn't brittle, it now prepends spaces to the free-form part.

		Linus