On Feb 9, 2011, at 12:33 AM, Lars Tandle Kyllingstad wrote:

> On Tue, 2011-02-08 at 15:40 -0800, Sean Kelly wrote:
>> I still barely understand how Git works, but I'm starting to warm up to the workflow.  Using SVN, coordinating library and compiler changes (ie. spanning multiple repositories) generally resulted in a window where the library code was out of date or broken.  With Git I'm finding that I can create a series of pull requests that reference one another, which is a heck of a lot nicer than including multiple patch files to a bugzilla ticket.
>> 
>> I'm still fuzzy on what to do if I want to create multiple pull requests that don't derive from one another though.  A fork for each one?  I'd hoped that I could create a branch for each, but haven't yet figured out how to push the branch upstream so I can generate the pull request from it.
> 
> I've written a bit about that in the still-embryonic contributor's guide:
> 
>    http://www.kyllingen.net/guide.html#publish
> 
> It's probably a good idea to always create a new branch for each pull request, though, so I'll put a note about that in there, too.

Thanks!  I think I'm starting to get the hang of git now.  For each issue, I'm creating a local branch named "issue-XXXX" and a remote branch named "issue-XXXX".  Then I just do "git push issue-XXXX issue-XXXX" and everything works as intended.  Very different workflow than SVN, but a lot more powerful.

On Wednesday, February 09, 2011 10:18:12 Sean Kelly wrote:
> On Feb 9, 2011, at 8:41 AM, Jesse Phillips wrote:
> > On Wed, Feb 9, 2011 at 7:26 AM, Sean Kelly <sean at invisibleduck.org> wrote:
> >> Even the instructions on github for generating a pull request use the master branch. After a few failed attempts usig a separate branch I gave up and did what thy said.
> > 
> > You must be talking about something else, step 1 is to switch to the branch you want:
> > 
> > http://help.github.com/pull-requests/#initiating_the_pull_request
> 
> Ah, I was working mostly from the "forking a project" page.  It says "once you've pushed your commit(s), inform the project owner of the changes so they can pull them into their repo. The best way to do this is by sending a pull request."  I'll see about reverting my changes in master and moving them to a branch.
> 
> > The default is to have the request pulled into the master branch of your forked repository though, which usually is the desired location
> 
> Is it really the desired location?  If I want to submit multiple pull requests to a single project, I'd think that each one should be done from a separate branch.  Using master as the default seems like it would work against this.

Making changes in your own repository on separate branches for each issue makes sense, but when the pull request for them is done and the changes are pushed into the main repository, I'd expect that to be to the master branch. So, the pull request would come _from_ a separate branch of your repository and go _to_ the master branch of the main repository.

- Jonathan M Davis

Just to try and state the same thing differently:

d-programming-language/phobos
|
v
Fork: Sean/phobos

These are your remote repositories, yes two of them.

git clone Sean/phobos
|
v
phobos: repository on local machine

Note that your local repository will then have a remote named origin

origin -> Sean/phobos

You will create branches and push those to origin as branches:

git push origin issue-XXX:issue-XXX

Your pull request will then come from Sean/phobos:issue-XXX to d-programming-language/phobos:master

I realize this is hard to covey since there are 3 master branches involved, two which are in a remote repository.

Example pull: https://github.com/D-Programming-Language/phobos/pull/4

Its branch: https://github.com/jmdavis/phobos/tree/5552

Pretty diagram: https://github.com/D-Programming-Language/phobos/network

Hopefully this clears up how these all fit together.

On Wed, Feb 9, 2011 at 11:16 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Wednesday, February 09, 2011 10:18:12 Sean Kelly wrote:
>> On Feb 9, 2011, at 8:41 AM, Jesse Phillips wrote:
>> > The default is to have the request pulled into the master branch of your forked repository though, which usually is the desired location
>>
>> Is it really the desired location? ?If I want to submit multiple pull requests to a single project, I'd think that each one should be done from a separate branch. ?Using master as the default seems like it would work against this.
>
> Making changes in your own repository on separate branches for each issue makes sense, but when the pull request for them is done and the changes are pushed into the main repository, I'd expect that to be to the master branch. So, the pull request would come _from_ a separate branch of your repository and go _to_ the master branch of the main repository.

On Feb 9, 2011, at 12:03 PM, Jesse Phillips wrote:

> Just to try and state the same thing differently:
> 
> d-programming-language/phobos
> |
> v
> Fork: Sean/phobos
> 
> These are your remote repositories, yes two of them.
> 
> git clone Sean/phobos
> |
> v
> phobos: repository on local machine
> 
> Note that your local repository will then have a remote named origin
> 
> origin -> Sean/phobos
> 
> You will create branches and push those to origin as branches:
> 
> git push origin issue-XXX:issue-XXX

So I don't have to create the remote branch as a separate step?  I had been doing:

git remote add issue-XXXX
...
git push issue-XXXX issue-XXXX

On Wed, Feb 9, 2011 at 2:03 PM, Sean Kelly <sean at invisibleduck.org> wrote:
> On Feb 9, 2011, at 12:03 PM, Jesse Phillips wrote:
>
>> You will create branches and push those to origin as branches:
>>
>> git push origin issue-XXX:issue-XXX
>
> So I don't have to create the remote branch as a separate step? ?I had been doing:
>
> git remote add issue-XXXX
> ...
> git push issue-XXXX issue-XXXX

Ah, no need to do that. And looking over the docs, I don't think it is doing what you want it to do. If I understand it right this command makes issue-XXXX a synonym for origin or something, but not a branch:

git-remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url> "Adds a remote named <name> for the repository at <url>. The command git fetch <name> can then be used to create and update remote-tracking branches <name>/<branch>."

My branching command is

git checkout -b branch_name

aka

git branch branch_name
git checkout branch_name

On Friday 04 February 2011 06:36:55 Lars Tandle Kyllingstad wrote:
> Ok, now you can read my draft and comment on it.  Like I said, I'm going away for the weekend, so I probably won't be able to respond to any comments until Monday.
> 
>   http://www.kyllingen.net/guide.html

We should probably add some advice on rebasing if we figure out key places where it should be done (particularly to avoid ugly, extra commit messages).

Also, from the looks of it, the default commit message that you get from following the instructions on pull requests isn't terribly pretty. The one I ended up with the other day was:

Merge branch 'master' of https://github.com/kyllingstad/phobos into kyllingstad- master

It appears that pull requests have numbers, I'm thinking that we should rename such commits (using git-commit --amend presumably) as being a pull request and give the pull request's number. That way, it's clearly identified as to which pull request it originated from, and the commit message isn't so ugly.

- Jonathan M Davis