feat: add fork remote command

[karolzwolak]

PR Description

The command allows you to quickly add a new 'fork' remote with
replaced owner in the origin URL of the selected remote.

For example:
given url: https://github.com/jesseduffield/lazygit.git
and username: karolzwolak
adds a new remote with url: https://github.com/karolzwolak/lazygit.git

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

clip.mp4

[stefanhaller]

Thanks for the PR, and sorry for the long delay in looking at it.

This is a useful feature, I need it myself frequently. Before I review in detail, a few general thoughts:

• it would be even more useful if it could take a repo:branch specification and create the remote and check out the branch in one go. For example, for this very PR I would click the copy-to-clipboard icon here:
  , invoke the command, and paste. Any thoughts on this?
• I didn't look at the code in detail yet, I only noticed from a cursory look that there are many lines of code related to parsing URIs. Is this really needed? Intuitively I would have thought that the implementation would consist of basically a single line of code doing a regex replace. I may well be missing something here, and I should probably look at the code in detail before asking questions like this.
• How much of this is github specific? For me personally, github is the only hosting service that I have experience with, but lazygit supports a bunch of others (gitlab, azure devops, gitea, bitbucket). I wonder if we need to hook into hosting_service.go somehow to make it work for those, too.

[karolzwolak]

Thanks for the PR, and sorry for the long delay in looking at it.

This is a useful feature, I need it myself frequently. Before I review in detail, a few general thoughts:

• it would be even more useful if it could take a repo:branch specification and create the remote and check out the branch in one go. For example, for this very PR I would click the copy-to-clipboard icon here:
  , invoke the command, and paste. Any thoughts on this?

Yes, that's a great follow-up. It should be easy to do, too. I will implement it.

• I didn't look at the code in detail yet, I only noticed from a cursory look that there are many lines of code related to parsing URIs. Is this really needed? Intuitively I would have thought that the implementation would consist of basically a single line of code doing a regex replace. I may well be missing something here, and I should probably look at the code in detail before asking questions like this.

Yeah, I might have gone overboard with the url parsing. I didn't know we had regex support. Regex would work well for ssh urls, but it's a bit more nuanced for http/https urls, but I'll try to simplify it.

• How much of this is github specific? For me personally, github is the only hosting service that I have experience with, but lazygit supports a bunch of others (gitlab, azure devops, gitea, bitbucket). I wonder if we need to hook into hosting_service.go somehow to make it work for those, too.

I also don't have experience besides github, but I think most other hosting services follow the same owner/repo url pattern as github does, so it should work fine without any further modifications. I might be wrong on this, though.

I'm away from home for about 2 weeks, so I won't be active on this right now.

[karolzwolak]

I've refactored the replacement to just use regex replace. I think your suggestion is great follow up, but I think it should be supported not just in this new add fork feature, but also when adding a general remote like somerepo.git:dev. I'll submit separate PR that will implement specifying the branch for all ways of adding a new remote.

@stefanhaller friendly ping

[karolzwolak]

Nevermind, I added the ability to checkout PRs with user:branch. I'm not sure how to name this feature now. Since the branch is optional I kept the old name (add fork remote).

[stefanhaller]

Still didn't look at the code very much, but tested the feature, and it works nicely.

One thing I'm wondering is whether we need the second prompt that asks for a remote name; in my own use, I always use the same name as the forkUsername, doesn't everybody?

And then, I was also wondering if this even needs to be a separate command at all. We could include the functionality in the normal "add new remote" command, where the first prompt would say New remote name (use remotename:branch to check out a branch):, and the second prompt would say New remote url (leave empty to use same pattern as origin):. Any thoughts about that?

[karolzwolak]

One thing I'm wondering is whether we need the second prompt that asks for a remote name; in my own use, I always use the same name as the forkUsername, doesn't everybody?

Not always. I often add my own fork as origin or the main repo as upstream. But if we ditched the name prompt, I guess I could just rename the remote after creating it.
I think the name prompt should stay. You'd just confirm the suggested name most of the time, but there would be an option to name it differently if there's a need.

And then, I was also wondering if this even needs to be a separate command at all. We could include the functionality in the normal "add new remote" command, where the first prompt would say New remote name (use remotename:branch to check out a branch):, and the second prompt would say New remote url (leave empty to use same pattern as origin):. Any thoughts about that?

Incorporating it into add remote sounds nice in theory, but I’m not sure it works as well in practice. You still end up with two prompts and some limits:

• always basing the URL on origin
• no way to rename immediately

It also gets tricky if there’s no origin or multiple remotes. I think incorporating it this way would be too clunky. Dedicated command feels clearer, more powerful, and would allow more flexibility. I'm open to other suggestions for improving this new feature.

[stefanhaller]

I have used this for a while in my local build now, and I quite like it. I'm happy to keep it as a separate command; after thinking about it more, my suggestion to incorporate it into the add remote command wasn't so good.

However, I still can't get used to the second prompt, and I still vote for getting rid of it. The only scenarios I can imagine where you would want a different remote name is either origin itself (but that's irrelevant here), or an "upstream" remote. For that, I'd imagine you would use the regular add remote command; or rename it afterwards. Since that's a one-time thing, I don't find that too bad. But in all other cases the additional prompt is simply confusing, it trips me up every time.

Apart from that, I was thinking if we should have any special handling of the case that a remote with that name already exists; currently you get an error popup, which I guess is appropriate, but I was thinking it might be nice if I didn't have to pay attention and it would just use the existing remote and only check out the branch. But maybe that's too much magic and we just keep it the way it is.