Mark Levedahl wrote:
Junio C Hamano wrote:
The size field among other fields is to cache the last lstat(2)
information so that later "is the path modified?" question can
be answered efficiently. So the size should in general match
both blob and filesystem but on CRLF filesystems it is compared
against and updated with the data from the filesystem. There
could be a subtle bug that when updating an index entry we might
be incorrectly storing the size of the blob, but I haven't
checked.
Never mind: I should have triggered off the observation that something
was changing the file, but as far as I know git does not change the
working directory on commit and the autoCRLF code does not introduce
that "feature". My trusty old editor (visual slickedit) occasionally
corrupts its macros and starts doing strange and wonderful things,
always something I never saw before. In this case, I had foo open
(absent crlf endings) in it and and the editor was apparently re-saving
all of its files in the middle of my tests as I flipped between various
windows. Killing the editor stopped the behavior, rebuilding all the
macros from scratch got rid of the problem for good.
So, after all that, it appears that the index does reflect the size in
the working repository and the problems I was having were nothing to do
with git.
Sorry for the noise.
Mark
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html