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

On Thu, Apr 17, 2014 at 11:08:06PM +0200, Jens Lehmann wrote:

Am 17.04.2014 18:41, schrieb W. Trevor King:

quoted

On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote:

quoted

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

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.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy