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

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.