Andrei Purdea <and...@purdea.ro> writes:
> diff --git a/read-cache.c b/read-cache.c
> index 2121b6e7b..ca306993c 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -262,9 +262,8 @@ static int ce_match_stat_basic(const struct
> cache_entry *ce, struct stat *st)
> changed |= match_stat_data(&ce->ce_stat_data, st);
>
> /* Racily smudged entry? */
> - if (!ce->ce_stat_data.sd_size) {
> - if (!is_empty_blob_sha1(ce->oid.hash))
> - changed |= DATA_CHANGED;
> + if (ce->ce_stat_data.sd_size == (unsigned int)-1) {
> + changed |= DATA_CHANGED;
> }
>
> return changed;
> @@ -2028,7 +2027,7 @@ static void ce_smudge_racily_clean_entry(struct
> cache_entry *ce)
> * file, and never calls us, so the cached size information
> * for "frotz" stays 6 which does not match the filesystem.
> */
> - ce->ce_stat_data.sd_size = 0;
> + ce->ce_stat_data.sd_size = (unsigned int)-1;
> }
> }
This is not a good idea. A change like this will break existing
installations where a zeroed size is understood as "not verified as
clean".
Is it infeasible to fix your clean-smudge filter pair to clean
and/or smudge zero-sized payload to empty? After all, it does not
help offloading the storing of blob that is known to be empty and
read another emptiness from the network or whatever external service
when the end result is known to be zero bytes anyway, no?
