Re: [RFC/PATCH] clone: introduce clone.submoduleGitDir to relocate $GITDIR

[Marc Branchaud <marcnarc@xiplink.com>]

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.