Mark Levedahl [off-list ref] writes:
Sylvain Joyeux wrote:
quoted
Redo the prep work, the clone and now
git submodule add dir0/dir1/init
(i.e. don't expect dir0/dir1/init to be the clone of ./init, that was just a
shortcut for the test. Expect it to be a clone of "something, somewhere")
Per the man-page,
git submodule [--quiet] add [-b branch] [--] <repository> [<path>]
which means, that the *repository* url is mandatory, the path is
optional. What you specifically asked git-submodule to do was to
*clone* from dir0/dir1/init, and because you gave no path to put the
submodule in, git-submodule deduced the name as "init", and cloned to
there.
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?
(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_.
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
On Mon, Jul 07, 2008 at 11:26:12PM -0400, Mark Levedahl wrote:
Junio C Hamano wrote:
quoted
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:
Then it should raise an error when the following is given
git submodule add ./relative-path-in-repo
which, for now, is accepted as
git submodule add ./relative-path-in-repo ./relative-path-in-repo
(and confused me into thinking it was a normal behaviour)
Sylvain