Re: Nested submodule checkout

From: Damien Robert <damien.olivier.robert@gmail.com>
Date: Feb 18, 2020, 17:08 UTC
Message-ID: <20200218170808.dh4s65b475yqs3oz@mithrim>
In-Reply-To: <0123F1ED-C421-4C1F-896B-E54C9D345A34@gmail.com>

Hi Philippe,

From Philippe Blain, Sun 16 Feb 2020 at 23:51:43 (-0500) :

> I reported the same bug to the list back in September [1]

Meta question: is there an easy way I could have found your bug report?

> and I’m glad to say I just finished (today!) a patch series [2] that fixes this bug.

Great! Thanks for the patches!

Show 13 quoted lines

> Here you just did ` git commit -am 'Add submodule plam’` so the next command according to your reproducer above would be `git checkout nosubmodules`
> 
> > Migrating git directory of 'plam' from
> > '/data/dams/var/tmp/ploum/plam/.git' to
> > '/data/dams/var/tmp/ploum/.git/modules/plam'
> > Migrating git directory of 'plam/plim' from
> > '/data/dams/var/tmp/ploum/plam/plim/.git' to
> > '/data/dams/var/tmp/ploum/.git/modules/plam/modules/plim'
> > Switched to branch 'nosubmodules'
> > Your branch is behind 'master' by 1 commit, and can be fast-forwarded.
> >  (use "git pull" to update your local branch)
> 
> Here, git is migrating the git directories of both submodules to the git directory of the superproject (ploum). This tells me you probably have the `submodule.recurse` config set somewhere, as this is the behaviour I get I if I do `git checkout --recurse-submodules nosubmodules`.

Yes, you are of course right. I should have specified it in my bug report, I tried to specify the setting explicitely in the last checkout but as you noticed I forgot to specify it in all other commands, sorry about the noise.

> That’s another hint that you have `submodule.recurse` set. I don’t get this error doing `git reset --hard`, but I get it doing `git reset --hard --recurse-submodules` (or `git reset --hard --r`, which works and is quicker to type!). `git reset` populates the index, so now `git ls-files -s` would now show the correct content of ‘plam’.

Oh, I did not know git expand unambiguous long options!

By the way the fact that `git reset` also support `--recurse-submodules` is not specified in the man page. (It is in the help text thought).

And it would be nice if the documentation of submodule.recurse in git-config specify the list of all affected commands, rather than just "all commands that have a --recurse-submodules options".

(I could send a patch for this if there is interest)

> > Note that I wasn't able to reproduce in this small examples, but when
> > trying to repair I also add some strange errors of the form
> > '.git is not a git directory' (where .git was a pseudo symlink
> > gitdir: ../.git/modules/plam).

-> This is explained by your Patch 5/6

> would have correctly checked out the submodules. I have a git alias ‘no-rs’ (for no recurse-submodules) that I use in these situations:
>     git config --global alias.no-rs ‘-c submodule.recurse=0’

Can you use alias to define option settings (rather than commands followed by options) without using the 'f() {}' trick?

Using your alias, I get fatal: empty alias for no-rs

> Then the `submodule update` call above could be shortened to 
>     git no-rs submodule update --recursive --force

> Note that using the `submodule.recurse` config also applies to internal calls to git commands (issued by other git commands), so using adding `--no-recurse-submodules` to the command line might not be enough to completely turn off the effect of that config, hence this handy alias.

Ohh, good to know!

-- 
Damien Robert
http://www.normalesup.org/~robert/pro