Re: [PATCH 5/7] tmp-objdir: new API for creating and removing primary object dirs

From: Jeff King <peff@peff.net>
Date: Sep 30, 2021, 07:46 UTC
Message-ID: <YVVrY0/kXfWHCWJ1@coredump.intra.peff.net>
In-Reply-To: <YVVmssXlaFM6yD5W@coredump.intra.peff.net>

On Thu, Sep 30, 2021 at 03:26:42AM -0400, Jeff King wrote:

Show 8 quoted lines

> > > If you remove the tmp_objdir as the primary as soon as you're done with
> > > the merge, but before you run the diff, you might be OK, though.
> > 
> > It has to be after I run the diff, because the diff needs access to
> > the temporary files to diff against them.
> 
> Right, of course. I was too fixated on the object-write part, forgetting
> that the whole point of the exercise is to later read them back. :)

Ah, no, I remember what I was trying to say here. The distinction is between "remove the tmp_objdir" and "remove it as the primary".

I.e., if you do this:

  1. create tmp_objdir

  2. make tmp_objdir primary for writes

  3. run the "merge" half of remerge-diff, writing objects into the
     temporary space

  4. stop having tmp_objdir as the primary; instead make it an alternate

  5. run the diff

  6. remove tmp_objdir totally

Then step 5 can't accidentally write objects into the temporary space, but it can still read them. So it's not entirely safe, but it's safer, and it would be a much smaller change.

Some ways it could go wrong:

  - is it possible for the merge code to ever write an object? I kind of
    wonder if we'd ever do any cache-able transformations as part of a
    content-level merge. I don't think we do now, though.

  - in step 5, write_object_file() may still be confused by the presence
    of the to-be-thrown-away objects in the alternate. This is pretty
    unlikely, as it implies that the remerge-diff wrote a blob or tree
    that is byte-identical to something that the diff wants to write.

-Peff