I have started writing a guide now.  I'll hold off giving you the address until the bottom of this message, because I'd like you to read my comments on the following first. ;)

In general, I would say that since we have chosen GitHub as the place to host our code, we are probably best off adapting the kind of workflow that GitHub encourages.


On Thu, 2011-02-03 at 10:54 -0600, Andrei Alexandrescu wrote:
> Lars, you seem to know your way around the process. Do you think you could put together a short document and a collection of scripts that people can use? The workflows involved are:
> 
> 1. I am done making a change and want to submit it for review.

In GitHub, this is done by clicking "Pull Request".  It would of course be nice to be able to do this from the command line, and I'm pretty sure it is possible to make a short script that uses GitHub's API to do this. I'm going offline for the weekend, but I'll look into it next week.


> 2. Reviewers gave feedback and I need to change my stuff and submit it back for review. Preferably there would be an obvious connection between the first and subsequent submissions.

>From what I understand, this happens automatically.  When you make
further commits to the branch from which you issued the pull request, the request is automatically updated with the changes.


> 3. Reviewers are okay with my changes, I need to upload them.
> 
> Ideally we'd have a means of enforcement, i.e. no code makes it that didn't get "OK" at least from one reviewer. Also, even if one reviewer gave "OK" another one could veto.
> 
> We use a similar process at Facebook and it is extremely helpful.

Russel suggested Gerrit, which seems to be exactly what you're looking for.  However, Gerrit is a Git server in its own right, and encourages a quite different workflow than GitHub.  In general, it seems Gerrit and GitHub don't play nice together:

  http://stackoverflow.com/questions/2451644/gerrit-with-github

(Scott Chacon is one of the GitHub devs, by the way, so he should know.)

Instead, I suggest we do one of the following two things:

1. Trust people not to commit anything unless it has been reviewed and OK'ed by at least two other team members.

2. Revoke everyone except Andrei's (and possibly one or two others') push privileges, and leave the job of integrating our changes to those select few.

The latter is the "traditional" git way to do it, but it means more work for those chosen to be the integrators.  My vote goes to 1.


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


-Lars

Great! (1) sounds great. I won't have the time to read it soon, but I will and I encourage others to do so as well.

Andrei

On 2/4/11 8:36 AM, Lars Tandle Kyllingstad wrote:
> I have started writing a guide now.  I'll hold off giving you the address until the bottom of this message, because I'd like you to read my comments on the following first. ;)
>
> In general, I would say that since we have chosen GitHub as the place to host our code, we are probably best off adapting the kind of workflow that GitHub encourages.
>
>
> On Thu, 2011-02-03 at 10:54 -0600, Andrei Alexandrescu wrote:
>> Lars, you seem to know your way around the process. Do you think you could put together a short document and a collection of scripts that people can use? The workflows involved are:
>>
>> 1. I am done making a change and want to submit it for review.
>
> In GitHub, this is done by clicking "Pull Request".  It would of course be nice to be able to do this from the command line, and I'm pretty sure it is possible to make a short script that uses GitHub's API to do this. I'm going offline for the weekend, but I'll look into it next week.
>
>
>> 2. Reviewers gave feedback and I need to change my stuff and submit it back for review. Preferably there would be an obvious connection between the first and subsequent submissions.
>
>> From what I understand, this happens automatically.  When you make
> further commits to the branch from which you issued the pull request, the request is automatically updated with the changes.
>
>
>> 3. Reviewers are okay with my changes, I need to upload them.
>>
>> Ideally we'd have a means of enforcement, i.e. no code makes it that didn't get "OK" at least from one reviewer. Also, even if one reviewer gave "OK" another one could veto.
>>
>> We use a similar process at Facebook and it is extremely helpful.
>
> Russel suggested Gerrit, which seems to be exactly what you're looking for.  However, Gerrit is a Git server in its own right, and encourages a quite different workflow than GitHub.  In general, it seems Gerrit and GitHub don't play nice together:
>
>    http://stackoverflow.com/questions/2451644/gerrit-with-github
>
> (Scott Chacon is one of the GitHub devs, by the way, so he should know.)
>
> Instead, I suggest we do one of the following two things:
>
> 1. Trust people not to commit anything unless it has been reviewed and OK'ed by at least two other team members.
>
> 2. Revoke everyone except Andrei's (and possibly one or two others') push privileges, and leave the job of integrating our changes to those select few.
>
> The latter is the "traditional" git way to do it, but it means more work for those chosen to be the integrators.  My vote goes to 1.
>
>
> 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
>
>
> -Lars
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Fri, 2011-02-04 at 15:36 +0100, Lars Tandle Kyllingstad wrote: [ . . . ]
> Russel suggested Gerrit, which seems to be exactly what you're looking for.  However, Gerrit is a Git server in its own right, and encourages a quite different workflow than GitHub.  In general, it seems Gerrit and GitHub don't play nice together:
> 
>   http://stackoverflow.com/questions/2451644/gerrit-with-github
> 
> (Scott Chacon is one of the GitHub devs, by the way, so he should know.)

Bizarrely :-)  I hadn't twigged to this, thanks for the "head up" on this issue.

> Instead, I suggest we do one of the following two things:
> 
> 1. Trust people not to commit anything unless it has been reviewed and OK'ed by at least two other team members.
> 
> 2. Revoke everyone except Andrei's (and possibly one or two others') push privileges, and leave the job of integrating our changes to those select few.

In the GPars team we use 1, for Gant I use 2.  Both work, but I suspect that is because there is very little traffic on Gant.  Thus 1 is probably to be preferred.

There is a significant difference between having an inner core of privileged committers when using CVCS and DVCS.  With CVCS it is incredibly difficult to use version control at all for the project unless you are in the privileged group.  With DVCS anyone can use full version control to work on a project, the privileged committers are just the final gatekeepers as to what goes into the central repository that defines the official current state of the project.  Whilst a seemingly trivial difference, it is actually major and crucial -- at least in any form of FOSS project.

> The latter is the "traditional" git way to do it, but it means more work for those chosen to be the integrators.  My vote goes to 1.

Well for any big project there would be a hierarchical structure of filtering so as to have a balanced workload for each person at each level.

> 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

I wonder if the idea of keeping master as a mirror of the master of the central mainline and having all work done by people not in the final commit group on named branches would help with pull requests?

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20110204/79bf5873/attachment.pgp>

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.

Le 2011-02-08 ? 18:40, Sean Kelly a ?crit :

> 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.

	git push <remote-name> <branch-name>

<remote-name> is the name of the remote to push to. Generally it's "origin" that points to where you cloned the repository from. So:

	git push origin <branch-name>

If you want to see the list of remotes in your git repository, use:

	git remote

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

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.

-Lars

On 9 February 2011 09:33, Lars Tandle Kyllingstad <lars at kyllingen.net> 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.
>
> -Lars

I think github does you a major disservice by allowing you to do a pull request on your master branch, without giving you a warning.

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.

Sent from my iPhone

On Feb 9, 2011, at 1:55 AM, Don Clugston <dclugston at googlemail.com> wrote:

> On 9 February 2011 09:33, Lars Tandle Kyllingstad <lars at kyllingen.net> 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.
>> 
>> -Lars
> 
> I think github does you a major disservice by allowing you to do a
> pull request on your master branch, without giving you a warning.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

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.
>
> Sent from my iPhone

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

The default is to have the request pulled into the master branch of your forked repository though, which usually is the desired location (the one fulfilling the pull can first merge it to a separate branch before finally merging it with master). But if the request is for Phobos 1 then you would should change the destination branch:

http://help.github.com/pull-requests/#changing_the_commit_range_and_destination_repository

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.