Re: [PATCH v3/RFC 1/1] read-cache: do not trust a size change when conversion is active

[Johannes Sixt <j6t@kdbg.org>]

Am 12.10.26 um 19:56 schrieb tboegi@web.de:
> @@ -438,6 +439,27 @@ int ie_match_stat(struct index_state *istate,
>  	return changed;
>  }
>  
> +/*
> + * A difference between the size of the file in the working tree and the
> + * size recorded for it in the index proves that the contents changed
> + * only as long as the two are byte-for-byte comparable.  That stops
> + * being true as soon as the path is run through a clean filter:

I cannot agree with this reasoning. The index is a cache of the stat
information. The size recorded in the index is only used as a clue
whether the file was changed or not. It does *not* record the size of
the data that the object database holds for the blob.

If your analysis found that, after the content was `git add`-ed, the
size in the index is *not* identical to the size taken from the
filesystem, then the problem is that an incorrect size was put into the
index, and not that the size between the blob data in the database and
the filesystem's file are different (and unusable).

> + * rewriting a file with CRLF endings under "text eol=lf", for example,
> + * changes its size in the working tree without changing the blob Git
> + * would record for it.  For such a path the only way to tell is to read
> + * the contents and convert them, which is what we already do when only
> + * the mtime changed.
> + */

-- Hannes