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

From: Jens Lehmann <[email-masked]>
Date: Tue, 31 May 2011 21:30:52 +0200

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)