Ramkumar Ramachandra <artag...@gmail.com> writes:

> This configuration variable comes into effect when 'git clone' is
> invoked inside an existing git repository's worktree.  When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the path specified by this variable.

Relocate to where in the superproject's gitdir?  Presumably you can
do this more than once in a given superproject, so there needs to be
a key per such a clone, no?  I am guessing that you would follow the
usual "when adding a submodule without name, use its path as the
initial name" convention, but then I would suggest it to be spelled
out (and if you are doing it differently, that choice needs to be
spelled out and defended).

>  Okay, so this is part of my evil plan to make 'git add' DTRT wrt
>  submodules,...

If the envisioned use of this is to use it as a building block of
something else that is user-facing (e.g. the user says "git add",
and before the command finishes, somewhere we internally run "git
clone"), then would it be possible that you are better off running
that clone with --separate-git-dir and let it make the gitfile for

Any new configuration variable brings its own problem by forcing
existing users to countermand it explicitly from the command line.
If the --separate-git-dir would not work for your application, you
need a new feature and you can achieve the same by adding a new
command line option (say, --submodule-git-dir), that would be more
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