On Tue, Sep 21, 2021 at 6:27 PM Neeraj Singh <nksingh85@xxxxxxxxx> wrote: > > On Tue, Sep 21, 2021 at 4:53 PM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: > > > > All of this makes me wonder why this isn't using tmp-objdir.c, i.e. we > > could have our cake and eat it too by writing the "real" objects, and > > then just renaming them between directories instead. But perhaps the > > answer has something to do with the metadata issues I raised. > > > > And well, tmp-objdir.c isn't going to help someone in practice that's > > relying on this "update-index --stdin" behavior, as they won't know > > where we staged the temporary files... > > > > One motivation of the current design behind renaming the files is that > some networked filesystems don't seem to like cross-directory renames > much. It also so happens that ReFS on Windows also prefers renames to > stay within the directory. Actually any filesystem would likely be > slightly faster, > since fewer objects are being modified (one dir versus two). Whelp, as part of v5 I tried to make unpack-objects.c use the batch fsync mode and now I see a strong reason to take your tmp-objdir suggestion. As part of OBJ_REF_DELTA unpacking, we need access to the object while we're in the plugged state. I didn't notice this at first, but got lucky that I tested that case first and hit an error. V5 will create a tmp-objdir and add a new interface to install it as the primary objdir.
