Commit color yellow instead of green

[freijon]

Describe the bug

In the FAQ and https://github.com/jesseduffield/lazygit/discussions/1622 I read that yellow means it's not in the master branch. I have created a new repo (there is only the main branch) and the commit colors are yellow instead of green. Am I missing something?

To Reproduce

Steps to reproduce the behavior:

1. Create a new repo (cloned from an empty remote).
2. Add commits to the 'main' branch
3. Observe yellow color

Expected behavior

Commits should be green

Screenshots

Version info:

• lazygit --version: commit=80223c7fbbd0b86631a988834cbe88e267bb0bd9, build date=2025-11-01T09:43:19Z, build source=binaryRelease, version=0.56.0, os=windows, arch=amd64, git version=2.52.0.windows.1
• git --version: git version 2.52.0.windows.1

Additional context

I assumed the issue is main vs. master, but I have other repos where the color of commits is green and where the name is 'main' as well. I also tried switching context (switch to other repositories in [1]) and come back to the problematic repository - it didn't help.

[freijon]

After a restart of lazygit the colors are fine:

[ChrisMcD1]

I am able to reproduce on my local as well. Only happens when lazygit is launched in a repo with no commits. A pretty rare thing in the lifecycle of a repo (at least in the worlds I'm in), but a fun bug none the less!

I imagine the detection of what the main/master branch is relies on a git command that expects there to be commits.

I'll dig a bit more to see if that jumps out to me

[ChrisMcD1]

Okay, color is set here: https://github.com/jesseduffield/lazygit/blob/d1d2bb23b6b9d862fbd16aac20b029eec01ddc8d/pkg/gui/presentation/commits.go#L491 which comes from being set here: https://github.com/jesseduffield/lazygit/blob/d1d2bb23b6b9d862fbd16aac20b029eec01ddc8d/pkg/commands/git_commands/commit_loader.go#L555 which based on the fact that they are showing yellow, means we must be hitting this code path: https://github.com/jesseduffield/lazygit/blob/d1d2bb23b6b9d862fbd16aac20b029eec01ddc8d/pkg/commands/git_commands/commit_loader.go#L552

With the magic powers of log statements, it is indeed true that we are entering this code with two nils

We in the other branch found unpushedCommitHashes {nil},  unmergedCommitHashes {nil}

I have a strong suspicion that this is down to the behavior of how we determine mainBranches, it seems it is empty on first launch:

We got main branches []

Indeed, our systems to check what the main branch of a repo is do not handle this well https://github.com/jesseduffield/lazygit/blob/d1d2bb23b6b9d862fbd16aac20b029eec01ddc8d/pkg/commands/git_commands/main_branches.go#L85-L121

The fallback that is designed to work for a local-only branch

git rev-parse --verify --quiet refs/heads/master

does not return success when you do not have a commit on master.

Created a workaround using git symbolic-ref HEAD here: https://github.com/jesseduffield/lazygit/pull/5079