From: Damien Robert <damien.olivier.robert@gmail.com>
To: Philippe Blain <levraiphilippeblain@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Nested submodule checkout
Date: Tue, 18 Feb 2020 18:08:08 +0100 [thread overview]
Message-ID: <20200218170808.dh4s65b475yqs3oz@mithrim> (raw)
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!
> 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
next prev parent reply other threads:[~2020-02-18 17:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 22:42 Nested submodule checkout Damien Robert
2020-02-17 4:51 ` Philippe Blain
2020-02-18 17:08 ` Damien Robert [this message]
2020-02-19 4:19 ` Philippe Blain
2020-02-26 17:23 ` Nested submodule status bug Damien Robert
2020-02-27 10:05 ` Damien Robert
2020-02-27 10:43 ` Spurious GIT_DIR set when in a worktree [was Re: Nested submodule status bug] Damien Robert
2020-02-27 15:50 ` GIT_DIR in aliases [Re: " Damien Robert
2020-02-28 19:02 ` Jeff King
2020-02-28 20:22 ` Junio C Hamano
2020-03-03 22:44 ` Damien Robert
2020-02-29 1:42 ` Philippe Blain
2020-03-03 21:56 ` Damien Robert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200218170808.dh4s65b475yqs3oz@mithrim \
--to=damien.olivier.robert@gmail.com \
--cc=git@vger.kernel.org \
--cc=levraiphilippeblain@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).