git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Ben Avison <bavison@riscosopen.org>
To: git@vger.kernel.org
Subject: Bug in git submodule update --remote
Date: Fri, 14 May 2021 19:11:04 +0100	[thread overview]
Message-ID: <c4b27662-1228-a1ff-26fc-637897ffc8e7@riscosopen.org> (raw)

A recent-ish change in git 2.27.1, introduced in commit f0a96e8d, has 
also got me wondering about whether some related functionality is 
correct. I'm not sure what the best way to fix things is, so can I 
invite opinions?

The scenario: I have a repository with a submodule. The submodule's 
upstream repository uses a fork workflow, so the submodule has two 
remotes, one for pulling in other people's changes, and one for 
uploading my own pull requests.

$ mkdir myproject
$ cd myproject
$ git init
$ git submodule add https://github.com/acme/library
$ cd library
$ git remote add -f myfork https://github.com/user/library
$ cd ..
$ git add .
$ git commit -m "Initial commit"
$ git remote add origin https://github.com/user/myproject
$ git push -u origin master

Furthermore, assume I forked https://github.com/acme/example some time 
ago, so that the master branches between it and my fork have diverged.

Time passes. People hack away on both projects. I want to fix a bug or 
implement a new feature in the library, so I start by ensuring both are 
up-to-date:

$ git pull
$ git submodule update --remote
$ cd library
$ git checkout -b new-feature
$ # hack away
$ git add .
$ git commit -m "New feature"
$ git push -u myfork new-feature
$ cd ..

Some more time passes, and I want to work on it again. Again, I start by 
ensuring I'm up-to-date. Before git 2.27.1, I could do:

$ git submodule update --remote

Now, I get:

fatal: Needed a single revision
Unable to find current myfork/HEAD revision in submodule path 'library'

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.

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?

Ben

             reply	other threads:[~2021-05-14 18:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 18:11 Ben Avison [this message]
2021-05-19 10:49 ` Bug in git submodule update --remote 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
2021-05-19 11:19 ` Atharva Raykar
2021-05-22 18:02 ` Philippe Blain

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=c4b27662-1228-a1ff-26fc-637897ffc8e7@riscosopen.org \
    --to=bavison@riscosopen.org \
    --cc=git@vger.kernel.org \
    /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).