Re: What is in git.git

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

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*