On Fri, Jun 05, 2015 at 12:01:16PM +0000, [email protected] wrote:
> On Sunday, May 24, 2015 @ 10:01 AM Duy Nguyen [mailto:[email protected]] did > scribble: > > > In case you want to back away from option 2 because it starts to leak > > raciness, which your old commit tried to fix in the first place. I > > think the only other place that tests for lots of non-existent loose > > objects is write_sha1_file (e.g. "tar -xf bigtarball.tar.gz; cd > > bigtarball; git init; git add ."). But the number of calls should be > > much smaller compared to index-pack and it does not use has_sha1_file, > > it uses check_and_freshen_file() instead. > > > > There are other places where has_sha1_file() may return 0, but I think > > the number of calls is even smaller to bother (shallow.c, > > fetch-pack.c, apply.c, buik-checkin.c) > > Any updates / further thoughts on this? Sorry, I haven't had a chance to look at it further. It still on my todo list. My plan is: 1. Devise some torture to tests to see whether my patch series is in fact racy on Linux. 2. Assuming it is, scrap it and make a has_sha1_file_quick() which might sometimes return a false negative (if somebody else is repacking). Use that in index-pack (and possibly other places, but we can start with index-pack). If we skip step 1 out of pessimism (which I think is a reasonable thing to do), then step 2 should not be all that much work. I'm going to be offline for a few days, though, so I won't get to it until next week at the earliest. If you (or someone else) wants to take a stab at it, please feel free. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
