On 8/23/2021 1:09 PM, Taylor Blau wrote: > On Mon, Aug 23, 2021 at 07:05:31PM +0200, Johannes Berg wrote: >> On Mon, 2021-08-23 at 12:06 -0400, Jeff King wrote: >>> I'm not entirely convinced that writing a midx when not "inside" a repo >>> is something that we want to support. But if we do, then... >> >> Seemed like that was the point of --object-dir? > > Stolee (cc'd) would know more as the original author, but as I recall > the point of `--object-dir` was to be able to write a midx in > directories which were acting as Git repositories, but didn't contain a > `.git` directory. > > It's kind of a strange use-case, but I recall that it was important at > the time. Maybe he could shed more light on why. (Either way, we're > stuck with it ;)). Yes, the point was for how VFS for Git (and now Scalar) built the "shared object cache" directory. This is a directory that acts as an alternate for VFS for Git and Scalar clones so objects downloaded by one enlistment are immediately available in another. When the multi-pack-index was created, it was designed to handle this shared object cache through the --object-dir parameter. There are custom patches in microsoft/git that shoehorn the option into background maintenance via a config value. If I were to redesign the feature for use by Git, then I would make the clones create a bare copy of the repository (if it doesn't already exist) and then create a worktree of that bare repo. The key is to allow users to delete individual worktrees without losing the object data. In summary, there is a reason for its design like this, although its due to an external tool. But we are using it a lot, so I'd prefer that it stay. Thanks, -Stolee
