Junio C Hamano wrote:
Mark Levedahl <mlevedahl@xxxxxxxxxxx> writes:
... Is it the case that
the size info stored in the index reflects the size of the blob rather
than of the working copy?
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.
I instrumented read-cache.c with:
@@ -818,6 +822,8 @@ int read_cache_from(const char *path)
struct cache_entry *ce = (struct cache_entry *) ((char *)
cache_mmap + offset);
offset = offset + ce_size(ce);
active_cache[i] = ce;
+ printf("name: %s\n", ce->name);
+ printf("size: %u\n", ntohl(ce->ce_size)
}
index_file_timestamp = st.st_mtime;
while (offset <= cache_mmap_size - 20 - 8) {
And I get, post commit:
name: foo
size: 21452
$ git-update-index
$ git-runstatus
...
name: foo
size: 20517
...
Note: foo's size with lf endings is 20517
with crlf endings is 21452
So, what I think is happening:
I add a file with crlf endings: it gets converted to lf, but the file
size with crlf is saved in the index.
Post commit, the file is replaced with lf endings in the working
directory and now has size 205167. However, the index reflects the
pre-converted file with crlf endings, not the post-converted with lf
endings.
Remember: I have core.autocrlf=input, so all files have lf on output.
Apparently the working file is updated by this process. The problem is
the index is not updated to reflect that.
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