commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [ALL][Math] git pull requests: how?
Date Wed, 08 Mar 2017 11:10:57 GMT
Hi.

On Tue, 7 Mar 2017 22:06:11 -0600, Matt Sicker wrote:
> Found this link while trying to remember how to do this:
>
> https://help.github.com/articles/checking-out-pull-requests-locally/
>
> Same docs as above, just from the source. It sounds like you can't 
> write to
> a PR branch even if the author allows it, but the docs could be out 
> of date
> (it happens!).

1. I don't want to "write to a PR branch"; my question was about 
getting
    the PR automatically merged in a single command (as opposed to 
locally
    create the branch).
2. The result of the actions listed below was to create a local branch 
with
    the contents of the PR. Of course (?), I could modify that local 
branch.

Gilles

>
> On 2 March 2017 at 09:52, Gilles <gilles@harfang.homelinux.org> 
> wrote:
>
>> On Thu, 2 Mar 2017 09:35:53 -0600, Matt Sicker wrote:
>>
>>> Is the different behavior caused by svn versus git mirroring?
>>>
>>
>> The "Math" and "Numbers" projects both use git.
>>
>> Gilles
>>
>> That read-only branch feature is really cool.
>>> Some of this info might be
>>> useful to include in the template readme files and such for 
>>> commons.
>>>
>>
>>
>>> On 2 March 2017 at 06:09, Gilles <gilles@harfang.homelinux.org> 
>>> wrote:
>>>
>>> On Thu, 2 Mar 2017 11:30:17 +0000, sebb wrote:
>>>>
>>>> This info (when validated) should be added to the Wiki:
>>>>>
>>>>> https://wiki.apache.org/commons/UsingGIT
>>>>>
>>>>> ...
>>>>>
>>>>> Oh, it already is there at the end
>>>>>
>>>>>
>>>> Indeed, there is information there.
>>>> That works:
>>>>   $ git fetch github pull/72/head:fix-foo-in-bar
>>>>
>>>> But is it simpler to
>>>>  1. remember the syntax
>>>>  2. go to the GitHub site (following the link "manually" posted by
>>>>     the contributor on the JIRA page)
>>>>  3. figure out what part of the GitHub page contains the string
>>>>     for replacing "fix-foo-in-bar"
>>>>  4. copy/paste it in a console
>>>>  5. run the above command
>>>>  6. merge the branch created by the above command
>>>> than have the full command posted automatically on the JIRA page,
>>>> so that the committer can do everything in one go?
>>>>
>>>> Note that the command above is not the same as the syntax provided
>>>> in the automatic posts ("fetch" vs "pull").
>>>>
>>>> Question is still: Why different behaviours of the GitHub mirrors?
>>>> Do we want this fixed?
>>>> How?
>>>>
>>>>
>>>> Thanks,
>>>> Gilles
>>>>
>>>>
>>>>
>>>> On 2 March 2017 at 10:50, Gilles <gilles@harfang.homelinux.org> 
>>>> wrote:
>>>>
>>>>>
>>>>> On Wed, 1 Mar 2017 22:51:54 -0600, Matt Sicker wrote:
>>>>>>
>>>>>>
>>>>>>> Normally the GitHub email gives you the proper command to use

>>>>>>> to pull
>>>>>>> the
>>>>>>> PR into your local git which you can merge and push (which 
>>>>>>> merges the
>>>>>>> PR
>>>>>>> once GitHub gets updated from apache.org).
>>>>>>>
>>>>>>> As for making sure that email gets sent, if it's not, file an

>>>>>>> INFRA
>>>>>>> ticket
>>>>>>> about it. I've never tried it, but this might work:
>>>>>>>
>>>>>>> git pull https://github.com/apache/commons-math/pull/55
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> $ git pull https://github.com/apache/commons-math/pull/55
>>>>>> remote: Not Found
>>>>>> fatal: repository 
>>>>>> 'https://github.com/apache/commons-math/pull/55/'
>>>>>> not
>>>>>> found
>>>>>>
>>>>>> If you add .diff or .patch to the end of the URL, it gives you a

>>>>>> diff
>>>>>>
>>>>>>> that
>>>>>>> you can manually apply. The .diff URL appears to be a normal

>>>>>>> diff
>>>>>>> while
>>>>>>> the
>>>>>>> .patch URL is the output of "git format-patch". So, if you 
>>>>>>> download <
>>>>>>> https://github.com/apache/commons-math/pull/55.patch> and
run 
>>>>>>> "git
>>>>>>> apply
>>>>>>> 55.patch", that'll commit it properly as if you merged the PR

>>>>>>> itself I
>>>>>>> think (it'll set the commit author properly at least for proper
>>>>>>> historical
>>>>>>> attribution).
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks, that could be a (sub-optimal) solution.
>>>>>>
>>>>>> Also, adding a commit message somewhere (e.g., a follow up empty

>>>>>> commit
>>>>>>
>>>>>>> or
>>>>>>> a changelog entry commit) containing the phrase "this closes

>>>>>>> #55" (or
>>>>>>> maybe
>>>>>>> just "closes #55"; it's pretty loose) is enough to close the

>>>>>>> PR, but
>>>>>>> merging it should close it automatically.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Yes, I knew that, because the notification, when it gets sent, 
>>>>>> contains
>>>>>> all the information necessary to handle to request (and 
>>>>>> additionally,
>>>>>> the
>>>>>> JIRA issue will be updated automatically too).
>>>>>>
>>>>>> Hence that would be the preferred solution.
>>>>>>
>>>>>> I still wonder why the various Commons projects (those managed 
>>>>>> by git
>>>>>> and
>>>>>> having a GitHub mirror) behave differently.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>> On 1 March 2017 at 17:53, Gilles <gilles@harfang.homelinux.org>

>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>>>
>>>>>>>> How should the project be configured such that the request
>>>>>>>> posted here:
>>>>>>>>   https://issues.apache.org/jira/browse/MATH-1405
>>>>>>>> is as easy to handle as the one posted here:
>>>>>>>>   https://issues.apache.org/jira/browse/NUMBERS-4
>>>>>>>> ?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Gilles
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message