Ramkumar Ramachandra <artag...@gmail.com> 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

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to