Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 you? 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 preferrable. -- 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