Re: [PATCH v2] multi-pack-index: fix *.rev cleanups with --object-dir

From: Derrick Stolee <stolee@gmail.com>
Date: Aug 23, 2021, 18:00 UTC
Message-ID: <35654780-b0f7-d1b1-d7a1-0365e42f63b4@gmail.com>
In-Reply-To: <YSPWQtOjKVgIKqsd@nand.local>

On 8/23/2021 1:09 PM, Taylor Blau wrote:

Show 15 quoted lines

> 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