Re: git bugs
- From
Ben Lynn <benlynn@gmail.com>
- Date
- Jun 11, 2008, 17:52 UTC
- Message-ID
- <832adb090806111052p32a750c2n5f2d43e0ed1b910d@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.1.10.0806110752550.3101@woody.linux-foundation.org>
> I'm not sure why you think my patch that just did the zero-sized blob > thing was slow? It's a 20-byte memcmp(). It takes no time at all.
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.
Also, I think we could set ce->ce_size to ~0 when we first realize timestamp = mtime, and we'd no longer have to do index-wide smudging on writes.
Thanks for the explanation by the way. I get why you can't modify the SHA1. It is indeed what we asked git to record, right or wrong. I got confused because I misread the code and thought ce_modified_check_fs() would write the new SHA1 to disk.
-Ben