On Thu, Jan 19, 2017 at 4:09 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Wed, Jan 11, 2017 at 12:01 AM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >> On Tue, Jan 10, 2017 at 3:25 AM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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. > >> 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