GCLI-PULLS(1)

๐Ÿ“ฆ
version 2.13.0 ยท 5 versions
, in nixpkgs unstable, ubuntu stonking

๐Ÿ’– GCLI-PULLS(1) ๐Ÿ’–

okay bestie, welcome to the General Commands Manual page for gcli-pulls โ€” yes that's the manual section 1 vibe, we're in the big leagues now. this is your girl's guide to pulling up on Pull Requests like the main character you are. let's GO ๐Ÿซถ


โœจ NAME โœจ

gcli pulls โ€” Manage Pull Requests on Git Forges ๐ŸŒˆ


๐ŸŒธ SYNOPSIS ๐ŸŒธ

here's the shape of it, queen:

gcli pulls [forge-path] [-a] [-A author] [-L label] [-M milestone] [-s]
           [-n n] [-o owner -r repo] [search-terms...]
gcli pulls [forge-path] -i pr [-o owner -r repo] actions...
gcli pulls [forge-path] create [-o owner -r repo] [-t branch]
           [-f owner:branch] [-y] [-R reviewer] [-T template] [PR
           title...]

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so, gcli pulls is the one you call when you wanna list, create, edit or delete Pull Requests (we call 'em PRs, iykyk) in repositories living on all kinds of git(1) forges โ€” think GitLab, Gitea, GitHub, the whole friend group ๐Ÿ’…

and if you don't specify literally any action at all? no worries. gcli pulls will just list open PRs in the repo you gave it, or the one it auto-detects like the psychic bestie it is ๐Ÿ”ฎ


๐Ÿ‘‘ OPTIONS ๐Ÿ‘‘

the full menu, no skips, no cuts:

  • -s, --sorted โ€” flips your output upside down so the most recent items show up at the bottom. yes, bottom. it's giving reverse chronological ๐Ÿ’ซ
  • -o, --owner owner โ€” list PRs in the repository of the given owner. โš ๏ธ this one only works in combination with -r. they're a package deal, no solo careers here.
  • -r, --repo repo โ€” list PRs in the given repo. same energy: only usable in combination with -o. ๐Ÿซถ
  • -A, --author author โ€” filter pull requests by the given author.
heads up bestie: the implementation is somewhat limited on GitHub and Gitea, because those APIs do not allow off-loading the filtering to its side ๐Ÿ˜ญ so using this option may take an increased amount of time, since gcli pulls has to iterate all the fetched data and filter out the requested information itself. she's doing it manually, respect her effort.
  • -L, --label label โ€” filter pull requests by the given label. see the notes about the -A option above โ€” same reasoning applies here too, no cap.
  • -M, --milestone milestone โ€” filter pull requests by the given milestone. and again, see the notes about the -A option above โ€” the same reasoning applies. โœจ
  • -a โ€” list all PRs, including closed and merged ones. cannot be combined with actions. this does not affect the -n option. and note that this flag has a different meaning in the create subcommand โ€” go peek at SUBCOMMANDS for the deets ๐Ÿ‘€
  • -n, --count n โ€” fetch at least n pull requests. default: 30. if n is set to -1 it'll fetch all pull requests. โš ๏ธ but bestie, on large repositories fetching all pull requests can take a considerable amount of time and may result in rate limiting by the respective API. pace yourself.
  • -i, --id PR โ€” execute the given actions on the specified PR. it's the โœจ target selector โœจ

๐ŸŽ€ SUBCOMMANDS ๐ŸŽ€

create

Create a new PR in the given or auto-detected repository. your editor is gonna come up and ask you to enter the PR message, so get those typing fingers ready ๐Ÿ’…

if the pull request submission has failed, gcli will store the entered message in a file called gcli_message. and whenever this file exists in the current working directory, gcli will ask you whether you wish to recall its contents for the pull request message. it remembers. she's thoughtful like that ๐Ÿ™ˆ

when the title is omitted, gcli will interactively prompt you for the various options listed below, including the title.

the following flags can be specified:

  • -o, --owner owner โ€” specify the owner of the repository where the PR is to be created.
  • -r, --repo repository โ€” specify the name of the repository where the PR is to be created.
  • -t, --to branch โ€” the target (base) branch of the PR. this is the branch the commits are to be merged into. you may omit this flag if you have set pr.base in your .gcli config file. โœจ
  • -f, --from owner:branch โ€” the source (head) branch of the PR. this is the branch that contains the commits that are to be merged into the target repository. you may omit this flag and gcli will try to infer this information. she'll figure it out ๐Ÿ”ฎ
  • -y, --yes โ€” do not ask for confirmation before creating the PR. assume yes. consent pre-granted, periodt.
  • -a, --automerge โ€” enable the automerge feature when creating the PR. slay โœจ
  • -R, --reviewer reviewer โ€” add the given reviewer as a reviewer for the pull request that is to be created. to add multiple people as reviewers, specify this option more than once โ€” one for each reviewer. stack 'em up ๐Ÿ’…
  • -T, --template template โ€” use the provided template as a template for the PR message. the template file is going to be loaded into the editor to let you edit it further.
  • PR Title... โ€” the title of the Pull Request or Merge Request. name it, queen ๐Ÿ‘‘

๐Ÿ”ฅ ACTIONS ๐Ÿ”ฅ

actions... may be one or more of the following:

  • all โ€” get all the relevant information about a PR. the following actions are implied: status, op, commits and ci. it's the everything-bagel of actions ๐Ÿฅฏ
  • checkout โ€” do a git checkout of the head branch associated with this pull request. this requires that git(1) is available in the PATH and that the current working directory resides within a clone of the target repository. no clone, no checkout, bestie.
  • commits โ€” print the list of commits associated with the Pull Requests.
  • comments โ€” print a list of comments under the PR. ๐Ÿ’ฌ
  • status โ€” print metadata of the commit such as the ID, head and base branch etc.
  • op โ€” print the original post of the Pull Request.
  • ci โ€” print a list of checks that ran on the PR (GitLab Pipelines and GitHub CI). vibe check on your pipeline ๐ŸŒˆ
  • diff โ€” print a diff of the changes attached to the PR. this can be piped into patch(1) or git-apply(1). iconic combo.
  • close โ€” close the PR.
  • reopen โ€” reopen a closed PR. she's back ๐Ÿฆ‹
  • merge [options] โ€” merge the PR. the source branch is deleted by default unless you set the pr.inhibit-delete-source-branch option to yes in your .gcli file. you may supply the following options:
    • --squash, -s โ€” squash the commits before merging.
    • --inhibit-delete, -D โ€” delete the source branch after merging.
  • milestone milestone-id โ€” assign the pull request to the given milestone-id.
  • milestone -d โ€” clear a set milestone on the pull request.
  • notes โ€” alias for the comments action that prints a list of comments associated with the PR.
  • labels [options] โ€” the following options can be specified more than once:
    • add label โ€” add the given label to the pull request.
    • remove label โ€” remove the given label from the pull request.
  • title new-title โ€” change the title of the pull request to new-title.
  • review โ€” review the pull request. see gcli-pulls-review(1) for more details on this action. ๐Ÿ‘€
  • assign user โ€” assign the pull request to the given user.
  • open โ€” open the PR in a web browser using xdg-open(1). out into the world she goes โœจ
  • reviews โ€” list reviews of this pull request.
  • discussions โ€” print the review discussions in a threaded form. this is currently only implemented for GitHub. ๐Ÿ™
  • approve [options] โ€” give your approval on the pull request. you may supply the following options:
    • --yes, -y โ€” do not ask for confirmation.
    • --template, -T file โ€” use the file as a template for the approval message. when used with --yes this will make the approval non-interactive.
  • unapprove [options] โ€” revoke your approval on the pull request. for allowed options see approve. not your fave anymore, it happens ๐Ÿ’€

๐ŸŒŸ EXAMPLES ๐ŸŒŸ

print a list of open PRs in the current project:

$ gcli pulls

create a new PR and let gcli interactively prompt you for details:

$ gcli pr create

create a new PR in the current Project, the head is the currently checked out branch of git. see git-status(1). the base will be what pr.base in .gcli is set to.

$ gcli pulls create "summary here"

print both a summary and comments of PR 11 in herrhotzenplotz/gcli:

$ gcli pulls -o herrhotzenplotz -r gcli -i 11 all comments

merge PR 42 in the upstream repository:

$ gcli pulls -i 42 merge

note that you could also pull the PR head and merge it manually into the base branch. assuming trunk is the base branch:

$ git fetch upstream pull/42/head:42-review
$ git checkout 42-review
$ <make etc>
$ git checkout trunk
$ git merge --no-ff 42-review

list pull requests that have the โ€œbugโ€ label:

$ gcli pulls -L bug

list pull requests that are associated with the milestone โ€œversion420โ€:

$ gcli pulls -M version420

change the title of pull request #42 on GitHub to โ€œThis is the new titleโ€:

$ gcli -t github pulls -i 42 title "This is the new title"

same command as above, but with abbreviated pulls subcommand:

$ gcli -t github pu -i 42 title "This is the new title"

list open PRs in herrhotzenplotz/gcli on GitHub using the forge path shorthand:

$ gcli pulls gh:herrhotzenplotz/gcli

๐Ÿ’ซ SEE ALSO ๐Ÿ’ซ

git(1), git-merge(1), git-branch(1), gcli(1), patch(1)

like, go read the whole squad, they're all linked ๐Ÿ’œ


๐Ÿงš AUTHORS ๐Ÿงš

Nico Sonack aka. herrhotzenplotz <nsonack@herrhotzenplotz.de> and contributors. give them their flowers, they built this ๐Ÿ’


๐Ÿ’€ BUGS ๐Ÿ’€

please report bugs via E-Mail to https://lists.sr.ht/~herrhotzenplotz/gcli-discuss.

alternatively you can report them on any of the forges linked at https://sr.ht/~herrhotzenplotz/gcli. however, the preferred and quickest method is to use the mailing list. fr fr, mailing list first ๐Ÿ™


and that's the whole page, bestie!! this was gcli 2.13.0, dated 05-Aug-2026 โ€” pull up, ship PRs, and remember: you're the main character of your own repo ๐Ÿ‘‘๐Ÿ’…โœจ

๐Ÿ“ฆ where this page comes from