Change:
<details<summary<codegit --version --build-options</code</summary</detailsExample: <details<summary<codeD:tmpgit clone -o upstream</code</summary</details<details<summary<codeD:tmpcd rust</code</summary</details<details<summary<codemaster:rustpython setup</code</summary</details(continued) <details<summary<codemaster:rustgit show-ref HEAD</code</summary</details label +C-bug +A-bootstrap
Additional info: switching to a new branch that is not tracking upstream succeeds, so it is the upstream tracking that's messing something up: <details<summaryterminal session</summary
My current working theory is that this is a git bug (maybe we can work around it though). I think this is because git has created the submodule with a remote of , but probably due to the passed for the rust checkout, it's trying to fetch/pull from the upstream remote inside the submodule too. That won't work; the upstream remote doesn't exist there, as the submodule was initially cloned (via that same git submodule update) with an "origin" remote. I'm not sure what we should be doing to avoid this -- my guess is a proper fix would be in git itself... it might be that we can try to workaround it somehow, but I'm not seeing an obvious hook for us to attach to.
Can we report this bug upstream to git? I think they use a mailing list?
I was not able to reproduce this locally :/ I tried and it checked out the submodules successfully. I'm using
For me this happens only sometimes. Most of the time when I checkout an old branch. I think I've got a reproduction (by checking out an old commit and pushing a branch to my fork), probably has unnecessary steps, but it seems to be "working" for me. git version:
To make steps reproducible - HEAD is currently
Oh lol, I just ran into this today. A bit more info: <details</details
On the bright side, this means it's easy to work around the bug.
ah hmm, after doing that I can no longer reproduce the bug ... I think this might only happen on the very first submodule we try to clone? git is acting so strangely ... this happens even in a fresh worktree, it's only when it's a fresh clone it hits this problem, which makes no sense to me since submodules aren't shared between worktrees. Anyway, here's a minimal reproduction that doesn't depend on exactly which commit you're using, or : I'll put up a PR shortly.

Discussion:
use std::io; use std::io::ErrorKind; use std::path::{Path, PathBuf}; <del> use std::process::Command; </del> <ins> use std::process::{Command, Stdio}; </ins> use std::str; use channel::GitInfo;

// Try passing `--progress` to start, then run git again without if that fails. let update = |progress: bool| { <del> let mut git = Command::new("git"); </del> <ins> // Git is buggy and will try to fetch submodules from the tracking branch for *this* repository, // even though that has no relation to the upstream for the submodule. let current_branch = { let output = self .config .git() .args(["symbolic-ref", "--short", "HEAD"]) .stderr(Stdio::inherit()) .output(); let output = t!(output); if output.status.success() { Some(String::from_utf8(output.stdout).unwrap().trim().to_owned()) } else { None } }; let mut git = self.config.git(); if let Some(branch) = current_branch { git.arg("-c").arg(format!("branch.{branch}.remote=origin")); } </ins> git.args(&["submodule", "update", "--init", "--recursive", "--depth=1"]); if progress { git.arg("--progress"); } <del> git.arg(relative_path).current_dir(&self.config.src); </del> <ins> git.arg(relative_path); </ins> git }; // NOTE: doesn't use `try_run` because this shouldn't print an error if it fails.