Skip to content

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

Closed

Description

@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.

Activity

  1. fee1-dead commented on Jun 24, 2022

    @fee1-dead
    Member

    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
    
  2. jplatte commented on Jun 24, 2022

    @jplatte
    ContributorAuthor

    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)

  3. the8472 commented on Jun 25, 2022

    @the8472
    Member

    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.

  4. changed the title [-]git remote for rust-lang/rust has to be named origin for x.py to work?[/-] [+]src/tools/rls submodule remote commit is broken[/+] on Jun 25, 2022
  5. RalfJung commented on Jun 25, 2022

    @RalfJung
    Member

    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...

  6. RalfJung commented on Jun 25, 2022

    @RalfJung
    Member

    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).

  7. RalfJung commented on Jun 25, 2022

    @RalfJung
    Member

    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.

  8. changed the title [-]src/tools/rls submodule remote commit is broken[/-] [+]src/tools/rls submodule remote commit is broken; only works when current remote is called 'origin'[/+] on Jun 25, 2022
  9. added 2 commits that reference this issue on Jun 25, 2022
  10. added a commit that references this issue on Jun 26, 2022
  11. jplatte commented on Mar 12, 2023

    @jplatte
    ContributorAuthor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: This is a bug.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions