src/tools/rls submodule remote commit is broken; only works when current remote is called 'origin'

[jplatte]

I just tried updating my local rust fork, but all x.py invocations were failing because they were trying to fetch the upstream remote of src/tools/rls. upstream was my local name of this repo (and origin was the local name of my fork). It seems like because I was on a local branch tracking a branch from upstream, x.py tried fetching upstream of submodules as well, but those submodules don't have an upstream remote, so things failed.

When I renamed origin to jplatte and upstream to origin, things started working again.

[fee1-dead]

More information is probably needed, perhaps this should be a topic on Zulip?

Here's my setup and it works.

❯ git remote get-url origin
git@github.com:fee1-dead/rust.git

❯ git remote get-url upstream
git@github.com:rust-lang/rust.git

[jplatte]

Hm, does it work when you're on a branch that tracks a branch from upstream? (e.g. when on master, after git branch -u upstream/master)

[the8472]

I think I'm facing the same issue. I worked on a branch, did git switch master && git pull as usual and then I got

$ ./x.py check library/core/
Updating only changed submodules
Updating submodule src/tools/cargo
Submodule path 'src/tools/cargo': checked out 'a5e08c4703f202e30cdaf80ca3e7c00baa59c496'
Updating submodule src/tools/rls
remote: Enumerating objects: 12, done.
remote: Counting objects: 100% (12/12), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 2 (delta 1), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (2/2), 286 bytes | 143.00 KiB/s, done.
fatal: 'upstream' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
fatal: Fetched in submodule path 'src/tools/rls', but it did not contain 27f4044df03d15c7c38a483c3e4635cf4f51807d. Direct fetching of that commit failed.
Failed updating submodule. This is probably due to uncommitted local changes.
Either stash the changes by running "git stash" within the submodule's
directory, reset them by running "git reset --hard", or commit them.
To reset all submodules' changes run "git submodule foreach --recursive git reset --hard".
Build completed unsuccessfully in 0:00:01

This workflow used to work.

[RalfJung]

This is not about the remote name; the RLS submodule points to a commit that doesn't exist in the repo (https://github.com/rust-lang/rls/tree/27f4044df03d15c7c38a483c3e4635cf4f51807d) since #97853 landed.

My biggest question is why CI allowed this to land...

[RalfJung]

On top of that git seems to have some strange heuristics for submodules that involves remote names, which I have no clue what it is about. I do have a remote called origin pointing to the upstream repo and it still fails when the current branch points to another remote (ralf, for my fork).

[RalfJung]

Indeed, checking out a branch that tracks the origin remote, then doing the submodule update, and then checking out my branch again works. Wtf is git doing here?!? That probably explains why this worked on CI.

[jplatte]

I think the broken commit reference was fixed a long time ago, and the git bug (if therr is one) should be tracked elsewhere.