0

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.

halfer
  • 19,824
  • 17
  • 99
  • 186
Tim
  • 1
  • 141
  • 372
  • 590
  • 1
    Unless your using forks (typically only open source, gut hub, etc.) then you should never need `git pull-request`. You should all just `push` and `pull` form one repo. Pull requests are only useful in a collaborative environment where you don't trust the people committing, so need to check their commits before merging them in, etc – Liam Jan 16 '19 at 14:16
  • *share a remote repository* yes, this is the thing, your sharing a repository. `pull-requests` are for merging between remote repositories ([forks](https://stackoverflow.com/a/6286877/542251)) – Liam Jan 16 '19 at 14:23
  • @Liam between any two repos, surely? For example, if one doesn't use a cloud repo host like github or bitbucket. – evolutionxbox Jan 16 '19 at 14:29
  • I guess so. Why would you do that though? Source control is usually multiple people accessing some kind of backed up remote repo (star pattern). – Liam Jan 16 '19 at 14:32
  • When you make one or more new commits from a base, you are implicitly or explicitly creating a new branch. A pull request or the output of `git request-pull` tells others that you have created a branch from a revision and made some new commits, and where they can get this new branch if they need these commits. If they need one or some or all of these commits, they can fetch the branch from the repository and then apply as many commits as they need, by `git merge`, `git rebase`, `git cherry-pick`, etc. The branch may be a real branch like `refs/heads/foo` or a ref like `refs/changes/22`. – ElpieKay Jan 16 '19 at 14:54

1 Answers1

2

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.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks. "if you're using a shared remote repository, git request-pull is almost entirely redundant and pointless." Do you mean "a shared remote repository" is writable? Why `git request-pull` is almost entirely redundant and pointless"? What should be used instead of `git request-pull`? – Tim Jan 19 '19 at 04:59
  • *Do you mean "a shared remote repository" is writable?* Yes. (What else would "shared" mean here? A read-only access repository could be called "shared", but I've never heard the word used that way—people call them "public" and/or "read-only".) Given this shared (i.e., writeable) repository, you simply `git push` to it as usual. – torek Jan 19 '19 at 07:48