Wrong git branch showing when inside a git sub-module since v1.10

[simonc]

Current Behavior

The value printed for git_branch is always master instead of the current branch. Same thing in a repo where the default branch is main, it will always print main.

Expected Behavior

The git_branch module should print the current active branch.

Additional context/Screenshots

$ git branch
  master
* test-branch

$ starship module git_branch
 master

Environment

• Starship version: 1.10.1
• zsh version: zsh 5.8.1 (x86_64-apple-darwin21.0)
• Operating system: Mac OS 12.5.0
• Terminal emulator: iTerm.app 3.4.16
• Rust Version: rustc 1.63.0
• Rust channel: release
• Build Time: 2022-08-15 18:21:57 +00:00
• Git version: 2.37.2

[davidkna]

We've replaced (lib)git2 with gitoxide/git-repository in 0.10.

Is the repo owned by the user, and would it be considered trusted by git without secure.directories? What's the content of .git/HEAD?

[simonc]

Hey @davidkna. Actually trying to answer your question made me realize that both repos I tested were in sub-module contexts so there's no .git/HEAD file in those cases.

I tried in a classic repo and it works fine so it limits the issue to the sub-module scenario, that's a positive point 😊

[daniel-white]

I'm not getting any git module stuff for a large mono repo

[daniel-white]

@davidkna can that all be backed out - theres apparently a lot of breaking changes

[robert914]

I see this same problem, anytime I descend into a submodule the branch shown by starship is the parent repo branch, and not the branch of the submodule I'm in.

[davidkna]

I've confirmed the cause of the bug and upstream will hopefully fix it soon.

@daniel-white Personally, I wouldn’t revert it just yet, though at this time reverting should still be straightforward. The other large issue wasn't specifically tied to the git implementation, and more related to how starship is parallelized.

Would you please describe your issue in more detail? I'm not sure if it's the same issue from your description.

[daniel-white]

@davidkna i'd be happy to move this to a new thread, but since i upgraded to 1.10.1, none of the git modules are working in a rather large (private) monorepo. for a smaller public repo, they do present. i do not have any submodules. i'd be happy to see if theres any debug flags to help isolate the problem. i'm just concerned that the new git crate is failing on this repo. my git version is 2.37.2

[davidkna]

@daniel-white I've created a new issue for your problem in #4272.

[Byron]

Indeed, submodules have never been tested and apparently during the test-period of starship 1.10 and the duration of a couple of weeks, none of the testers (myself included) ever managed to enter a git-submodule to notice this.

That said, today gitoxide will learn to open submodules and I think this enables the starship maintainers to make a new release in the course of the day. I have a 6 hours head start, so I second @davidkna that a revert certainly won't be needed here. The only known workaround to this issue will be downgrading starship to a version prior to 1.10.

[simonc]

Just installed the latest version and everything is working fine. Thanks for the very quick fix and thanks for Starship! ❤️

[robert914]

I can also confirm the submodule branch detection works again with 1.10.2. Thanks!

[simonc]

Sadly I don't think it's the end of it 🙈 Just checked out a commit on the git tree. It used to show the commit number but now it simply prints like if there was not git activity 😕

I'll open a new issue for this problem as it's different.