Daniel Barkalow [off-list ref] writes:
I think you're misunderstanding the use of the "bind" file or equivalent.
...
So moving back to (A) wouldn't keep the binding point of subproject,
because it would rewrite bind to what it had been.
A lot better said than my version of the response. Thanks.
I'm going to suggest again keeping this information in the index file (but
not in the index data structure, so the changes to the code are only in
the library routines to read and write the file, and, of course, anything
that's actually trying to manipulate the binding locations). I started
working on a patch to pu to skip S_IFDIR entries from the index file when
building the table in memory, and that was straightforward, but I got into
sysadmin issues when I was going to test giving it something to skip.
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.
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*