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?


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

Reply via email to