Bitcoin Forum

The bitcoin integration/testing source tree is at GitHub (https://github.com/bitcoin/bitcoin), and we (jgarzik/tcatm/gavinandresen right now) use GitHub's "pull request" feature to keep track of patches that people think are ready for integration into mainline bitcoin.  This post is a walk-through of how to create a pull request.

1. You'll need a GitHub account; sign up for free (http://github.com/signup), and set up git and ssh (http://help.github.com/set-up-git-redirect) to work with GitHub.

2. You need a fork of the main bitcoin source tree.  Login to your GitHub account, browse to the bitcoin project (https://github.com/bitcoin/bitcoin), then poke the little 'Fork' button near the top of the screen.

3. Connect that fork at GitHub with source code on your development machine.  The easiest way to do that is to clone your github fork, using the SSH Read+Write URL github shows you on your fork's page.  For example:
You might already have a clone of the bitcoin git tree that you've modified; you should push those changes into your new GitHub fork.  Assuming you made your changes in the 'master' branch on your machine (next time you should create a specific feature branch), the command would be:

4. Submit a PULL request by going to your fork's GitHub page, selecting the branch containing the changes you want pulled ("niftynewfeature" in the above example), and then poking the "Pull Request" button.  Enter a good description of what your changes do and why they're a good idea and how everybody and their brother is already using them to make the world a better place .

Eventually, if all goes well, after discussion and argument and nit-picking and revision, your changes will get pulled into the bitcoin repository.  If all doesn't go well, you (or the core developers) can close your pull request and resubmit it when the feature is perfect.

I think it's possible to do something along the line of:


Then you'll only need to do:


You can also add a commit message by using the -m flag:


This way you won't end up in Vim (and freak out). This is more usefull for shorter commit messages though.

...or you could just tell git what editor you'd prefer (http://book.git-scm.com/5_customizing_git.html)!

Me too. Thanks Gavin.

For those of us that are ignorant, can somebody tell me what a PULL request in layman's terms is? And what is it used for?

Since the project is open source, anyone can change the files.  However, this creates a "fork", their version of the software is different from everyone else's.  This means that they need to incorporate any future changes into their fork.

A pull request allows them to submit the change back to the main project.  If it is accepted, the changes become part of the official version of the software. 

It can be properly understood when you know what a Distributed Version Control System is. Start with http://progit.org/book/ (http://progit.org/book/).

Can anyone help me figure out how to do the following?

1. Get the latest version at bitcoin/bitcoin
2. Apply just sipa's pull request called "Wallet Import and Export" to my own copy so I can compile it in.

Thanks

EDIT: Asking a question seems to guarantee I will find the answer right after I ask.  My end result was to git clone bitcoin/bitcoin, and then download https://github.com/bitcoin/bitcoin/pull/220.diff, then git apply, then compile.

I've made a new locale file "bitcoin_zh_CN.ts",How can i upload it to my github fork and make a pull request?

I've made my fork of bitcoin on github.com, I've installed Git, and cloned my fork.
I ran
git push origin master
It shows:  
everything up-to-date
and nothing changed to my fork on github.com

but i've copy "bitcoin_zh_CN.ts" to the directory "bitcoin/src/qt/locale",
clearly

What should i do? (http://github.com/finway-china/bitcoin)


EDIT:
Yeah, done my first pull request :)

git add bitcoin_zh_CN.ts
git commit
EDIT
git push origin master

or optionally (for posterity of a stickied thread):


Explanations for -A (http://stackoverflow.com/questions/572549/difference-of-git-add-a-and-git-add) and -u (http://stackoverflow.com/questions/5697750/what-exactly-does-the-u-do-git-push-u-origin-master-vs-git-push-origin-ma).  Generally only use -A if all the modifications to be committed are a single bundle of functionality, describable by the same commit message.

What happens if I already submitted the pull request and then commit a fix to my patch, so there are now 2 commits in that pull request. Am I supposed to squash the commits into one? Do I need to re-submit my pull request afterwards?

You do not have to resubmit the pull request.  Squash the commits into one, and then "git push --force" to "rebase" the branch.

Is the decision for acceptance determined by a developer?

Whether or not your pulls get accepted depends on a rough consensus of the devs.  Some of them have a bit more pull than the others, but there isn't like a formal voting process.

If you are submitting pulls, you'll get emails from github when people comment on it.  Pay attention to those, the people making them are giving advice earned through hard experience.  Address their concerns when you can, and be prepared to defend your choices.

Also start hanging out in #bitcoin-dev on IRC.  It can be very helpful to start conversations about your pull, particularly with the people that have commented on it.  Be polite, and keep in mind that they can be busy, even if you can't see it.

Thank you for your advice. I definitely will be checking out the IRC channel.

Is it fair to say then, that Bitcoin is not completely decentralized? I am only asking to better my understanding, but it seems there is some amount, even if minor, of centralization.

The only completely and utterly decentralized bitcoin-like system I can think of would have every person using it write and run their own code.

On computers that they built themselves.

Communicating over a wireless mesh network where each node in the mesh was controlled by a single person who wrote all the code and built all the hardware....

Right - maybe the word "completely" was stronger than what I needed.

The mechanics of bitcoin differ from something like gold, because gold was created by nature, and bitcoin is managed by people. And anything managed by people is centralized to some extent.

I will do some reading and try to understand the PULL process.

To me, Bitcoin is valuable not because of how much it is "decentralized" and "democratic", but simply because it allows choice including option to exit the club at any time. I have a choice to build my own software, I have choice to suggest an improvement to others, I have choice to mine coins myself, or buy them, or stash them away and sell any time in the future. Of course, my freedom of choice is limited by my resources and your willingness to cooperate with me. But that's voluntary. Neither you, nor me can impose our will on each other. So I can use bitcoins with peace of mind knowing that they are built on top of voluntary interactions instead of enslavement. If I get rich or poor, it will be only because of my voluntary choices, so there will be no one to blame but myself.

Well Said oleganza!

Great tut +1 for the info

Well just got it
Still a bit technical need to keep learning
Thanks for the info  ;D

I'm having a fight with git. 

Here's what I want to do. 

I want to throw away all local changes, including those committed to the local git repository, and make my project directories look exactly like the ones that were most recently checked into the remote master, from a different git repository. 

That is, with NO attempt to "merge" local changes, NO local files hanging around that aren't in the upstream, NO version garbage inserted into files ... Just plain abandon this branch and go back to trunk development. 

In every other revision control system I've ever encountered, that is a simple command.  But either I am too stupid to know how the hell to ask  Git to do this, or Git is too stupid to get it done.

"Git revert" doesn't even destroy local files that aren't part of the version you're reverting to!  What the hell is wrong here?

Thanks for the tutorial.

(or replace 'origin' with whatever you called the remote)

git revert is there to revert already checked-in commits with a reverse patch. You will likely use it very sparingly, if at all.

Yep.  Finally figured it out about a day after I made that post.  Thanks though.

I've been getting used to Git, but it's a very annoying RCS. 

what if i pull 2 requests

it is used to request a merge of different versions of versioned files in so called "Versioning file systems"
just google for the term :)

Thanks for this OP, This is something I have been interested in learning, I have been using git for a few months, but only within my own repo, so I have been avoiding learning how to do this.
btw @zulu I love using the -m flag as well,  :D

Do I need to create a pull request to suggest translation fixes?

In simple Words, Pull requests let you tell others about changes you've pushed to a GitHub repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

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 and your master, to pull it from your public repository.

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

A good start:
https://help.github.com/articles/set-up-git/

if you get stuck, lots of people will be able to help.  ;-)

Pull requests let u tell others about changes you have pushed to a repository on GitHub. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Thank you for the post and information.  :)

