Pull Request! Or the Hammer of Dave

#1 Maybe the just want feedback and confirmation first, before they submit them to Github, at least that was my motivation so far. But if you know what you are doing and have experience in that you could go straight for submitting it to github.

#2 I was actually gearing up to put in a pull request but I'm Github challenged. I ride the small GitHub bus, does anyone have a walk through on how to do a pull request?

#3 This calms me a little, that even you do not understand how to use github...
For a pull request I think you have to fork the original repository, open your own branch, do the changes you think are needed into your branch, then you can do a pull request with that, this means, the project leader will pull this change into the main repository, if he thinks that it is a good thing.

#4 There is an article on GitHub that explains how to use pull requests.

So, fork the original repository, make a branch for each issue (to keep pull requests from containing EVERYTHING you've changed EVER! I made this mistake once....) and then just follow the directions.

Honestly, I still prefer Subversion over Git, but once you get accustomed to it Git is pretty easy to use. It's easier to learn it if you must, like for work, since most of us only "get around to it" when we really need something.

#5 THINGS TO DO:

• Sign the Open Source Software Agreement
• Use a unique branch to contain your changes. Pull requests are for the branch and not any specific commit.
• All pull request branches are to be based upon the development branch.
• Maintain code style consistent with the files you are modifying -- there is a code style guidelines page on our T3D wiki.

WHAT NOT TO DO:

• Don't use personal identifiers such as initials or names to mark the code you contribute. Doing so implies responsibility for maintenance by you.
• Don't use comment tags to denote additions or removals. Git (or any source control) tracks these changes for us.
• Don't comment a line of code and then paste a duplicate with your changes. This makes your change look temporary.
• If code is meant to be deleted, do so. Don't just comment the old code for it implies a temporary or testing status.
• If the modification has not been tested or is not ready for use then don't submit it for inclusion.

#6 Cannot stress enough the importance of cleanliness in a pull request. Extraneous commits to the branch, or a history of commits and reverts is to be avoided.

#7 @Michael,
I was wondering when you guys were going to have people sign something for contributions. Due to the SCO vs IBM suit they are doing that with the Linux Kernel for some time. Anyway, I am signed and ready to go! :)

Now I just need to do that pull request...

#8 @Demolishun:
The open source agreement has been in place almost from the start.

#9 @Michael,
It is getting very painfully obvious that I keep missing/misplacing the memos! :)

#10 Ok, after a lot of Git-Pain I was able to Git the code fixes in. I've got a couple more but I'm all Git-Outed...

Have GitNight!

Vince
Winterleaf Entertainment L.L.C.

#11 Unfortunately, thecelloman's hammer of git-denial is gonna have to smack down on every one of those pull requests for being improperly submitted.

#12 A basic guide to how to submit a pull request:

1. Update your development branch
2. Create a new "topic" branch that is based upon the development branch. This branch will contain the changes that your contribution will make.
3. Commit your changes to the "topic" branch.
4. Push the "topic" branch to your forked repository on Github.
5. From the webpage of your fork on Github select the newly pushed branch, then click the Pull Request button. Make sure on the following page that the base branch correctly points to development.
6. Click the "Send Pull Request" button.