`gh pr checkout` default should be the same as `gh pr list`, and optionally also support `--limit`

[kahlstrm]

Describe the feature or problem you’d like to solve

Before gh pr checkout had the interactive mode support added, I had a DIY version of it:

gh pr list | fzf | awk '{print $1}' | xargs gh pr checkout

That worked quite well, but I have started using gh pr checkout interactive mode instead.

However, I noticed that the number of PRs listed with the new interactive mode is limited to 10, and that value is hardcoded. In contrast, the old version's default seems to be 30 and can even be overridden with the --limit flag.

Proposed solution

Either change the default limit to match gh pr list, add --limit support to gh pr checkout interactive mode, or both.

How will it benefit CLI and its users? Users can have a more flexible way of using the gh pr checkout interactive mode.

Additional Context

I have already a local checkout with these changes, but noticed the CONTRIBUTING.md after implementing this.

[williammartin]

@BagToad I think you did the original implementation of this, would you mind triaging it since you probably have context on the current behaviour.

[BagToad]

Thanks for the issue @kahlstrm 🙏 & thanks for the ping @williammartin

Here's some context for everyone, before anything actionable:

This was feedback I knew was coming when we did this because I felt it myself in https://github.com/cli/cli/pull/9868#issuecomment-2533069026 under the "💭 Listing only 10 PRs feels like it might not be enough" heading.

In that comment, I brought up having a --limit flag, but noted that this is a trailblazing move as other commands that list out things interactively don't have a --limit flag AFAIK. I hesitate on what solution is best here because whatever we choose will no-doubt become the standard and we will be stuck with it.

I'll also just note that the 10 pull request limit comes from alignment with run view which is a bit of a closer partner than pr list because run view is prompting for a thing and then doing something with the selection, just like we are with pr checkout here. I'm not saying I like 10 or that I like 30 instead, but that's context on where it came from. To be honest, I think raising this to 30 would still be a band-aid.

---

Moving forward, I think it would be good to get the rest of the maintainer team's opinion on --limit since that seems to be the most ideal solution to me right now. Please see https://github.com/cli/cli/pull/9868#issuecomment-2533069026 for other options, if interested.

@cli/code-reviewers:

• How do you feel about the --limit flag controlling how many items come out in an interactive prompt like when gh pr checkout and run view are run with no args?
• Do you have any concerns with this becoming a standard form factor for commands that do this?
• Does this feel like something we want a differently named flag for?

[BagToad]

💭 In the meantime, I'm considering this triaged and pending the team's investigation and feedback.

[kahlstrm]

Thanks for the issue @kahlstrm 🙏 & thanks for the ping @williammartin

Here's some context for everyone, before anything actionable:

This was feedback I knew was coming when we did this because I felt it myself in #9868 (comment) under the "💭 Listing only 10 PRs feels like it might not be enough" heading.

In that comment, I brought up having a --limit flag, but noted that this is a trailblazing move as other commands that list out things interactively don't have a --limit flag AFAIK. I hesitate on what solution is best here because whatever we choose will no-doubt become the standard and we will be stuck with it.

I'll also just note that the 10 pull request limit comes from alignment with run view which is a bit of a closer partner than pr list because run view is prompting for a thing and then doing something with the selection, just like we are with pr checkout here. I'm not saying I like 10 or that I like 30 instead, but that's context on where it came from. To be honest, I think raising this to 30 would still be a band-aid.

Moving forward, I think it would be good to get the rest of the maintainer team's opinion on --limit since that seems to be the most ideal solution to me right now. Please see #9868 (comment) for other options, if interested.

@cli/code-reviewers:

• How do you feel about the --limit flag controlling how many items come out in an interactive prompt like when gh pr checkout and run view are run with no args?
• Do you have any concerns with this becoming a standard form factor for commands that do this?
• Does this feel like something we want a differently named flag for?

Thanks for the reply and background!

To be honest, I think raising this to 30 would still be a band-aid.

I agree, as I was just finding a middle ground for past of the least effort to get rid of my problem 😄.

Also, if there are several of these interactive lists that are considered, then perhaps a design decision could be made to about having the behavior similarity with commands close in terms of context (pr list and pr checkout) or in terms of behavior (the interactive part of pr checkout and run view). In either case a good idea would be to add a constant value that would be used for all of these to document this relation. Just an idea that came to mind 😄

As said, I've already implemented a version with --limit of this in my fork, but I guess the limit would also be required for run view as well given the similar nature🤔