Hi Damien, > Le 18 févr. 2020 à 12:08, Damien Robert <damien.olivier.robert@xxxxxxxxx> a écrit : > > 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? That’s a good question. The search capabilities of public-inbox (the software running at lore.kernel.org) are explained at https://lore.kernel.org/git/_/text/help/ In this case, my bug report comes out in the following searches: b:(nested submodule checkout) s:(bug* submodule* checkout) the first one can be refined with b:(nested submodule checkout) NOT s:(cooking) NOT s:(ANNOUNCE) NOT s:(PATCH*) > >> 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! Yes, it’s not widely known but can be useful! It’s documented in gitcli(7) (`man gitcli`) or online at https://git-scm.com/docs/gitcli#_abbreviating_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). Yes, this is on my radar, I’d like to get some time to clean this up sometimes soon. It’s also missing for `git restore`. > 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) That’s a very good idea in my opinion, especially since the search functionality on git-scm.com is presently limited to 10 hits from the manpages so it fails to find all occurrences of `--recurse-submodules` [1]. [1] https://github.com/git/git-scm.com/issues/1374 >> 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 The alias specifies an option directly to the git "main" executable instead of a specific Git command (in this case setting a particular configuration variable for the duration of the command that will follow). This alias works for me, at least on Git 2.25. The git-config man page mentions aliases can start with an option to git [2]. If it does not work in an older version of Git then you can use git config --global alias.no-rs ‘!git -c submodule.recurse=0' which should do the trick. [2] https://git-scm.com/docs/git-config#Documentation/git-config.txt-alias >> 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! If you do go ahead with a patch listing the commands affected by submodule.recurse in git-config, then I think this should also be mentioned. Cheers, Philippe.
