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

From: Marc Branchaud <[email-masked]>
Date: Tue, 31 May 2011 17:06:31 -0400

On 11-05-31 03:30 PM, Jens Lehmann wrote:
> 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)

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.