Junio C Hamano wrote:
I'd like to hear clarifications on two counts, please?
(1) If Sylvain wanted to have that appear at dir0/dir1/init not init,
would it have been sufficient to give that path twice (once for
<repository> and another for <path> parameter) to make things work as
expected?
git-submodule really requires two arguments:
$ git submodule add <URL> <relative-path-to-module-in-tree>
and supports two modes:
1) relative-path exists and is a valid repo: just add the module, it was
created in tree, the user is expected to eventually push this to the
given URL so other users will get this as normal. This exists to
simplify the process of creating a repo to begin with.
2) relative-path doesn't exist: clone from the URL. This is the normal use.
submodule supports adding a module in one of two ways:
So,
$ git submodule add dir0/dir1/init dir0/dir1/init
will add the repo, but also makes the repo its own origin. I don't think
this makes sense.
(2) Is it generally considered a sane use case to specify an existing
repository inside the working tree of a superproject as a submodule
using "git submodule add" like Sylvain's example did?
I would have understood if the command were "git add dir0/dir1/init",
but I have this vague recolleciton that "git submodule add" is about
telling our repository about a submodule that comes from _outside_.
Adding an existing in-tree repo, ala
$ git submodule add <intended-URL> <path>
is there to ease the initial creation of a submodule. It can be created
and registered in-tree, and later pushed to the server. This is sane,
but is not the normal usage (makes sense only on creation).
Mark
--
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
