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
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
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
- 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html