Multiple origin support

[arusahni]

It'd be great to be able to support these use-cases:

1. I receive a GitHub PR. While I can check it out by number, I can't push commits to it unless I can check out the remote branch.
2. I'm mirroring a private repo publicly, and want to specify the remote to track.
3. I don't use origin, and instead use something else.

Todo:

• [x] Allow users to specify the remote when checking out a MR/PR
• [x] Prefix the checked out MR/PR branches with the remote when using the non-default
• [x] Stub out logic for determining if the current remote is the default
• [x] Infer the default on first run and write it
• [x] Prompt the user to specify a default if none can be inferred
• [x] Provide CLI tooling to allow for the default to be modified

[Jonathas-Conceicao]

Hello, I would like to implement this feature. I have a minimal working implementation on my fork but I have a couple of questions:

1. I'm not sure I understood your item 2, is it any different than item 3 our just a specific case?
2. Should the new branch created/used for the pulled PR contain the remote name? And if so, when using origin should it also use a different name? I think not changing the branch's name might lead to conflicts when pulling from different remotes, but I'm not sure if this changes would break backwards compatibility.

[arusahni]

Hi! Thanks for taking this one.

1. Close. A way to phrase this: for case 2, my "primary" repo is origin, while in case 3, origin may not be my "primary".
   • For case 2, users may have an origin remote for their private github repo, and gh for their public github. Someone submits a PR to that repo. I'd like to check out the PR for that repo, but git-req currently uses origin.
   • For case 3, the ability to specify what the default/base remote is for a project. e.g., git-req --set-primary-remote <remote_name>
2. I like the idea of avoiding tracking conflicts by prefixing the branch with the remote name. Similar to how GitHub does pr/{mr} number, we could do {remote_name}/{branch_name}.

Backwards compatibility is an interesting concern. I wonder if it would make sense to make this opt-in (for now) with a --editable flag for the case of checkout out a PR from a satellite repo.

Thoughts? Now that I've teased this out, it sounds like there are probably multiple tickets here.

[Jonathas-Conceicao]

So, from what I get, I think these can be two different modifications. The first one is to allow pulling a PR from a non default (non 'origin') remote name, while the second one is to have a settings entry that tells what the default remote name would be.

And as for the branch's naming convention, that means we would have something like: origin/pr/42 for a PR tracking origin and a upstream/pr/42 for a PR tracking a upstream? I like the idea, but if we had only pr/42 for when pulling from the default (e.g. origin) and upstream/pr/42 for when pulling from a upstream named remote, and I think this is enough to making this change backwards compatible and I think it's still intuitive.

[arusahni]

After merging #38 and #42, all that remains is:

1. Update the get_default_remote function to read the set value. a. If no value is set, try to infer using the existing logic (the existing remote name if only one, else origin)

   • If still can't be inferred, prompt the user

   b. set the default remote

2.. Provide an interface to change the default (via CLI flags)