GIT-REQUEST-PULL(1)

πŸ’– GIT-REQUEST-PULL(1) πŸ’–

okay so bestie, welcome to the git-request-pull manual page, fresh out of the Git Manual ✨ this one's a real one, fr fr 🫢


✨ NAME ✨

git-request-pull β€” generates a summary of pending changes


🌸 SYNOPSIS 🌸

git request-pull [-p] <start> <URL> [<end>]

πŸ¦‹ DESCRIPTION πŸ¦‹

So what this does: it generates a request asking your upstream project to pull changes into their tree. The request gets printed to standard output, and it starts with the branch description, summarizes the changes, and then says where they can be pulled from. It's giving "hey bestie, come get this work" energy πŸ‘‘

The upstream project is expected to already have the commit named by <start>, and the output asks it to integrate the changes you made since that commit, up to the commit named by <end>, by visiting the repository named by <URL>. That's the whole vibe. No cap.


πŸ’… OPTIONS πŸ’…

  • -p β€” include patch text in the output. yes, the actual patches. slay.
  • <start> β€” the commit to start at. this names a commit that is already in the upstream history β€” like, they have it, you're not introducing it, it's a known entity πŸ’–
  • <URL> β€” the repository URL to be pulled from. this is where they come get it.
  • <end> β€” the commit to end at (defaults to HEAD). this names the commit at the tip of the history you're asking to be pulled. lowkey the important one 🌟

When the repository named by <URL> has the commit at a tip of a ref that is different from the ref you have locally, you can use the <local>:<remote> syntax, to have its local name, a colon :, and its remote name. iykyk πŸŽ€


🌈 EXAMPLES 🌈

Picture it: you built your work on your master branch on top of the v1.0 release, and you want it integrated into the project. First you push that change to your public repository for others to see:

git push https://git.ko.xz/project master

Then, you run this command:

git request-pull v1.0 https://git.ko.xz/project master

which will produce a request to the upstream, summarizing the changes between the v1.0 release and your master, to pull it from your public repository. iconic behavior honestly πŸ’…βœ¨

Now, if you pushed your change to a branch whose name is different from the one you have locally, e.g.

git push https://git.ko.xz/project master:for-linus

then you can ask that to be pulled with

git request-pull v1.0 https://git.ko.xz/project master:for-linus

see what they did there? the <local>:<remote> thing. main character energy fr 🧚


πŸ‘‘ GIT πŸ‘‘

Part of the git(1) suite πŸ’œ


and that's the whole page bestie!! πŸŽ€ this is Git 2.56.0, dated 09/28/2026, and it's literally part of the git(1) suite β€” go forth and request those pulls, you absolute legend πŸ«Άβœ¨πŸ’–
πŸ“¦ where this page comes from
  • fedora 43: git 2.56.0-1.fc43 Β· BSD-3-Clause AND GPL-2.0-only AND GPL-2.0-or-later AND LGPL-2.1-or-later AND MIT
  • fedora 44: git 2.56.0-1.fc44 Β· BSD-3-Clause AND GPL-2.0-only AND GPL-2.0-or-later AND LGPL-2.1-or-later AND MIT
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms