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.

[stefanhaller]

none of the previous 3 methods of detection of main branches work without an associated commit

Yes, and the reason is that a branch without commits doesn't really exist yet (it's what git calls an "unborn branch"). It doesn't show up in the output of git branch, and calling git merge-base main feature (which is what we are using the main branches for, mainly) returns an error. So the current code in lazygit is right in not considering such a branch to be an existing main branch.

the first commit you make will still be incorrectly tagged

Yes, and the reason is that we need to re-determine the existing main branches at that point, because the main branch now exists when it didn't before.

If the primary objection is that this would add a few ms potentially to startup times

No, that's not my objection to your fix. I was talking about the performance implications of the other (better) fix, which adds time to every refresh except the one at startup.

consider the reporting bug a Wont-Fix

I wasn't suggesting to close it as won't-fix, I was suggesting to use a different fix instead.