Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> The other approach is to know that an empty blob always has a very
> specific SHA1. Here's an trial patch.
> read-cache.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 8e5fbb6..f83de8c 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> ...
> @@ -193,6 +203,12 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
> if (ce->ce_size != (unsigned int) st->st_size)
> changed |= DATA_CHANGED;
>
> + /* Racily smudged entry? */
> + if (!ce->ce_size) {
> + if (!is_empty_blob_sha1(ce->sha1))
> + changed |= DATA_CHANGED;
> + }
> +
> return changed;
> }
Thanks. This would be a good fix to the issue.
The only theoretical worry I can think of is if there is an insane
convert_to_worktree() filter that turns a non-empty blob into an empty
work tree file.
An "In blobs, always store everything as UTF16 with BOM" filter, when
badly implemented, might turn an empty work tree file into a blob with BOM
and nothing else in it, but we can safely declare that such use case is
simply insane and broken ;-).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
