RE: git filter bug

["Shupak, Vitaly" <Vitaly.Shupak@deshaw.com>]

Here's the behavior that I observe:
- If the mtime of the normal file changes from what's in the index but the content doesn't change, "git status" updates the index with the latest timestamp of the file.
- If the filtered file changes, but the size stays the same, git status also triggers an index update.
- BUT if the size of the filtered file changes, then the index does NOT get updated and the file appears modified on every git status run until you explicitly run "git add <filename>" again. This is true even if the post-clean filter content is the same as what's currently in the index.
- The clean filter runs on every "git status" call anyway, so this behavior does not appear to be an optimization.

So if a file is modified such that the post-clean filter content is the same as what's in the index, "git status" will show the file as modified only if the file size has also changed. It seems that perhaps "git status" is comparing file sizes before applying the clean filter to see if the index entry needs to be refreshed? 

Vitaly

-----Original Message-----
From: Johannes Sixt <j6t@kdbg.org> 
Sent: Monday, June 13, 2022 5:15 PM
To: Junio C Hamano <gitster@pobox.com>
Cc: Udoff, Marc <Marc.Udoff@deshaw.com>; Shupak, Vitaly <Vitaly.Shupak@deshaw.com>; git@vger.kernel.org
Subject: Re: git filter bug

This message was sent by an external party.


Am 13.06.22 um 19:29 schrieb Junio C Hamano:
> Johannes Sixt <j6t@kdbg.org> writes:
>
>> git status does not compute differences; it only looks at the stat 
>> information, and that is by design for performance reasons. So, IMO, 
>> this is working as designed and not a bug.
>
> Hmph, is that true?  I thought "git status" did an equivalent of 
> diff.autoRefreshIndex just like other commands like "git diff" at the 
> Porcelain level.

Is it true? I don't know; you tell me ;) git status certainly does autoRefreshIndex, but is that based on a diff computation? I thought git status looks only at stat information.

> Is this more like the commonly seen "after you futzed the attributes 
> to affect normalization, "--renormalize" is needed to force the index 
> to match the cleaned version of working tree under the new clean 
> filter rules", I wonder?

Not in this case. The modified file that git status reports happens long after git commit -a has already applied the new filter.

-- Hannes