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

On Thu, Jan 19, 2017 at 4:09 AM, Duy Nguyen [off-list ref] wrote:

On Wed, Jan 11, 2017 at 12:01 AM, Stefan Beller [off-list ref] wrote:

quoted

On Tue, Jan 10, 2017 at 3:25 AM, Nguyễn Thái Ngọc Duy [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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