Re: [Mutopia-discuss] reviewing pull requests in github

[Federico Bruni]

Il giorno ven 5 dic 2014 alle 18:36, Federico Bruni 
 ha scritto:
Perhaps it's better using 'git format-patch' in case the contributor 
approves it and what to apply to his branch? I don't know if the 
patch generated with the command above can be applied with 'git am'.


sorry, typo:
... and want to apply to...
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Federico Bruni]

Il giorno gio 4 dic 2014 alle 22:48, Glen Larsen  
ha scritto:
Adding a link to the guide is a good idea but it doesn't exactly 
match our wiki's entry regarding setting up for contribution. Here is 
some wiki text that I will add to a new page on reviewing (if one 
hasn't been created by now.)


Go ahead and create a page on the wiki, I won't have any time in the 
coming days.


GITHUB's pull/ID/head references a storage location for a pending 
pull request. If you have created your repository using the wiki 
page, getting a local copy for review would go something like this:


# A. create & use a new branch (to make cleanup easier later)
git checkout -b oakbucket-review
# B. 484 is the number of the pull request
git fetch upstream pull/484/head

(Note the use of "upstream" as the remote reference.) You could stop 
here and do a diff,


git diff ...FETCH_HEAD

But if you want to compile the file and review the score as a PDF, 
you would have to merge first,


# check that you are in your review branch before doing this!
git merge -m'review merge' FETCH_HEAD


I prefer rebase to avoid the merge commit.

You still won't be able to update somebody else's pull request but if 
during review you find an issue you would like to include in the pull 
request you have these choices:


1. Create a patch that you could send to the contributor
2. Annotate on GITHUB the line(s) you propose to change in the pull 
request


A patch can easily be created from git,

git diff -p >date-edit.patch



Perhaps it's better using 'git format-patch' in case the contributor 
approves it and what to apply to his branch? I don't know if the patch 
generated with the command above can be applied with 'git am'.



___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Glen Larsen]

Adding a link to the guide is a good idea but it doesn't exactly match our
wiki's entry regarding setting up for contribution
.
Here is some wiki text that I will add to a new page on reviewing (if one
hasn't been created by now.)

GITHUB's pull/ID/head references a storage location for a pending pull
request. If you have created your repository using the wiki page, getting a
local copy for review would go something like this:

# A. create & use a new branch (to make cleanup easier later)
git checkout -b oakbucket-review
# B. 484 is the number of the pull request
git fetch upstream pull/484/head

(Note the use of "upstream" as the remote reference.) You could stop here
and do a diff,

git diff ...FETCH_HEAD

But if you want to compile the file and review the score as a PDF, you
would have to merge first,

# check that you are in your review branch before doing this!
git merge -m'review merge' FETCH_HEAD

You still won't be able to update somebody else's pull request but if
during review you find an issue you would like to include in the pull
request you have these choices:

1. Create a patch that you could send to the contributor
2. Annotate on GITHUB the line(s) you propose to change in the pull request

A patch can easily be created from git,

git diff -p >date-edit.patch

-glen
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Glen Larsen]

Ah, so right. My apologies for not doing deeper research. I'll take a more
complete look later today.

On Thu, Dec 4, 2014 at 3:12 AM, Federico Bruni  wrote:

> Il giorno gio 4 dic 2014 alle 8:00, Glen Larsen  ha
> scritto:
>
> These instructions are modifying an inactive pull request. Looking at the
> first section about modifying an *active* pull request locally it
> mentions following commands given at the bottom of a pull request.
>
>
> Right, but only collaborators can merge a pull request through github.
> On the bottom of any pull request I can see only:
>
>
> This pull request can be automatically merged by project collaborators.
>
> Only those with write access to this repository can merge pull requests.
>
>
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Federico Bruni]

Il giorno gio 4 dic 2014 alle 8:00, Glen Larsen  
ha scritto:
These instructions are modifying an inactive pull request. Looking at 
the first section about modifying an active pull request locally it 
mentions following commands given at the bottom of a pull request.


Right, but only collaborators can merge a pull request through github.
On the bottom of any pull request I can see only:


This pull request can be automatically merged by project collaborators.

Only those with write access to this repository can merge pull requests.


___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Glen Larsen]

On Tue, Dec 2, 2014 at 2:43 PM, Federico Bruni  wrote:

> Hi all
>
> I'm reading this guide:
> https://help.github.com/articles/checking-out-pull-requests-locally/
>
> I see that I can easily checkout the branch submitted through a pull
> request with this command:
>
> git fetch origin pull/ID/head:BRANCHNAME
> git checkout BRANCHNAME
>
>
These instructions are modifying an inactive pull request. Looking at the
first section about modifying an *active* pull request locally it mentions
following commands given at the bottom of a pull request. Those commands
are for merging but the same principle applies. Step 1 of that help is
about getting the pull request into a local branch and step 2 is all about
merging with the master. All you care about is step 1:

git checkout -b fedelibre-oaken-bucket master
git pull g...@github.com:fedelibre/The-Mutopia-Project.git oaken-bucket

