From: "Michael S. Tsirkin" <mst@redhat.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Glen Choo" <chooglen@google.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
git@vger.kernel.org
Subject: Re: sudmodule.<name>.recurse ignored
Date: Tue, 11 Oct 2022 18:34:16 -0400 [thread overview]
Message-ID: <20221011182119-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <xmqq35bze3rr.fsf@gitster.g>
On Fri, Oct 07, 2022 at 02:13:12PM -0700, Junio C Hamano wrote:
> Glen Choo <chooglen@google.com> writes:
>
> > - where to get the submodule from during a fetch/clone, e.g.
> > `submodule.<name>.url`, `submodule.<name>.branch`
> > - information needed for submodules to work correctly, e.g.
> > `submodule.<name>.path`
> > - default config that gets populated in .git/config via `git submodule
> > init`, e.g. `submodule.<name>.update`,
> > `submodule.<name>.fetchRecurseSubmodules`
> >
> > With respect to config, the general stance is that .gitmodules is meant
> > to provide defaults for .git/config and _not_ to be read directly (see
> > Ævar's answer).
>
> I think that is a sensible way to think about this.
>
> It is more like "suggestion made by the upstream", to be taken after
> examining it, just like you should type "make" after examining the
> Makefile. At least enough to trust its contents ;-)
>
> > There are some very limited cases where config is read
> > directly from .gitmodules, but that approach is very frowned upon and
> > it's unlikely that we'll add more of them in the future.
>
> Yup, we should be careful and see if we can get rid of existing
> uses.
>
> Thanks.
Fundamentally the problem we encounter regularly is this:
qemu is superproject, ui/keycodemapdb is subproject.
I have a change on master setting the submodule commit:
qemu$ git show master | grep +Sub
+Subproject commit 7381b9bfadd31c4c9e9a10b5bb5032f9189d4352
and check it out:
qemu$ git submodule update --init ui/keycodemapdb
Submodule 'ui/keycodemapdb' (https://gitlab.com/qemu-project/keycodemapdb.git) registered for path 'ui/keycodemapdb'
Submodule path 'ui/keycodemapdb': checked out '7381b9bfadd31c4c9e9a10b5bb5032f9189d4352'
In another branch I have a different commit:
qemu$ git show sub-foo | grep +Sub
+Subproject commit 57ba70da5312170883a3d622cd2aa3fd0e2ec7ae
Now I switch branches and nothing happens, the submodule
is marked as dirty:
qemu$ git checkout sub-foo
M ui/keycodemapdb
Switched to branch 'sub-foo'
qemu$ (cd ui/keycodemapdb && git show | head -1)
commit 7381b9bfadd31c4c9e9a10b5bb5032f9189d4352
it is now very easy to generate incorrect code:
- git commit -a will commit the change to submodule
- any build will use a mix of super and subproject that
is completely untested
As a result people are basically saying avoid using submodules
but I am wondering whether git can be tweaked to do the
right thing by default.
I understand we can work around it by asking everyone to
create a correct config, but can't we make it DTRT by default
to reduce friction?
--
MST
next prev parent reply other threads:[~2022-10-11 22:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 10:10 sudmodule.<name>.recurse ignored Michael S. Tsirkin
2022-10-07 11:09 ` Ævar Arnfjörð Bjarmason
2022-10-07 12:56 ` Michael S. Tsirkin
2022-10-07 21:04 ` Glen Choo
2022-10-07 21:13 ` Junio C Hamano
2022-10-11 22:34 ` Michael S. Tsirkin [this message]
2022-10-12 16:56 ` Glen Choo
2022-10-12 21:49 ` Michael S. Tsirkin
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221011182119-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=avarab@gmail.com \
--cc=chooglen@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.