Re: [RFC/PATCH 2/4] Submodules: Add the lib-submodule-update.sh test library

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 17.04.2014 23:55, schrieb W. Trevor King:
> On Thu, Apr 17, 2014 at 11:08:06PM +0200, Jens Lehmann wrote:
>> Am 17.04.2014 18:41, schrieb W. Trevor King:
>>> On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote:
>>>> *) When a submodule is replaced with a tracked file of the same name
>>>>    the submodule work tree including any local modifications (and
>>>>    even the whole history if it uses a .git directory instead of a
>>>>    gitfile!) is simply removed.
>>>> …
>>>> I think the first bug really needs to be fixed, as that behavior is
>>>> extremely nasty. We should always protect work tree modifications
>>>> (unless forced) and *never* remove a .git directory (even when
>>>> forced).
>>>
>>> I think this should be covered by the usual “don't allow checkouts
>>> from dirty workdirs unless the dirty-ing changes are easily applied to
>>> the target tree”.
>>
>> Nope, the target tree will be removed completely and everything in
>> it is silently nuked. It should be allowed with '-f', but only if
>> the submodule contains a gitfile, and never if it contains a .git
>> directory (which is just what we do for rm too).
> 
> I think it's not covered *now* because of a flaw in our “are dirty-ing
> changes easily applied to the target tree” detection logic, and the
> solution should involve updating that logic to hit on this case.

Yup.

>> b) recursive checkout is the place to consistently care about
>> submodule modifications (the submodule script doesn't do that and it
>> is impossible to change that without causing trouble to a lot of
>> users.
> 
> I agree that the submodule script is not the place for this, and the
> core checkout code is.  I'd like checkouts to always be recursive, and
> see --[no-]recurse-submodules as a finger-breaking stop-gap until we
> can complete that transition for checkout, bisect, merge, reset, and
> other work-tree altering commands.  I think this is one reason why
> some folks prefer the stiffer joints you get from a subtree approach.

We are definitely in the same boat here :-)