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

From: Stefan Beller <sbeller@google.com>
Date: Jan 19, 2017, 20:03 UTC
Message-ID: <CAGZ79kYy2q9ZMt8r7MdysuNOu84bY7uSUTGJXVxA1nnP-ZJW0Q@mail.gmail.com>
In-Reply-To: <CACsJy8BHgc8o+SydeiVnqaZRCbkJEWVzqDZM4sgey04ZLtG3tQ@mail.gmail.com>

On Thu, Jan 19, 2017 at 4:09 AM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 31 quoted lines

> On Wed, Jan 11, 2017 at 12:01 AM, Stefan Beller <sbeller@google.com> wrote:
>> 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.

Similar to worktrees submodules can appear and disappear without affecting the project/main tree. (though the mechanism is different, for submodules, you'd checkout a version that doesn't have the submodule, whereas for worktrees the user explicitely says: "I don't want to see this worktree any more")

> 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 ;-)

I sure hope so.

Show 26 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).

The sharing is what we are asked for as it would "make submodules usable" (compared to the repo tool, which doesn't have object sharing AFAIK). ;)

Currently I am leaning to put the worktree directory first and the submodules within, i.e.

.git/worktrees/<worktree-name>/modules/<submodule-name>/

but in that directory, we'd only have the per-worktree specific stuff, the object store would live with the superprojects main worktree, i.e. at .git/modules/<submodule-name> we'd have the main git dir for the submodule.

Thanks, Stefan

> --
> Duy