[PATCH 0/2] Tests for some submodule corner cases.

Ran across some submodule behavior that seems wrong to me.  I don't have the
chops to fix the issues, so I thought I'd just point them out with some unit
tests.

Patch 1 tests the case where "submodule add" fails if the path to the
submodule repo is relative (i.e. starts with "../").  This currently fails
with "remote (origin) does not have a url defined in .git/config".  Maybe
there's a reason to fail?  If so, a better error message would be appreciated.

Patch 2 exposes an anomaly in "submodule status", which reports that a
submodule is OK even though it has deleted files.  "git status" inside
the submodule (and in the super-repo) both identify any deleted files, but
"submodule status" doesn't prefix the submodule's HEAD SHA-ID with a "+".

(ps. I didn't sign-off these two patches, since they're just failing unit
tests.  Should I sign-off on them?)

		M.

---
 t/t7400-submodule-basic.sh |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index bbcfc61..d321540 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh

@@ -331,6 +331,12 @@ test_expect_success 'status should be "up-to-date" after update' '
 	grep "^ $rev1" list
 '
 
+test_expect_failure 'status should be "modified" if working dir deleted' '
+	rm -rf init/* &&
+	git submodule status >list &&
+	grep "^+$rev1" list
+'
+
 test_expect_success 'checkout superproject with subproject already present' '
 	git checkout initial &&
 	git checkout master

-- 
1.7.5.3.686.g35b8

---
 t/t7400-submodule-basic.sh |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index b2b26b7..bbcfc61 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh

@@ -86,6 +86,13 @@ test_expect_success 'submodule add' '
 	test_cmp empty untracked
 '
 
+test_expect_failure 'submodule add with relative path to submodule repo' '
+	(
+		cd addtest &&
+		git submodule add ../.subrepo relative_subrepo_path
+	)
+'
+
 test_expect_success 'submodule add to .gitignored path fails' '
 	(
 		cd addtest-ignore &&

-- 
1.7.5.3.686.g35b8

Am 30.05.2011 23:51, schrieb Marc Branchaud:

Ran across some submodule behavior that seems wrong to me.  I don't have the
chops to fix the issues, so I thought I'd just point them out with some unit
tests.

Thanks for bringing these issues to our attention this way, having a way
to easily reproduce them is very much appreciated.

Patch 1 tests the case where "submodule add" fails if the path to the
submodule repo is relative (i.e. starts with "../").  This currently fails
with "remote (origin) does not have a url defined in .git/config".  Maybe
there's a reason to fail?  If so, a better error message would be appreciated.

I stumbled across this behavior now and then too, but according to the
commit it added (f31a522a2d) it is intended that adding a relative path
behaves differently than using an absolute path (it resolves relative to
the superproject's origin, not the filesystem, and to be able to do that
the superproject's .git/config has to have an url defined for it). But
you are right about the error message, it really isn't that helpful ...

Patch 2 exposes an anomaly in "submodule status", which reports that a
submodule is OK even though it has deleted files.  "git status" inside
the submodule (and in the super-repo) both identify any deleted files, but
"submodule status" doesn't prefix the submodule's HEAD SHA-ID with a "+".

That is documented behavior. "git submodule status" only cares about the
commit recorded in the superproject vs the HEAD in the submodule, work
tree modifications are never shown by it.

But try a "git status" in the superproject, that will give you the following
output:
#	modified:   init (modified content)

A "git submodule add ../sub" interprets "../sub" relative to the default
remote of the superproject. To be able to do that, a url for that remote
has to be set in the superprojects .git/config. If that is not the case
the command fails with:
	"remote (origin) does not have a url defined in .git/config"

This neither mentions the relative repository nor that the .git/config of
the superproject is the one with the missing url. And as a novice user
could assume that relative paths would work just like absolute paths do
in the filesystem and run into this by accident, the message is not very
helpful.

So change that to
	"Cannot resolve "../sub" relative to remote (origin), its url
	 is not set in .git/config"
to give the user a clue that "git submodule add" interprets a relative
path as being relative to its default remote, not the work tree.

Signed-off-by: Jens Lehmann <redacted>
---

Am 31.05.2011 21:30, schrieb Jens Lehmann:

Am 30.05.2011 23:51, schrieb Marc Branchaud:

quoted

Patch 1 tests the case where "submodule add" fails if the path to the
submodule repo is relative (i.e. starts with "../").  This currently fails
with "remote (origin) does not have a url defined in .git/config".  Maybe
there's a reason to fail?  If so, a better error message would be appreciated.

I stumbled across this behavior now and then too, but according to the
commit it added (f31a522a2d) it is intended that adding a relative path
behaves differently than using an absolute path (it resolves relative to
the superproject's origin, not the filesystem, and to be able to do that
the superproject's .git/config has to have an url defined for it). But
you are right about the error message, it really isn't that helpful ...

What about this patch?


 git-submodule.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index d189a24..14ef1d4 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -34,7 +34,7 @@ resolve_relative_url ()
 {
 	remote=$(get_default_remote)
 	remoteurl=$(git config "remote.$remote.url") ||
-		die "remote ($remote) does not have a url defined in .git/config"
+		die "Cannot resolve \"$1\" relative to remote ($remote), its url is not set in .git/config"
 	url="$1"
 	remoteurl=${remoteurl%/}
 	sep=/

-- 
1.7.5.3.412.gb2afd.dirty

On 11-05-31 04:00 PM, Jens Lehmann wrote:

A "git submodule add ../sub" interprets "../sub" relative to the default
remote of the superproject. To be able to do that, a url for that remote
has to be set in the superprojects .git/config. If that is not the case

Nit: superprojects --> superproject's

the command fails with:
	"remote (origin) does not have a url defined in .git/config"

This neither mentions the relative repository nor that the .git/config of
the superproject is the one with the missing url. And as a novice user
could assume that relative paths would work just like absolute paths do
in the filesystem and run into this by accident, the message is not very
helpful.

So change that to
	"Cannot resolve "../sub" relative to remote (origin), its url
	 is not set in .git/config"
to give the user a clue that "git submodule add" interprets a relative
path as being relative to its default remote, not the work tree.

Thanks for the cogent explanation & patch.  I think the message could be
improved a bit:

	Cannot resolve "../sub" relative to this repository's "origin"
	remote: The remote's URL is not set in .git/config

However, overall I think this is a pretty fragile way to handle relative
paths.  Consider:

 - The super-repo must be a clone in order for this to work at all.

 - The super-repo cannot be checked out on a detached HEAD.

 - The current code rewrites the URL so that any relative path is either
   rejected or munged into an absolute remote URL.

It seems to me that this feature will only work in a fairly narrow set of
circumstances, and even when it does work it's likely to do something
unexpected (think of a super-repo with several remotes).

Back when Junio accepted the original patch, he said "If you maintain and
serve a set related projects you need to give the users a single URL (per
where the user is and how to reach the server)."  I'm not sure I understand
that:  Why would the users be adding their own submodules to the
superproject?  Wouldn't the superproject define the submodules in for them?

I think it would be better to either just reject relative paths entirely, or
accept any relative path as-is and display a warning that the submodule is
only valid on the local machine.  (Perhaps one day receive-pack could even be
taught to reject any pushes with a .gitmodules file containing a relative URL.)

		M.

On 11-05-31 03:30 PM, Jens Lehmann wrote:

Am 30.05.2011 23:51, schrieb Marc Branchaud:

quoted

Ran across some submodule behavior that seems wrong to me.  I don't have the
chops to fix the issues, so I thought I'd just point them out with some unit
tests.

Thanks for bringing these issues to our attention this way, having a way
to easily reproduce them is very much appreciated.

quoted

Patch 1 tests the case where "submodule add" fails if the path to the
submodule repo is relative (i.e. starts with "../").  This currently fails
with "remote (origin) does not have a url defined in .git/config".  Maybe
there's a reason to fail?  If so, a better error message would be appreciated.

I stumbled across this behavior now and then too, but according to the
commit it added (f31a522a2d) it is intended that adding a relative path
behaves differently than using an absolute path (it resolves relative to
the superproject's origin, not the filesystem, and to be able to do that
the superproject's .git/config has to have an url defined for it). But
you are right about the error message, it really isn't that helpful ...

quoted

Patch 2 exposes an anomaly in "submodule status", which reports that a
submodule is OK even though it has deleted files.  "git status" inside
the submodule (and in the super-repo) both identify any deleted files, but
"submodule status" doesn't prefix the submodule's HEAD SHA-ID with a "+".

That is documented behavior. "git submodule status" only cares about the
commit recorded in the superproject vs the HEAD in the submodule, work
tree modifications are never shown by it.

But try a "git status" in the superproject, that will give you the following
output:
#	modified:   init (modified content)

I understand.  My apologies for not reading the man page closely enough.

I know there's been a lot of recent work on making "git status"
submodule-friendly, but would there be any interest in having another prefix
for submodule status to cover this case?  Maybe ! could indicate that the
submodule's HEAD is correct, but the working directory doesn't match it exactly.

		M.

Am 31.05.2011 23:06, schrieb Marc Branchaud:

On 11-05-31 03:30 PM, Jens Lehmann wrote:

quoted

Am 30.05.2011 23:51, schrieb Marc Branchaud:

quoted

Patch 2 exposes an anomaly in "submodule status", which reports that a
submodule is OK even though it has deleted files.  "git status" inside
the submodule (and in the super-repo) both identify any deleted files, but
"submodule status" doesn't prefix the submodule's HEAD SHA-ID with a "+".

That is documented behavior. "git submodule status" only cares about the
commit recorded in the superproject vs the HEAD in the submodule, work
tree modifications are never shown by it.

But try a "git status" in the superproject, that will give you the following
output:
#	modified:   init (modified content)

I understand.  My apologies for not reading the man page closely enough.

No problem, maybe that's just an indication that a reference to "git status"
being more capable of telling what is going on inside a submodule is missing
to the man page for "git submodule status".

I know there's been a lot of recent work on making "git status"
submodule-friendly, but would there be any interest in having another prefix
for submodule status to cover this case?  Maybe ! could indicate that the
submodule's HEAD is correct, but the working directory doesn't match it exactly.

I'd rather leave "git submodule status" as it is and incorporate this kind
of functionality into core git (for "submodule status" it already arrived there
in 1.7.0/1.7.1, so that part is finished ;-). I hope making the "git submodule"
script mostly obsolete in the long run and would want to avoid teaching it new
stuff already covered by core git.

A "git submodule add ../sub" interprets "../sub" relative to the default
remote of the superproject. To be able to do that, a url for that remote
has to be set in the superproject's .git/config. If that is not the case
the command fails with:
	"remote (origin) does not have a url defined in .git/config"

This neither mentions the relative repository nor that the .git/config of
the superproject is the one with the missing url. And as a novice user
could assume that relative paths would work just like absolute paths do
in the filesystem and run into this by accident, the message is not very
helpful.

So change that to
	Cannot resolve "../sub" relative to this repository's "origin"
	remote: The remote's URL is not set in .git/config
to give the user a clue that "git submodule add" interprets a relative
path as being relative to its default remote, not the work tree.

Thanks-to: Marc Branchaud [off-list ref]
Signed-off-by: Jens Lehmann <redacted>
---

Thanks for your review, here is the updated patch.

Am 31.05.2011 22:57, schrieb Marc Branchaud:

However, overall I think this is a pretty fragile way to handle relative
paths.  Consider:

 - The super-repo must be a clone in order for this to work at all.

 - The super-repo cannot be checked out on a detached HEAD.

 - The current code rewrites the URL so that any relative path is either
   rejected or munged into an absolute remote URL.

It seems to me that this feature will only work in a fairly narrow set of
circumstances, and even when it does work it's likely to do something
unexpected (think of a super-repo with several remotes).

And even worse: it defies the principle of least surprise when I can't
just replace an absolute filesystem path with a relative one just like
almost everywhere else ... an option enabling this behavior might have
been a better way in hindsight.

Back when Junio accepted the original patch, he said "If you maintain and
serve a set related projects you need to give the users a single URL (per
where the user is and how to reach the server)."  I'm not sure I understand
that:  Why would the users be adding their own submodules to the
superproject?  Wouldn't the superproject define the submodules in for them?

I can't tell about that reasoning, but it might make sense in a way I don't
understand yet ...

I think it would be better to either just reject relative paths entirely, or
accept any relative path as-is and display a warning that the submodule is
only valid on the local machine.  (Perhaps one day receive-pack could even be
taught to reject any pushes with a .gitmodules file containing a relative URL.)

Breaking backwards compatibility should not be considered easily. I tend to
not change such things until I understand the use cases for the solution,
especially as submodule use cases tend to be very different ...


 git-submodule.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index d189a24..587d74e 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -34,7 +34,7 @@ resolve_relative_url ()
 {
 	remote=$(get_default_remote)
 	remoteurl=$(git config "remote.$remote.url") ||
-		die "remote ($remote) does not have a url defined in .git/config"
+		die "Cannot resolve \"$1\" relative to this repository's \"$remote\" remote: The remote's URL is not set in .git/config"
 	url="$1"
 	remoteurl=${remoteurl%/}
 	sep=/

-- 
1.7.5.3.445.g9c0c23

On 05/31/2011 04:57 PM, Marc Branchaud wrote:

Thanks for the cogent explanation & patch.  I think the message could be
improved a bit:

	Cannot resolve "../sub" relative to this repository's "origin"
	remote: The remote's URL is not set in .git/config

However, overall I think this is a pretty fragile way to handle relative
paths.  Consider:

 - The super-repo must be a clone in order for this to work at all.

Yes, but that constraint (mostly) makes sense to me.  But if 'git
submodule add' did not initialize .git/config, this constraint could be
dropped.

 - The super-repo cannot be checked out on a detached HEAD.

Why do you think that?  I just tried this and it worked fine for me.  I
can't think of a reason for it to fail.

 - The current code rewrites the URL so that any relative path is either
   rejected or munged into an absolute remote URL.

I don't see the URL getting munged away from being relative.  Can you
point to an example?

It seems to me that this feature will only work in a fairly narrow set of
circumstances, and even when it does work it's likely to do something
unexpected (think of a super-repo with several remotes).

I use it this way with several remotes. 

Back when Junio accepted the original patch, he said "If you maintain and
serve a set related projects you need to give the users a single URL (per
where the user is and how to reach the server)."  I'm not sure I understand
that:  Why would the users be adding their own submodules to the
superproject?  Wouldn't the superproject define the submodules in for them?

I am a user.  I admin a super-project for other users.  This project
lives at three remotes, remotes/public, remotes/shared and remotes/build. 

I add a new submodule to the superproject like this:

   mkdir sub && cd sub && git init
   cd ..
   git submodule add ../sub sub

This results in the new submodule being inserted into my .gitmodules
file and my .git/config:

   tail -3 .gitmodules
   [submodule "sub"]
       path = sub
       url = ../sub

   tail -2 .git/config
   [submodule "sub"]
       url = public:git/sub

I do have to make sure to push my submodule to the correct location on
each remote before pushing my new .gitmodules.

But the exact same commands work for me if I do this first and then do
'git submodule add ../sub' afterwards. 

So, I don't understand your objections.  Do you understand my use case
any better?

Phil

On 11-05-31 06:04 PM, Phil Hord wrote:

On 05/31/2011 04:57 PM, Marc Branchaud wrote:

quoted

Thanks for the cogent explanation & patch.  I think the message could be
improved a bit:

	Cannot resolve "../sub" relative to this repository's "origin"
	remote: The remote's URL is not set in .git/config

However, overall I think this is a pretty fragile way to handle relative
paths.  Consider:

 - The super-repo must be a clone in order for this to work at all.

Yes, but that constraint (mostly) makes sense to me.  But if 'git
submodule add' did not initialize .git/config, this constraint could be
dropped.

quoted

 - The super-repo cannot be checked out on a detached HEAD.

Why do you think that?  I just tried this and it worked fine for me.  I
can't think of a reason for it to fail.

Whoops, right.  I was confusing a different error with the fact that "git
symbolic-ref HEAD" fails on a detached HEAD.  The code defaults to "origin"
as the remote name in this case (perhaps that's not strictly the right thing
to do, but I'm sure this isn't the only part of git that assumes there's a
remote called "origin").

quoted

 - The current code rewrites the URL so that any relative path is either
   rejected or munged into an absolute remote URL.

I don't see the URL getting munged away from being relative.  Can you
point to an example?

I reached this conclusion because if I go into my clone of git.git and do

	git submodule add ../MyThing

where ../MyThing is a regular git repo, I get

Cloning into MyThing...
fatal: The remote end hung up unexpectedly
Clone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path
'MyThing' failed

So it seemed the relative URL became an absolute URL.

Looking more closely at a working example, I can see that (as you show below)
the URL in the super-repo's .gitmodules file retains the relative path, but
the submodule's remote.origin.url is an absolute path.

In any case, "submodule add" isn't doing what I expected: make my local
MyThing repo a submodule of my git.git clone.

quoted

It seems to me that this feature will only work in a fairly narrow set of
circumstances, and even when it does work it's likely to do something
unexpected (think of a super-repo with several remotes).

I use it this way with several remotes. 

quoted

Back when Junio accepted the original patch, he said "If you maintain and
serve a set related projects you need to give the users a single URL (per
where the user is and how to reach the server)."  I'm not sure I understand
that:  Why would the users be adding their own submodules to the
superproject?  Wouldn't the superproject define the submodules in for them?

I am a user.  I admin a super-project for other users.  This project
lives at three remotes, remotes/public, remotes/shared and remotes/build. 

I add a new submodule to the superproject like this:

   mkdir sub && cd sub && git init
   cd ..
   git submodule add ../sub sub

This results in the new submodule being inserted into my .gitmodules
file and my .git/config:

   tail -3 .gitmodules
   [submodule "sub"]
       path = sub
       url = ../sub

   tail -2 .git/config
   [submodule "sub"]
       url = public:git/sub

I do have to make sure to push my submodule to the correct location on
each remote before pushing my new .gitmodules.

But the exact same commands work for me if I do this first and then do
'git submodule add ../sub' afterwards. 

So, I don't understand your objections.  Do you understand my use case
any better?

It's not so much an objection as confusion over how "submodule add" works.

I believe your case works smoothly only because in your super-project you're
careful to make sure you have checked out a branch that remotely tracks a
something in remotes/public.  If you checked out a branch that tracks a
different remote you'd get different results.  This seems fragile to me.

When you tried the detached-HEAD scenario, did you get URLs for
"public:git/sub" or "origin:git/sub"?  Does "origin" just happen to be the
remote you want to use in any case?

My fundamental point is that "git submodule add" seems to do confusing things
with relative paths.  Maybe all that's needed is to clarify the
documentation.  I'll post a patch.

		M.

On 11-05-31 05:26 PM, Jens Lehmann wrote:

Am 31.05.2011 23:06, schrieb Marc Branchaud:

quoted

On 11-05-31 03:30 PM, Jens Lehmann wrote:

quoted

Am 30.05.2011 23:51, schrieb Marc Branchaud:

quoted

Patch 2 exposes an anomaly in "submodule status", which reports that a
submodule is OK even though it has deleted files.  "git status" inside
the submodule (and in the super-repo) both identify any deleted files, but
"submodule status" doesn't prefix the submodule's HEAD SHA-ID with a "+".

That is documented behavior. "git submodule status" only cares about the
commit recorded in the superproject vs the HEAD in the submodule, work
tree modifications are never shown by it.

But try a "git status" in the superproject, that will give you the following
output:
#	modified:   init (modified content)

I understand.  My apologies for not reading the man page closely enough.

No problem, maybe that's just an indication that a reference to "git status"
being more capable of telling what is going on inside a submodule is missing
to the man page for "git submodule status".

Yes, that'd possibly help.

quoted

I know there's been a lot of recent work on making "git status"
submodule-friendly, but would there be any interest in having another prefix
for submodule status to cover this case?  Maybe ! could indicate that the
submodule's HEAD is correct, but the working directory doesn't match it exactly.

I'd rather leave "git submodule status" as it is and incorporate this kind
of functionality into core git (for "submodule status" it already arrived there
in 1.7.0/1.7.1, so that part is finished ;-). I hope making the "git submodule"
script mostly obsolete in the long run and would want to avoid teaching it new
stuff already covered by core git.

A noble goal, certainly.

So here's my basic question: How can my build system be sure that a submodule
contains the correct working directory?  Do I need to do both "git submodule
status" to check the submodule's HEAD, then also use "git status" to see if
that HEAD is correctly checked out?

Note that my automated builds don't really care about possibly-modified files
or anything like that.  They just want the exact tree that corresponds to the
commit ID recorded in the superproject.  (Previous builds might've left some
cruft lying around, and the automated build wants to be sure that's eliminated.)

Maybe I should just forego the status-checking altogether, and do "git
submodule update path/to/sub && (cd path/to/sub; git reset --hard HEAD; git
clean -dx)".

		M.

Am 01.06.2011 18:11, schrieb Marc Branchaud:

On 11-05-31 05:26 PM, Jens Lehmann wrote:

quoted

No problem, maybe that's just an indication that a reference to "git status"
being more capable of telling what is going on inside a submodule is missing
to the man page for "git submodule status".

Yes, that'd possibly help.

Ok, I'll see if I can come up with something ...

So here's my basic question: How can my build system be sure that a submodule
contains the correct working directory?  Do I need to do both "git submodule
status" to check the submodule's HEAD, then also use "git status" to see if
that HEAD is correctly checked out?

No, "git status" will do both. The only thing it will be silent about is when
a submodule isn't initialized at all ("git submodule status" shows this with
a '-').

On 06/01/2011 11:55 AM, Marc Branchaud wrote:

On 11-05-31 06:04 PM, Phil Hord wrote:

quoted

On 05/31/2011 04:57 PM, Marc Branchaud wrote:

quoted

 - The current code rewrites the URL so that any relative path is either
   rejected or munged into an absolute remote URL.

I don't see the URL getting munged away from being relative.  Can you
point to an example?

I reached this conclusion because if I go into my clone of git.git and do

	git submodule add ../MyThing

where ../MyThing is a regular git repo, I get

Cloning into MyThing...
fatal: The remote end hung up unexpectedly
Clone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path
'MyThing' failed

So it seemed the relative URL became an absolute URL.

Looking more closely at a working example, I can see that (as you show below)
the URL in the super-repo's .gitmodules file retains the relative path, but
the submodule's remote.origin.url is an absolute path.

In any case, "submodule add" isn't doing what I expected: make my local
MyThing repo a submodule of my git.git clone.

I thought I understood this workflow better than I actually did.  I
think I understand more now, and I'm somewhat disappointed.  But I also
failed to pick up the ball on this old discussion.

If you do this, I think it will work like you were hoping:

    :: ( mkdir MyThing && cd MyThing && git init )
    Initialized empty Git repository in /opc/git/MyThing/.git/
    :: git submodule add ../MyThing
    Adding existing repo at 'MyThing' to the index

I haven't examined the code, but I think this is how it works.  'git
submodule add' takes a URL and a local path.  When you omit the local
path, git infers one from the URL.  So these two commands are equivalent:
    :: git submodule add ../MyThing
    :: git submodule add ../MyThing MyThing


If the path you provide (explicitly or implicitly) already contains a
git repo, it is assumed to be "the" submodule repo and git uses it.  If
it does not contain a git repo, git attempts to clone it from the
(remote) URL.

Furthermore, the relative path only works for URLs.  It does not work
for local filesystems.

Phil

On 11-07-27 03:00 PM, Phil Hord wrote:

On 06/01/2011 11:55 AM, Marc Branchaud wrote:

quoted

On 11-05-31 06:04 PM, Phil Hord wrote:

quoted

On 05/31/2011 04:57 PM, Marc Branchaud wrote:

quoted

 - The current code rewrites the URL so that any relative path is either
   rejected or munged into an absolute remote URL.

I don't see the URL getting munged away from being relative.  Can you
point to an example?

I reached this conclusion because if I go into my clone of git.git and do

	git submodule add ../MyThing

where ../MyThing is a regular git repo, I get

Cloning into MyThing...
fatal: The remote end hung up unexpectedly
Clone of 'git://git.kernel.org/pub/scm/git/MyThing' into submodule path
'MyThing' failed

So it seemed the relative URL became an absolute URL.

Looking more closely at a working example, I can see that (as you show below)
the URL in the super-repo's .gitmodules file retains the relative path, but
the submodule's remote.origin.url is an absolute path.

In any case, "submodule add" isn't doing what I expected: make my local
MyThing repo a submodule of my git.git clone.

I thought I understood this workflow better than I actually did.  I
think I understand more now, and I'm somewhat disappointed.  But I also
failed to pick up the ball on this old discussion.

If you do this, I think it will work like you were hoping:

    :: ( mkdir MyThing && cd MyThing && git init )
    Initialized empty Git repository in /opc/git/MyThing/.git/
    :: git submodule add ../MyThing
    Adding existing repo at 'MyThing' to the index

I see how that works, but I don't find that intuitive at all.  For one,
../MyThing doesn't even exist, neither locally or on the origin repo.  It's
really ./MyThing (with one dot).  The last idea that I'd come up with for
adding ./MyThing as a submodule would be to use ../MyThing.

What git does in this case actually looks like a bug to me.  I'd expect "git
submodule add ../MyThing" to fail if there's no local ../MyThing and no
remote ../MyThing.

Furthermore, the relative path only works for URLs.  It does not work
for local filesystems.

Well, sort of.  From the current man page: "If the superproject doesn't have
an origin configured the superproject is its own authoritative upstream and
the current working directory is used instead."

I submitted two patches to clarify the documentation on that point:

	http://article.gmane.org/gmane.comp.version-control.git/175163
	http://article.gmane.org/gmane.comp.version-control.git/175162

They seemed to have been lost in the shuffle, though.

		M.