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

["Torsten Bögershausen" <tboegi@web.de>]

On 2026-10-08 22:45, Curtis Allen Smith wrote:

Disclaimer: My comments may be hard to read - they are intended to
be helpfull, but I struggled with my email-prgrams here.

> "git status", "git diff" and "git add" can disagree about whether a
> file has been modified.  Under
> 
> 	* text eol=lf
> 
> a tool that rewrites an otherwise unchanged file with CRLF endings
> makes "git status" report it as modified, while "git diff" shows
> nothing and "git add" stages nothing [snip]

Nit:... stages nothing to be committed.
It does update the index,
since the length of the file in the working tree has changed.

`git add` runs the clean filter, the working tree encoding, CRLF
conversion and the "indent" filter, if specified for a file.

[snip]
> That contradiction, rather than the line endings as such, is what
> this series is about.
good

> 
> The cause is the size comparison in ie_match_stat().  ie_modified()
> takes a difference between the file's size and the size recorded in
> the index as proof of a content change and returns without reading
> the file.
[snip] The following can be shortened, but I don't have a good suggestion
yet.

> The mtime branch of the very same function already reads
> the file and applies the conversion before deciding, so Git pays for skip

"Git pays" ? May be: does the correct thing.

> the conversion-aware check in one branch and refuses to in the other.
> 
> Patch 1 makes the size branch behave like the mtime branch whenever
> the path is subject to conversion.  Paths with no conversion take the
> existing early return untouched.  It also stops ce_compare_data()
> hashing a file whose converted length already differs from the size
> of its blob, since equal contents must have equal length; that is
> where most of the cost of the new check would otherwise go, and it
> helps the pre-existing mtime path as well.  When the end-of-line
> conversion is the only one that applies, that length comes from a
> scan for CR, and the file is not converted either.

Skip the rest: I don't think that an option turning this feature off
is needed.
Users which don't use CRLF conversion or any clean filters are not
affected by this path - or did I miss something ?
Users which use filters and/or CRLF should probably get the correct
answer from `git status`.
And yes, I think that this has happened to me as well - in my
case a tool insisting to replace 4 spaces with a TAB combined
with a clean filter that converted TAB into 4 spaces.
`git status` and `git diff` didn't agree, and I was never able to find
out why.

[snip]
> This was reported against Git for Windows [1], where Torsten suggested
> bringing it to the list.  It is not Windows-specific; anything with a
> clean filter runs into it, and Git LFS users on Linux see the same
> contradiction.

Yes.

> 
> Built with gcc 15.2 on top of 6de20f6; each commit builds and passes
> on its own.  t0020 (with the new tests), t0021, t0026, t0027, t1300,
> t2106, t2200, t3700, t7508 and t0008 pass.
> 
> [1] https://github.com/git-for-windows/git/issues/6410
I didn't dig deep into the code yet - that's for the future.
Thanks for working on this.