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!
> 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
