On Wed, Mar 13, 2019 at 10:22:46PM -0400, Jeff King wrote: > 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
