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

From: W. Trevor King <wking@tremily.us>
Date: Apr 17, 2014, 16:41 UTC
Message-ID: <20140417164138.GP21805@odin.tremily.us>
In-Reply-To: <5331B741.6000606@web.de>

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

Show 9 quoted lines

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

Are we waiting to land this series (or a successor) before starting on a fix for this issue? There have been a number of submodule series in flight recently, and I'm having trouble keeping track of them all ;).

Show 13 quoted lines

> *) Forced work tree updates happily manipulate files in the
>    directory of a submodule that has just been removed in the
>    superproject (but is of course still present in the work tree due
>    to the way submodules are currently handled). This becomes
>    dangerous when files in the submodule directory are overwritten
>    by files from the new superproject commit, as any modifications
>    to the submodule files will be lost) and is expected to also
>    destroy history in the - admittedly unlikely case - the new
>    commit adds a file named ".git" to the submodule directory.
> …
> I'm not so sure about the second one. Even though I believe the
> current behavior is not correct (switching commits should never mess
> around in a submodule directory)

This should also be covered by the usual “don't allow checkouts from dirty workdirs unless the dirty-ing changes are easily applied to the target tree”. We don't implement this yet, but I'd like to force users to move any about-to-be-clobbered state from their submodule into .git/modules/<name>/ (via commits or stashes) before allowing them to begin the checkout. Once we've ensured that the state is preserved out-of-tree, then clobber away ;).

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