Re: git bugs

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 11, 2008, 18:10 UTC
Message-ID: <alpine.LFD.1.10.0806111105150.3101@woody.linux-foundation.org>
In-Reply-To: <832adb090806111052p32a750c2n5f2d43e0ed1b910d@mail.gmail.com>

On Wed, 11 Jun 2008, Ben Lynn wrote:

Show 22 quoted lines

> 
> I don't think the memcmp is slow. I think the ce_modified_check_fs in:
> 
> smudge() {
>    ...
>   if (ce_match_stat_basic(ce, &st))
>                 return;
>   if (ce_modified_check_fs(ce, &st))
>                 ce->ce_size = 0;
> }
> 
> is potentially slow, and I'm saying you could replace it with
> 
> smudge() {
>    ...
>   if (ce_match_stat_basic(ce, &st))
>                 return;
>   ce->ce_size = ~0;
> }
> 
> to avoid the ce_modified_check_fs call. But it is an unclean solution,
> which is why I champion having an extra flag per file.

Well, you have to think about what you want to optimize here.

The thing we want to optimize is not the writing of the index file, but the subsequent _use_ of it!

As such, the last thing we actually want to do is to smudge the index file entry. If it actually has a possibility of being not smudged, we're much better off saying "hey, now the index file is newer, and the file it refers to is all good!"

That way, we won't have to do the ce_modified_check_fs() call later - we do it just once, and the file is up-to-date.

So we don't want to smudge it, but if the stat information says it migth match even though it doesn't, we have to. But if the stat information says it matches, and the data actually _does_ match, then we shouldn't smudge it, we should be happy - and all subsequent users of the index will then know that they don't even need to look at the file contents.

			Linus