# Submodules: two confusing situations

2 messages from 2016-11-01 to 2016-11-01. Participants: David Turner, Stefan Beller.
Thread: https://gitlist.dev/t/44410

## David Turner, 2016-11-01 22:13

Subject: Submodules: two confusing situations
Message-ID: <6533af94ebd74952b75e51c5609d8c20@exmbdft7.ad.twosigma.com>
URL: https://gitlist.dev/e/6533af94ebd74952b75e51c5609d8c20%40exmbdft7.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?


```

## Stefan Beller, 2016-11-01 22:56

Subject: Re: Submodules: two confusing situations
Message-ID: <CAGZ79kbqVphQpDSEKFs=_6E1XNsn6rz=1ifRx9iEHFhRd9ZPOA@mail.gmail.com>
URL: https://gitlist.dev/e/CAGZ79kbqVphQpDSEKFs%3D_6E1XNsn6rz%3D1ifRx9iEHFhRd9ZPOA%40mail.gmail.com
In-Reply-To: <6533af94ebd74952b75e51c5609d8c20@exmbdft7.ad.twosigma.com>

```
On Tue, Nov 1, 2016 at 3:13 PM, David Turner <David.Turner@twosigma.com> wrote:
> 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.

Because you are using git-submodule.sh that is only an approximation of
what is supposed to happen. ("git checkout [X | Y] && git submodule update"
I'd guess).

"git submodule update" only *updates* the submodules and doesn't *delete*
them at all. I think this originated from the historic behavior of
having the submodules
.git directory inside the submodule and not in the superprojects .git/module.
When having the .git dir inside the submodule, you cannot delete the submodule
as you'd potentially loose information (local commits) from the submodule.

I am currently working on implementing a flag --recurse-submodules for
git-checkout
that would be symmetrical from X -> Y and back, but that feature hasn't seen
the mailing list yet as I discovered yet another bug locally.
I think I found a reviewer though. ;)

The problem with doing a propoer checkout, i.e. update and deletion of
a submodule,
you need to be sure the submodule in its state can go away:
* no untracked files that are lost (except for gitignored files)
* clean index in the submodule and
* the submodule points at the recorded sha1 (i.e. there are no
  commits that would be dangling)

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

That sounds like a bug indeed.

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

```