That is,
a. create a branch (under master) called fedelibre-oaken-bucket and switch
to it
b. pull (fetch and merge) the changes in the request into that branch

Now you can build the pdf and review. When done you can delete the branch:

git checkout master
git br -D fedelibre-oaken-bucket

Submitting any edits you make in this local branch could still be processed
in a reasonable manner by submitting another pull request. I've made a
small test edit which I merged to my origin:

# edit & commit a new date into the "lastupdated" field as a test
git push origin fedelibre-oaken-bucket

The pull request is here:

https://github.com/chrissawer/The-Mutopia-Project/pull/487

GIT keeps track rather nicely.

-glen


> Now, if the author of the pull request add one or more commits, what's the
> best way to update it to the last commit?
> If I repeat the fetch above I get this error:
>
> fatal: Refusing to fetch into current branch refs/heads/search of non-bare
> repository
>
> The simple (stupid) solution I found is deleting the branch so I can
> repeat the two commands above without any problem. But I'm sure that
> there's something better.
> Mmmmh, I think I found it. If I checkout master again and run the fetch
> again it works.
> I guess that I'm missing what the fetch does.
>
> Anyway, do you think it's worth adding a small page  in the wiki about
> reviewing patches?
>
> Cheers
> Federico
>
> PS For Glen and Javier: what about another round of updates? Or some focus
> to close the Phase 3 milestone?
> I got a bit stuck on writing a piece from scratch. But during Christmas I
> might have some time to get some things done.
>
> ___
> Mutopia-discuss mailing list
> Mutopia-discuss@mutopiaproject.org
> http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
>
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Federico Bruni]

Il giorno mer 3 dic 2014 alle 10:23, Federico Bruni 
 ha scritto:
I don't think it's possible to submit changes to someone else's open 
pull request. You can upload the .patch file of your changes in the 
comments of the pull request, if you want the author of the PR to see 
your ideas. Or you can copy his branch in your repository and send a 
new PR, if you want to take up his work.


And of course the full commit history, including commits of the first 
author, is present. You can see an example of a patch taken over by a 
new developer here:

https://github.com/tomchristie/mkdocs/pull/222/commits

He created a new pull request..
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Federico Bruni]

Il giorno mer 3 dic 2014 alle 4:24, Javier Ruiz-Alma 
 ha scritto:
Having a link to this guide would've made things easier for the few 
times I've copy/pasted code to compile some else's pull-requests.  
This doesn't happen often, though, so maybe you can create a new wiki 
page for advanced topics.


Ok, I'll add it in the afternoon.

Is it possible to also submit changes to someone else's open 
pull-request via github?  If so, add a link to this too.  Speaking 
for myself: I'd be lost on how to process a change request to one of 
my open PR's thru github.


Changing and updating your own pull request is very easy. You just have 
to work on the same branch used for that specific pull request (that's 
why using a different branch from master is highly recommended in 
github, unless you know that you are going to merge it immediately). 
You add a commit to that branch and push it to your remote/branch; the 
pull request will be updated automatically.


I don't think it's possible to submit changes to someone else's open 
pull request. You can upload the .patch file of your changes in the 
comments of the pull request, if you want the author of the PR to see 
your ideas. Or you can copy his branch in your repository and send a 
new PR, if you want to take up his work.



___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

Re: [Mutopia-discuss] reviewing pull requests in github

[Javier Ruiz-Alma]

Hi Federico,
Having a link to this guide would've made things easier for the few times I've 
copy/pasted code to compile some else's pull-requests.  This doesn't happen 
often, though, so maybe you can create a new wiki page for advanced topics.Is 
it possible to also submit changes to someone else's open pull-request via 
github?  If so, add a link to this too.  Speaking for myself: I'd be lost on 
how to process a change request to one of my open PR's thru github.
I'm open to the next round of updates from Glenupdating Mutopia code sounds 
like a great plan for the Christmas time off...season of giving :)

Javier



 On Tuesday, December 2, 2014 2:44 PM, Federico Bruni  
wrote:
   
 

 Hi all
I'm reading this 
guide:https://help.github.com/articles/checking-out-pull-requests-locally/
I see that I can easily checkout the branch submitted through a pull request 
with this command:
git fetch origin pull/ID/head:BRANCHNAMEgit checkout BRANCHNAME
Now, if the author of the pull request add one or more commits, what's the best 
way to update it to the last commit?If I repeat the fetch above I get this 
error:
fatal: Refusing to fetch into current branch refs/heads/search of non-bare 
repository
The simple (stupid) solution I found is deleting the branch so I can repeat the 
two commands above without any problem. But I'm sure that there's something 
better.Mmmmh, I think I found it. If I checkout master again and run the fetch 
again it works.I guess that I'm missing what the fetch does.
Anyway, do you think it's worth adding a small page  in the wiki about 
reviewing patches?
CheersFederico
PS For Glen and Javier: what about another round of updates? Or some focus to 
close the Phase 3 milestone?I got a bit stuck on writing a piece from scratch. 
But during Christmas I might have some time to get some things done.
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss

 
   ___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss