CODEWITHSUNDEEP
gitpull-request
Tim
Tim

Reputation: 99418

What are the relations between git pull-request and git pull and git push?

What are the relations between git pull-request and git pull and git push?

Suppose I and other peers share a remote repository. Each of us has an individual local repository.

When I finish working on a feature in my local repository, I would like to share my work with my peers.

  1. Shall I use git pull-request to ask my peers to git pull from my local repository to their individual repositories?

  2. Shall I run git pull-request with the shared remote repository as its URL argument? If yes, does the command ask the administrator of the shared remote repository to git pull from my local repository to the remote repository? The following three sources seem to say yes.

    The manpage of git pull-request says it "Generate a request asking your upstream project to pull changes into their tree."

    https://stackoverflow.com/a/49432466/10082400 says after someone runs git request-pull, "...Linus can then git pull directly from this other repository, or more likely, git fetch from there and decide whether and how to merge them"

    https://github.com/torvalds/linux/blob/master/Documentation/process/submitting-patches.rst#16-sending-git-pull-requests says "if you have a series of patches, it may be most convenient to have the maintainer pull them directly into the subsystem repository with a git pull operation."

  3. Do I need to git push my work on the feature from my local repository to the shared remote repository before I run git request-pull?

    Why do I need to, if git request-pull will request the administrator of the shared remote repository to pull my work on the feature from my local repository to the shared remote repository?

    The manpage of git pull-request gives an example, which git push before git pull-request". Isgit pushnecessary beforegit pull-request` in the example?

    Imagine that you built your work on your master branch on top of the v1.0 release, and want it to be integrated to 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 andyour master , to pull it from your public repository.

Upvotes: 0

Views: 422

Answers (1)

torek
torek

Reputation: 488103

The git request-pull command, given suitable input, builds a suitable email message. That, literally, is all that it does. The email message goes to the standard output of the command; it is up to you to collect this and send the email, if that is what you wish to do.

The git pull command runs git fetch followed by a second Git command, typically either git merge or git rebase. (For the special case of a pull into an empty repository with no commits, it will run git checkout as its second command.) See any of the many other StackOverflow questions about it.

The git push command has your Git call up some other Git and exchange information, send any commit objects and other internal Git objects that yours must send to complete the last step, and then, as its last step, gives polite requests (non-forced push), compare-and-swap commands (force-with-lease), or command style requests (forced push) asking that the other Git set some of its references to some particular hash IDs.

Your three subsequent questions are about how you can use these various commands and their abilities to build a useful workflow. There are many different ways to do so; it is not possible to prescribe one workflow that is suitable for everyone without making many assumptions about any limits (or lack thereof) on network access and so on. Git itself is much more a system of tools that users can employ however they wish, rather than specific solutions to specific problems.

Still, we can address these three to some extent:

  1. Shall I use git pull-request to ask my peers to git pull from my local repository to their individual repositories?

If you wish, yes. Note that for them to do so successfully, they must have at least read-permissions on your local repository, perhaps via network access.

  1. Shall I run git pull-request with the shared remote repository as its URL argument?

If you wish, yes. However, if you're using a shared remote repository, git request-pull is almost entirely redundant and pointless.

If yes, does the command ask the administrator of the shared remote repository to git pull from my local repository to the remote repository?

No; it will request that they pull from the shared remote repository, which they are, we might assume, already doing frequently anyway. Try running git request-pull to see. Since its output goes to the standard output, you will see precisely what emailing its output to someone else would send to that someone else. In particular, however, it will say:

The following changes since commit %H:

  %s (%ci)

are available in the Git repository at:

  $url $pretty_remote

for you to fetch changes up to %H:

  %s (%ci)

with the various $ and % fields filled in. The $url part is literally whatever you passed in as the URL argument, while $pretty_remote is composed by stripping refs/heads/ or refs/ from the destination part of a refspec argument, if one is provided. See the git-request-pull code (it is a simple shell script) for further details here.

  1. Do I need to git push my work on the feature from my local repository to the shared remote repository before I run git request-pull?

No. As in question 2, if you have a shared repository, git request-pull is almost certainly pointless. The command is designed around the assumption that, for whatever reason, you do not have a true shared repository—that you and your upstream have only read access to each other's repositories.

Upvotes: 2

Related Questions