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

> 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)