Don't assume remote name is origin

[RBird111]

• PR Description

  • Remove hardcoded assumption that the remote is named origin
    Previously, lazygit assumed the remote was always named origin, causing errors when repositories used a different remote name—even if a valid remote was available. This PR removes that assumption by delegating remote resolution to RemoteCommands, which now identifies the appropriate remote automatically (it one exists). As a result, HostingServiceMgr can consistently be instantiated with a valid repoURL, regardless of the remote’s name.

  • Disable the option to copy the URL for local-only commits
    While testing, I noticed that lazygit generates a URL for commits that exist only locally, which results in a 404 when opened. This portion of the PR disables the “Copy Commit URL” option for commits that are not present on any remote branch. I achieved this by adding a commitExistsOnRemote func(string) bool field to the HostingServiceMgr and populating it with a new RemoteCommands.CommitExistsOnRemote helper method at instantiation.

    I’m not fully satisfied with my current implementation—it feels clunky—so I’d welcome any suggestions for improvement.

  Resolves in commits, if yu (aka Copy URL of commit) it always assumes the remote is named origin #4746.

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

[stefanhaller]

I don't think this approach works, as I tried to explain over in the issue. You are using the upstream branch of the currently checked out branch to see which remote it is on; this works for local commits (in the commits panel), but is wrong for when you press enter on another branch in the branches panel, if that branch's upstream is on a different remote. We need to find a way to pass the information about the upstream branch down to where we need it; also, we shouldn't have to make any git calls to determine this information (except for the ls-remote call), because we have it all in memory in our models already.

I can have a closer look at all this next week.

[stefanhaller]

I started looking into this a little bit today (didn't get far yet). My feeling is that we need to pass the name of the remote to the getHostingServiceMgr call; I think I can help with how to determine the name of the remote for the various situations this can be called from, but one thing I'm stuck on is what this means for the "View create pull request options" menu (shift-O). I have never quite understood what the various options in that menu mean, and how they would be affected. Am I the only one to be confused by this? I feel we need to start by cleaning up this feature (at the very least by providing tooltips that explain what the various options mean, but preferably by making the UI clearer somehow). Can anybody help with this?