Submodules: two confusing situations

From: David Turner <david.turner@twosigma.com>
Date: Nov 1, 2016, 22:13 UTC
Message-ID: <6533af94ebd74952b75e51c5609d8c20@exmbdft7.ad.twosigma.com>

Consider the following two cases:

We have commit X and commit Y.  X is an ancestor of Y.

We're at X and doing get checkout Y -- or we're at Y and we're doing git checkout X.

Case 1: Between X and Y, we have deleted a submodule. In order to move from X to Y, git removes the submodule from the working tree.

Case 2: Between X and Y, we have instead added a submodule. In order to move from Y to X (that is, the opposite direction), git *does not* remove the submodule from the tree; instead, it gives a warning and leaves the submodule behind.

I don't understand why these two cases are not symmetric.

-- 
Perhaps relatedly, consider the attached shell-script, which I have not yet made into a full git test because I'm not sure I understand the issues fully.

It creates three commits:

Commit 1 adds a submodule
Commit 2 removes that submodule and re-adds it into a subdirectory (sub1 to sub1/sub1).
Commit 3 adds an unrelated file.

Then it checks out commit 1 (first deinitializing the submodule to avoid case 2 above), and attempts to cherry-pick commit 3.  This seems like it ought to work, based on my understanding of cherry-pick.  But in fact it gives a conflict on the stuff from commit 2 (which is unrelated to commit 3).

This is confusing to me, and looks like a bug.  What am I missing?