On Thu, Sep 30, 2021 at 03:26:42AM -0400, Jeff King wrote:
> > > 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
