On 13-04-16 04:13 AM, Ramkumar Ramachandra wrote: > 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. Doesn't contrib/workdir/git-new-workdir do this? M. -- 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