* [BUG?] git submodule update --remote assumes 'origin' remote
@ 2021-03-01 15:46 Sean Barag
2021-03-01 16:38 ` Ævar Arnfjörð Bjarmason
2021-03-01 17:17 ` Sean Barag
0 siblings, 2 replies; 4+ messages in thread
From: Sean Barag @ 2021-03-01 15:46 UTC (permalink / raw)
To: git
I think I've found a bit of an edge case in
`git submodule update --remote` [1] that got easier to reproduce in
2.30+ under certain configurations.
`git submodule--helper print-default-remote` defaults to 'origin' when
run in a submodule in a detached HEAD state or on a branch with no
remote tracking branch [1]. In git < 2.30, the only way for that
default to be incorrect required a user to manually change remote names
with something like `git -C ./some-sm remote rename origin foo`.
`git rev-parse`ing that ref would naturally fail, but at least it's
because the user took manual steps to break git's assumptions.
Under git 2.30+ with clone.defaultRemoteName set however, submodules are
created with that remote name instead of 'origin'. The same behavior
occurs, but this time without direct user action - only a simple
`git submodule init && git submodule update --remote` is required.
I'm terribly sorry about that regression - I've only just started
working on a few projects that use submodules heavily and probably could
have found this sooner. I'm happy to fix it, but would *super*
appreciate a little guidance. It seems the intention is "use the remote
that has the url found in the superproject's .submodules entry", that'd
require `git submodule--helper print-default-remote` to be called from
the superproject from what I can tell. I've experimented with
introducing fallbacks to `remote_for_branch` in `remote.c` [2] as an
alternative:
1. use remote tracking branch; or
2. if there's only one remote, use that; or
3. if config.defaultRemoteName is set, use that; or
4. fall back to "origin"
This seems to work (at the very least, no tests fail?), but leaves
`cd ./some-sm; git remote add foo bar; git remote rename origin baz`
open to the original behavior.
Something tells me y'all will have a very simple solution that I'm
missing :)
Again, I'm so sorry for introducing a regression here!
Sean Barag
[1] https://github.com/git/git/blob/225365fb5195e804274ab569ac3cc4919451dc7f/git-submodule.sh#L571-L584
[2] https://github.com/git/git/blob/225365fb5195e804274ab569ac3cc4919451dc7f/remote.c#L477-L487
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG?] git submodule update --remote assumes 'origin' remote
2021-03-01 15:46 [BUG?] git submodule update --remote assumes 'origin' remote Sean Barag
@ 2021-03-01 16:38 ` Ævar Arnfjörð Bjarmason
2021-03-01 17:13 ` Sean Barag
2021-03-01 17:17 ` Sean Barag
1 sibling, 1 reply; 4+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-03-01 16:38 UTC (permalink / raw)
To: Sean Barag; +Cc: git
On Mon, Mar 01 2021, Sean Barag wrote:
> I think I've found a bit of an edge case in
> `git submodule update --remote` [1] that got easier to reproduce in
> 2.30+ under certain configurations.
> `git submodule--helper print-default-remote` defaults to 'origin' when
> run in a submodule in a detached HEAD state or on a branch with no
> remote tracking branch [1]. In git < 2.30, the only way for that
> default to be incorrect required a user to manually change remote names
> with something like `git -C ./some-sm remote rename origin foo`.
> `git rev-parse`ing that ref would naturally fail, but at least it's
> because the user took manual steps to break git's assumptions.
>
> Under git 2.30+ with clone.defaultRemoteName set however, submodules are
> created with that remote name instead of 'origin'. The same behavior
> occurs, but this time without direct user action - only a simple
> `git submodule init && git submodule update --remote` is required.
>
> I'm terribly sorry about that regression - I've only just started
> working on a few projects that use submodules heavily and probably could
> have found this sooner. I'm happy to fix it, but would *super*
> appreciate a little guidance. It seems the intention is "use the remote
> that has the url found in the superproject's .submodules entry", that'd
> require `git submodule--helper print-default-remote` to be called from
> the superproject from what I can tell. I've experimented with
> introducing fallbacks to `remote_for_branch` in `remote.c` [2] as an
> alternative:
>
> 1. use remote tracking branch; or
> 2. if there's only one remote, use that; or
> 3. if config.defaultRemoteName is set, use that; or
> 4. fall back to "origin"
>
> This seems to work (at the very least, no tests fail?), but leaves
> `cd ./some-sm; git remote add foo bar; git remote rename origin baz`
> open to the original behavior.
>
> Something tells me y'all will have a very simple solution that I'm
> missing :)
>
> Again, I'm so sorry for introducing a regression here!
> Sean Barag
Just a quick note, I gather you're talking about de9ed3ef37 (clone:
allow configurable default for `-o`/`--origin`, 2020-10-01) which was
first released in v2.30.0.
Just noting that in the context of this bug already being in a release,
since we're now in the 2.31.0-rc0 period. Meaning likely not a release
blocker in the next few weeks.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG?] git submodule update --remote assumes 'origin' remote
2021-03-01 16:38 ` Ævar Arnfjörð Bjarmason
@ 2021-03-01 17:13 ` Sean Barag
0 siblings, 0 replies; 4+ messages in thread
From: Sean Barag @ 2021-03-01 17:13 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git
On Mon, Mar 1, 2021, at 8:38 AM, Ævar Arnfjörð Bjarmason wrote:
> Just a quick note, I gather you're talking about de9ed3ef37 (clone:
> allow configurable default for `-o`/`--origin`, 2020-10-01) which was
> first released in v2.30.0.
Yes, that's exactly the commit. I knew I forgot to include something.
> Just noting that in the context of this bug already being in a
> release, since we're now in the 2.310-rc0 period. Meaning likely not
> a release blocker in the next few weeks.
That makes sense - thanks for clarifying!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG?] git submodule update --remote assumes 'origin' remote
2021-03-01 15:46 [BUG?] git submodule update --remote assumes 'origin' remote Sean Barag
2021-03-01 16:38 ` Ævar Arnfjörð Bjarmason
@ 2021-03-01 17:17 ` Sean Barag
1 sibling, 0 replies; 4+ messages in thread
From: Sean Barag @ 2021-03-01 17:17 UTC (permalink / raw)
To: git
On Mon, Mar 01 2021, Sean Barag wrote:
> I've experimented with
> introducing fallbacks to `remote_for_branch` in `remote.c` [2] as an
> alternative:
>
> 1. use remote tracking branch; or
> 2. if there's only one remote, use that; or
> 3. if config.defaultRemoteName is set, use that; or
> 4. fall back to "origin"
>
> This seems to work (at the very least, no tests fail?), but leaves
> `cd ./some-sm; git remote add foo bar; git remote rename origin baz`
> open to the original behavior.
I forgot to mention that this approach requires `get_default_remote` in
`submodule--helper.c` to use the name of the remote returned by
`remote_get(NULL)`. That was probably obvious to regular mailing list
readers :D
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-03-01 17:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-01 15:46 [BUG?] git submodule update --remote assumes 'origin' remote Sean Barag
2021-03-01 16:38 ` Ævar Arnfjörð Bjarmason
2021-03-01 17:13 ` Sean Barag
2021-03-01 17:17 ` Sean Barag
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).