From: Philippe Blain <firstname.lastname@example.org>
To: Ben Avison <email@example.com>,
Atharva Raykar <firstname.lastname@example.org>,
Christian Couder <email@example.com>,
Shourya Shukla <firstname.lastname@example.org>,
Emily Shaffer <email@example.com>
Subject: Re: Bug in git submodule update --remote
Date: Sat, 22 May 2021 15:15:51 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Le 2021-05-19 à 10:41, Ben Avison a écrit :
> On 19/05/2021 11:49, Atharva Raykar wrote:
>> If I understood you correctly, you'd prefer that the updating of the
>> submodule should be independent of the ref that is checked out in the
>> submodule's directory.
>> While I am not sure of the reason why the design of 'update
>> --remote' uses the remote-tracking branch of the submodule, I can
>> imagine adding a switch like 'submodule.<name>.remote' that defaults
>> to 'origin'. Then the behaviour could be changed such that it always
>> pulls from the remote specified in that option.
>> This would help make the behaviour consistent in all the cases you
>> mentioned, while also giving the option for a user to update the
>> submodule from the remote of their choice (which may not be origin).
> I like that solution.
I also think a new config is a good solution.
> Although, I should note that if the user has set
> submodule.<name>.remote to something other than 'origin', they will need
> to ensure that submodule.<name>.branch is also set, or they will still
> hit the "Unable to find current <remote>/HEAD revision in submodule"
> error that I initially stumbled on.
> How about an implementation like the following? I introduced a new "git
> submodule--helper" command rather than modify "print-default-remote" for
> a couple of reasons:
> 1) "print-default-remote" is also used for "git submodule sync" (I'm not
> sure if we should change its behaviour too)
> 2) "print-default-remote" needs to be executed from within the
> submodule, and takes no arguments, whereas I need to parse the
> superproject's .git/config so need to be executed from the superproject
> and take the submodule path as an argument
> The two functions I added are heavily based on "git submodule--helper
> remote-branch". However:
> * Unlike with the branch name, I don't fall back to using the name for
> the remote cached from when we read the .gitmodules file, if it isn't
> found in .git/config. It doesn't make sense to me for the .gitmodules
> file to include this information, as any new clones will only contain
> "origin" remotes anyway.
> * I removed "struct strbuf sb" since I don't think it's used.
I think that we would want to careful examine every use of 'get_default_remote'
(and the NEEDSWORK in submodule.c:get_next_submodule)
and decide for each one if it makes sense to respect that new config before failing
back to 'origin'. So I'm not sure about the approach here since it just fixes the behaviour
for 'git submodule update --remote' but not other scenarios where the user would like
another remote than 'origin' to be used for some operations in the submodule.
There was also another bug report recently  around the new 'clone.defaultRemoteName'
config and 'git submodule update --remote', so it might be good to also keep that in
mind when working on a solution.
P.S. I've CC'ed Emily who has plans for a big overhaul of submodule functionality
over the next months  so might be interested.
next prev parent reply other threads:[~2021-05-22 19:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-14 18:11 Bug in git submodule update --remote Ben Avison
2021-05-19 10:49 ` Atharva Raykar
2021-05-19 14:41 ` Ben Avison
2021-05-21 11:47 ` Atharva Raykar
2021-05-21 18:36 ` Christian Couder
2021-05-22 19:15 ` Philippe Blain [this message]
2021-05-19 11:19 ` Atharva Raykar
2021-05-22 18:02 ` Philippe Blain
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:
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 \
* 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
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).