Re: What is in git.git

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 22, 2006, 20:26 UTC
Message-ID: <Pine.LNX.4.64.0601221512470.25300@iabervon.org>
In-Reply-To: <7vu0bwdo08.fsf@assigned-by-dhcp.cox.net>

On Sun, 22 Jan 2006, Junio C Hamano wrote:

Show 9 quoted lines

> I have been thinking about this one, and having read that
> read-cache code I think the coding is not too involved.
> 
> My current inclination is to use the same version number (2) by
> default and promote it to a new version number (3) once you add
> subproject-binding information to the index file.  Then current
> tools would keep working on repositories created or operated
> upon with the new tools, as long as the project does not use the
> new feature.

I think bumping the index file version number shouldn't be too big a deal; index files are rarely used by different versions, except for the case where you've installed a new version of git, and that's generally a later version, not an earlier one.

It might make sense to add logic to make the stable series accept version 3 files without special entries, though. And maybe future-proof by having it look for unexpected flags and give a "too new version" error for them, even if the version number is within range. (I.e., if we add more special entry types later, it would tell you if your index file uses a feature that the version of git you're using doesn't support, even if the version number hasn't changed, and we reserve changing the version number for things where the file wouldn't read right at all or something previously legal changes meaning.)

On a side topic, is there any reason not to convert ls-tree to use struct tree, and kill the other tree-object-parsing code, which doesn't seem to be used by anything else?

	-Daniel
*This .sig left intentionally blank*