From: Atharva Raykar <email@example.com>
To: Ben Avison <firstname.lastname@example.org>
Subject: Re: Bug in git submodule update --remote
Date: Wed, 19 May 2021 16:19:21 +0530 [thread overview]
Message-ID: <EB55447C-538F-44DE-BFC0-A3BD1A970E99@gmail.com> (raw)
On 14-May-2021, at 23:41, Ben Avison <email@example.com> wrote:
> What's going on is that within "git submodule update --remote", the sha1 used is formed by looking up the submodule's ref "<remote>/<branch>". The change in git 2.27.1 is that if no remote tracking branch is stated in the superproject's .gitmodules file, <branch> defaults to "HEAD" rather than "master" as previously. That's fine if <remote> is "origin", but in practice, it depends on how the submodule is currently checked out:
> * if it's in detached HEAD state, <remote> is set to "origin"
> * if its branch is not a tracking branch, "origin" is also used
> * but if it's a tracking branch (as I used in my workflow above - not uncommon in pull request workflows because you might grant other people access to the branch during the review process) then it looks up the name of the remote which is being tracked
> First observation: a ref called "myfork/HEAD" presumably *could* have been created by the "git remote add" command, reflecting that remote's default branch. Should it?
> In practice, that's not actually what I'd want, though. If I do "git submodule update --remote", I personally normally do so as a shortcut compared to cloning everything again. I don't expect the behaviour to change depending on whether I happen to have left one of the submodules checked out on a tracking branch or not: myfork/master is potentially quite out of date compared to origin/master.
> It also makes very little sense to me that issuing "git submodule update --remote" twice in quick succession would leave us in a different state, because the first call puts all the submodules into detached HEAD state, meaning that the second call always looks up the remote tracking branches from the submodule's "origin" remote.
I agree with you, this behaviour is rather inconsistent, and
can be quite surprising to an unsuspecting user.
> One way this could be fixed is that if <branch> turns out to be "HEAD", we could force <remote> to be "origin". However, this doesn't address the equivalent problem that arises if the remote tracking branch *is* named in .gitmodules.
> I'd therefore like to propose that "git submodule update --remote" *always* uses the remote named "origin" to form the ref used to check out the submodule. However, I'm not sure whether everyone would agree that this constitutes a bugfix, or whether I'd need to introduce a new switch to enforce this behaviour.
> So, what do you think?
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).
next prev parent reply other threads:[~2021-05-19 10:49 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 [this message]
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
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).