Add fallback to detecting main branches for fresh repositories

[ChrisMcD1]

PR Description

All other attempts to determine the main branch fail on a fresh repository right after git init because there are no actual commits that these branches point to.

Fixes #5058

Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[ChrisMcD1]

Converted to draft while I fix up the test failures

[stefanhaller]

I don't think this is the best approach; it doesn't address the root cause. There are other situations where the main branches get stale, for example if you rename your master branch to main; you'll have to restart lazygit for it to pick up that change, too. I'd prefer a solution that takes care of all these situations.

The real issue is that we cache the determined main branch refs and then never forget them again (unless the user config changes). The challenge is to find the right conditions under which to drop the cache; an easy and straightforward solution would be to drop the cache at the beginning of refresh whenever the refresh scope includes commits or branches, but I'm not sure we want to afford that. Maybe it's good enough (it won't affect the timing of starting up lazygit, which is the most important), but we'd have to take some measurements to see if we want to incur the cost on every refresh.

Investigating this didn't have high priority for me so far because the situations in which it is buggy are so rare, and easily fixed by restarting lazygit.

[ChrisMcD1]

I don't think this is the best approach; it doesn't address the root cause. There are other situations where the main branches get stale

I don't consider this bug report a matter of staleness, and do think this is a root cause fix. This bug occurs on fresh repositories right after a:

git init
lazygit

because none of the previous 3 methods of detection of main branches work without an associated commit (all rev-parse based). You could restart lazygit 1000 times, the first commit you make will still be incorrectly tagged. As a new user experience scenario, it feels slightly more important than a bug that happens in odd scenarios after doing many interactions and keystrokes. However....

it won't affect the timing of starting up lazygit, which is the most important

If the primary objection is that this would add a few ms potentially to startup times as we reach this 4th fallback for non-relevant branches like main on a master based project, then I have no strong reason to disagree with that stance. I am happy to close this PR and consider the reporting bug a Wont-Fix on those grounds.