Re: [PATCH 4/4] get_oid(): when an object was not found, try harder

From: Jeff King <peff@peff.net>
Date: Mar 14, 2019, 02:40 UTC
Message-ID: <20190314024023.GA3889@sigill.intra.peff.net>
In-Reply-To: <20190314022245.GA1414@sigill.intra.peff.net>

On Wed, Mar 13, 2019 at 10:22:46PM -0400, Jeff King wrote:

Show 25 quoted lines

> Try this:
> 
> -- >8 --
> mkfifo in
> (git cat-file --batch-check <in) &
> exec 9>in
> 
> git commit --allow-empty -m one
> git commit --allow-empty -m two
> 
> git rev-parse --short HEAD^ >&9
> git repack -adk
> git rev-parse --short HEAD >&9
> -- >8 --
> 
> The second object will (usually) be reported as "missing", even though
> by calling reprepare_packed_git(), we would then find it in the
> packfile.
> 
> I say "usually" because if the two commits have the same first-byte to
> their sha1, then we'd load both into the loose cache during the first
> request, and use that during the second request.
> 
> After this patch, it works consistently (we flush both the loose cache
> and the cached set of packs, and find the packed version).

By the way, an interesting implication of this is that we're doing the re-prepare only when we come up with no object. But we _could_ actually come up with the wrong object when we should say "ambiguous". I.e., the user asks for 1234abcd. We have 1234abcde in a pack, and 1234abcdf loose. A simultaneous process repacks, and we see neither copy of 1234abcdf, reporting that 1234abcde is the right answer.

I'm not sure it's really worth addressing (just because I don't think there's a good way to do it that isn't expensive).

-Peff