Im not clear with the pull request and github.. Can anyone say me clearly about this.. Thanks

This is the right method for creating pull request im using this in my every project. If you have any query then contact me via email info@clapcreative.com or +13479604186

will done

its not working for me

pull requests are a mechanism for a developer to notify team members that they have completed a feature. Once their feature branch is ready, the developer files a pull request via their Bitbucket account. This lets everybody involved know that they need to review the code and merge it into the master branch.

But, the pull request is more than just a notification—it’s a dedicated forum for discussing the proposed feature. If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits. All of this activity is tracked directly inside of the pull request.

Git Workflows: Activity inside a pull request
Compared to other collaboration models, this formal solution for sharing commits makes for a much more streamlined workflow. SVN and Git can both automatically send notification emails with a simple script; however, when it comes to discussing changes, developers typically have to rely on email threads. This can become haphazard, especially when follow-up commits are involved. Pull requests put all of this functionality into a friendly web interface right next to your Bitbucket repositories.

Anatomy of a Pull Request
When you file a pull request, all you’re doing is requesting that another developer (e.g., the project maintainer) pulls a branch from your repository into their repository. This means that you need to provide 4 pieces of information to file a pull request: the source repository, the source branch, the destination repository, and the destination branch.

Git Workflows: Pull Requests
Many of these values will be set to a sensible default by Bitbucket. However, depending on your collaboration workflow, your team may need to specify different values. The above diagram shows a pull request that asks to merge a feature branch into the official master branch, but there are many other ways to use pull requests.

How it works

Pull requests can be used in conjunction with the Feature Branch Workflow, the Gitflow Workflow, or the Forking Workflow. But a pull request requires either two distinct branches or two distinct repositories, so they will not work with the Centralized Workflow. Using pull requests with each of these workflows is slightly different, but the general process is as follows:

A developer creates the feature in a dedicated branch in their local repo.
The developer pushes the branch to a public Bitbucket repository.
The developer files a pull request via Bitbucket.
The rest of the team reviews the code, discusses it, and alters it.
The project maintainer merges the feature into the official repository and closes the pull request.
The rest of this section describes how pull requests can be leveraged against different collaboration workflows.




you can check in
https://www.atlassian.com/git/tutorials/making-a-pull-request/how-it-works

I stand by. Thanks!

Great, thanks for the info.

You have explained the method and its use that well even someone who not really was into coding could understand the wisdom in the method. Thank you for this information! It also is a nice example when PULL request becomes useful.

Since the project is open source, anyone can change the files.  However, this creates a "fork", their version of the software is different from everyone else's.  This means that they need to incorporate any future changes into their fork.

A pull request allows them to submit the change back to the main project.  If it is accepted, the changes become part of the official version of the software.

There is a beautiful tutorial posted by github ,I think its a video and a step by step tutorial on one of the GH pages .That is the most simplest tutorial I have seen yet.

To create a pull request, you must have changes committed to the your new branch. Go to the repository page on github. And click on "Pull Request" button in the repo header. Pick the branch you wish to have merged using the "Head branch" dropdown.