Re: autoCRLF, git status, git-gui, what is the desired behavior?

[Junio C Hamano <junkio@cox.net>]

Junio C Hamano <junkio@cox.net> writes:

> Ah, I know what is going on.  "update-index --refresh" notices
> that lstat(2) says the size is different between what is
> recorded in the index, and does not actually compare and refresh
> the entry.
>
> But that is a very important optimization, and I do not think we
> would want to cripple that for autoCRLF.

It might be interesting to try this patch.

Usually we _trust_ the index and say that the path has been
modified if what its length on the filesystem returned by
lstat(2) does not match with what is recorded in the index.

What this patch does is to disable that optimization when
autocrlf is in effect.  The change would make all paths whose
size, read by lstat(2) from the filesystem, does not match what
is recorded in the index to be re-validated by comparing the
data, and if it is found not to have been modified, refresh the
index by updating the size information (and other information
such as mtime).  In other words, this would probably make it
prohibitibly expensive on autocrlf filesystems if you leave many
paths dirty to run update-index --refresh (hence status and
commit).


diff --git a/read-cache.c b/read-cache.c
index 605b352..11b8b56 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -225,11 +225,15 @@ int ce_modified(struct cache_entry *ce, struct stat *st, int really)
 	if (changed & (MODE_CHANGED | TYPE_CHANGED))
 		return changed;
 
-	/* Immediately after read-tree or update-index --cacheinfo,
+	/*
+	 * Immediately after read-tree or update-index --cacheinfo,
 	 * the length field is zero.  For other cases the ce_size
 	 * should match the SHA1 recorded in the index entry.
+	 * However, use of core.autocrlf can screw us up badly.
 	 */
-	if ((changed & DATA_CHANGED) && ce->ce_size != htonl(0))
+	if ((changed & DATA_CHANGED) &&
+	    ce->ce_size != htonl(0) &&
+	    !auto_crlf)
 		return changed;
 
 	changed_fs = ce_modified_check_fs(ce, st);