mr checkout: specify the tracking remote

[claytonrcarter]

I don't use the "1 remote/author" workflow at work; instead we all push branches to a single, shared origin where only some of us have permission to merge to main. As written, mr checkout -t <id> will create/update a remote named after the MR author. In my case, this ends up w/ 2 remotes both pointing to the same URL, which doesn't feel helpful to me. I have hacked around this locally, but before I go making it pretty I'd like to know if anyone else wants this. 😛

My existing hack is just an add'l flag --track-default-remote that tells mr checkout use targetRemote instead of creating a new remote based on mr.Author.Username.

Any interest?

BTW I looked into some way to support something like this:

• --tracking-remote not specified on command line: use mr.Author.Username (current behavior)
• --tracking-remote specified but w/ no value: use default remote
• --tracking-remote=<remoteName>: use remote named remoteName

I got stuck on this b/c I couldn't (quickly) figure out how to coax pflags into working w/ some sort of flag that has different values if it's not specified, vs if it's passed but w/o a value vs w/ a value. (Or even if such a thing is possible.) I eventually just settled for the default remote being fine for me. 😄

[krobelus]

On Mon, Jan 03, 2022 at 10:52:04AM -0800, claytonrcarter wrote: I don't use the "1 remote/author" workflow at work; instead we all push branches to a single, shared `origin` where only some of us have permission to merge to `main`. As written, `mr checkout -t <id>` will create/update a remote named after the MR author. In my case, this ends up w/ 2 remotes both pointing to the same URL, which doesn't feel helpful to me. I have hacked around this locally, but before I go making it pretty I'd like to know if anyone else wants this. 😛

I use the same workflow, so yes, that sounds useful. I didn't look into the UI, but maybe we can use the remote specified in `git config remote.pushDefault`.

[bmeneg]

It seems indeed useful and I would like to test it myself actually :)
Even though I don't use this workflow I already saw other places/friends using it.

• --tracking-remote not specified on command line: use mr.Author.Username (current behavior)

• --tracking-remote specified but w/ no value: use default remote

• --tracking-remote=<remoteName>: use remote named remoteName

Yeah, it would require to specify two flags with the same name, being one a bool and the other string, otherwise the second bullet will eat the following string in the CLI as the flag value (even if the next string starts with --, which would indicate another flag). But it's not possible with pflag/Cobra 😢 .

I didn't look into the UI, but maybe we can use the remote specified in git config remote.pushDefault.

Using the git options here is indeed a valid option, maybe "use remote.pushDefault if set, targetRemote otherwise"?

[fmuellner]

As written, mr checkout -t <id> will create/update a remote named after the MR author. In my case, this ends up w/ 2 remotes both pointing to the same URL

Wouldn't it be better to detect that the MR remote matches the default remote and pick that automatically? The proposed CLI flag sounds like a workaround for something that shouldn't be done in the first place.

[bmeneg]

@fmuellner That's actually a pretty good point.
The checkout should track the remote from where that mr is coming from and we have this information available.

[bmeneg]

@claytonrcarter @fmuellner please take a look at the PR #786 .
@claytonrcarter if possible, could you test it in your local env and workflow?