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

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

On Tue, Oct 13, 2026 at 01:29:46PM -0700, Junio C Hamano wrote:
> Curtis Allen Smith <curtis.allen.smith@gmail.com> writes:
> 
> > 	git status --short      # ->  M file.txt
> > 	git diff                # -> empty
> > 	git add file.txt        # -> nothing to commit
> 
> I do not think "git add" would ever say nothing to commit.
> 
> 	git commit file.txt
> 
> may say "nothing added to commit" when there is no modification made
> to file.txt to indicate that there is no change worth comitting.
> 
> There are code paths that make performance trade-offs (see the
> introductory part of Documentation/technical/racy-git.adoc for
> examples) and are designed to tolerate false positives from
> ie_modified(), filtering them out themselves.  I am somewhat
> hesitant to butcher code paths at this low level to make
> unconditional changes that reduce false positives without thinking
> things through.  For example, we may want to disable this new code
> when the 'CE_MATCH_RACY_IS_DIRTY' bit is set.  But the goal
> nevertheless should be to avoid surfacing these false positives,
> which are deliberately allowed as performance trade-offs, to code
> paths like 'git status' that do not further filter them out (as you
> demonstrated above).
> 
> There may be other cases where this patch unknowingly breaks
> carefully made performance trade-offs.


Looking at CE_MATCH_RACY_IS_DIRTY it seems as if the call
to would_convert_to_git()may be better done in ie_match_stat() ?


Beside that I was able to test it with a real live repo,
where a clean filter replaces a TAB with 4 spaces: Now
git status no longer claims the file to be modified
(and refuses to stash or other operations))

[snip]