Jeff King wrote: > So there is some information that is per-clone (the objects, the remote > tips), but there is some information that is per-submodule (where our > local branches are, the index, the worktree). I can see why it is > advantageous to share the per-clone information between similar clones > (because it avoids disk space and network transfer). But I do not think > you can escape having some form of per-submodule repo, even if it is a > thin git-new-workdir-ish repo that points back to a parent repo for the > clone. I want the flexibility to do the following: 1. Do a "simple clone", where the clone contains the GITDIR embedded in the worktree. This is the most common case, and there is no reason to complicate it. I can optionally attach additional workdirs to this clone. I can also optionally relocate the GITDIR at a later date, if I feel the need to do so. 2. Attach a worktree to any object store without having to write a gitfile and set core.worktree by hand. The limitation is that you can't have two submodules from two different superprojects sharing the same object store (since both of them are worktrees). However, for the purpose of working on the submodule repository as an independent repository (this is a very common case for me), I can attach a new "workdir" to the GITDIR very easily. 3. Attach multiple submodules to the same object store. This will require maintaining a separate index, HEAD and logs/HEAD (aka. workdir) for each additional submodule (the first one doesn't need it) in .git/modules of the superproject. > Is there some part of your proposal that I am missing? It seems like you > would still need one/.git/modules/foo for this "thin" repo. You're talking about #3, while I'm still working on #2. And why do you want to use a hammer again if I don't want to share the same object store with multiple submodules? This .git/modules/<name> is completely optional, and is only required for the _second_ submodule onwards that I'm attaching to the same object store. > And by the way, I am actually not sure that such a shared-object setup > is a good idea, but only that _if_ you are going to do it with > submodules, you might as well do it for all repos. In theory, it is not > that hard to have a big per-user object-only repository (either for all > repos, or for related ones). But we can do that already with "git clone > -s", and people do not generally bother, because the maintenance is very > tricky (especially dealing with reachability and pruning). No, no. I'm against dumping objects from all repositories into one giant object store. That's a sledgehammer solution, while I'm looking for control and flexibility. Moreover, it has lots of downsides, as you already pointed out. > I am open to the argument that solving it in a specific case > (submodules) lets us make assumptions that simplify the problem from the > general case, but I do not offhand see how it would be any easier in > this case. So my proposal is to build a new first-class tool to make manipulations in #1, #2 and #3 easily possible. The first step is to formalize the names "bare worktree" (which refers to a worktree with a gitfile), "worktree" (which refers to a worktree with a GITDIR embedded in it), and "workdir" (which refers to a worktree with a "thin" GITDIR). The reason I want to build it for submodules first is because the non-submodule case (#2) is simply a reduced case of the submodule case (#3): - When I attempt to attach a new worktree to an existing GITDIR with a worktree attached, I will create a workdir instead. This simply involves creating a thin .git directory in the worktree in the non-submodule case. In the submodule case, it is more complicated: I have to locate the superproject's .git directory, and put it there. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html