Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > I specifically did not go down this route, because I think it is > gross. Where does moving a GITDIR fit into what git add's normal job > (index manipulation) is? Tools should do one specific thing, and do > it well: not a mixed bag of unrelated things. I see you are trying to repeat the UNIX mantra, but I do not think it is working. When we discuss "git add", the "one unit of work" is at much higher level than that of "git update-index". "git add dir/" has to do a lot more than "git add file", and "git add symlink" has to do quite a different thing from "git add file", but to the end user, all of them are about doing everything necessary to add what the user named to the index. "git add submodule/" that does whatever necessary to add the submodule to the index is still doing one thing well inside the same framework, and that may include moving the $GIT_DIR and turning it into a gitfile. Not that I am saying I prefer "add --url=xxx". Quite the opposite. I very much prefer the "clone and then add, but clone drops the repository at the right place from the beginning" approach than "add that knows about URL only for submodules", which is an ugly kludge. If the user creates here/.git without gitlink with whatever means, it is "git add here"'s job, if it wants to make it a submodule and if it wants to make it possible to later check out another branch that does not have the submodule, to stash away the repository and turn it into gitfile, if it is part of what is needed to add a submodule. Of course, we could start from teaching "submodule add" to do so, and then internally redirect "git add subm" to "git submodule add", but that is a minor implementation detail that does not affect the end user experience. -- 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