Re: [PATCH v5 0/4] Per-worktree config file support

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 19, 2017, 12:09 UTC
Message-ID: <CACsJy8BHgc8o+SydeiVnqaZRCbkJEWVzqDZM4sgey04ZLtG3tQ@mail.gmail.com>
In-Reply-To: <CAGZ79ka+zkr83tSkg_kJWoN1u3fgu1O3u1-7USEoSM1tj-53vA@mail.gmail.com>

On Wed, Jan 11, 2017 at 12:01 AM, Stefan Beller <sbeller@google.com> wrote:

Show 26 quoted lines

> On Tue, Jan 10, 2017 at 3:25 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>> Let's get this rolling again. To refresh your memory because it's half
>> a year since v4 [1], this is about letting each worktree in multi
>> worktree setup has their own config settings. The most prominent ones
>> are core.worktree, used by submodules, and core.sparseCheckout.
>
> Thanks for getting this rolling again.
>
>>
>> This time I'm not touching submodules at all. I'm leaving it in the
>> good hands of "submodule people". All I'm providing is mechanism. How
>> you use it is up to you. So the series benefits sparse checkout users
>> only.
>
> As one of the "submodule people", I have no complaints here.
>
>>
>> Not much has changed from v4, except that the migration to new config
>> layout is done automatically _update_ a config variable with "git
>> config --worktree".
>>
>> I think this one is more or less ready. I have an RFC follow-up patch
>> about core.bare, but that could be handled separately.
>
> I have read through the series and think the design is sound for worktrees
> (though I have little knowledge about them).

Submodules and multi worktrees start to look very similar, the more I think about it. Well, except that multi worktree does not separate odb and config files, maybe. And we have already seen both have a need to share code (like the moving .git dir operation). I suspect I'll learn more about submodules along the way, and you worktrees ;-)

Show 20 quoted lines

> Now even further:
>
> So to build on top of this series, I'd like to make submodules usable
> with worktrees (i.e. shared object store, only clone/fetch once and
> all worktrees
> benefit from it), the big question is how to get the underlying data
> model right.
>
> Would a submodule go into the superprojects
>
>     .git/worktrees/<worktree-name>/modules/<submodule-name>/
>
> or rather
>
>     .git/modules<submodule-name>/worktrees/<worktree-name>
>
> Or both (one of them being a gitlink file pointing at the other?)
>
> I have not made up my mind, as I haven't laid out all cases that are
> relevant here.

I would go with a conservative step first, keep submodules per-worktree. After it's sorted out. You can change the layout (e.g. as a config extension). The latter probably has some complication (but yeah sharing would be a big plus).

-- 
Duy