Working with Git

[Chris Jones]

Hi,

On 06/10/16 09:44, Ryan Schmidt wrote:
>
>
>> On Oct 6, 2016, at 03:32, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>>
>>
>>
>>> On 06/10/16 09:22, Ryan Schmidt wrote:
>>>> On Oct 6, 2016, at 02:33, Sterling Smith <smithsp at fusion.gat.com> wrote:
>>>>
>>>> Ryan,
>>>>
>>>>> On Oct 5, 2016, at 7:53PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>>>>
>>>>> Suppose a user submits an update to a port.
>>>>>
>>>>> With Subversion, the user would submit a patch in a Trac ticket. To test it, I would download the patch and apply it to my local Subversion working copy. If I like it, I commit it. If I don't like it, I give feedback to the user in the ticket, or I edit the Portfile further and commit it, then tell the user in the ticket what changes I made.
>>>>>
>>>>> How will this work on GitHub?
>>>>>
>>>>> The user will submit a pull request. How do I test it locally?
>>>> You test their changes by checking out their branch on your system.  Most likely they are on their own fork, and you will need to add their fork as a new remote
>>>>
>>>> git remote add <name describing the fork> <path to fork>
>>>>
>>>> before checking out their branch by issuing
>>>>
>>>> git checkout <branch>  # Note that this can fail if more than one remote has the same branch name (such as master...), and there is a more verbose way to indicate from where to check out the branch
>>>
>>> Can you or someone please add this to the WorkingWithGit wiki page?
>>>
>>> Sounds like the list of remotes is going to get unwieldy. How should one keep it sane?
>>
>> Just through good management. Each MR needs its own branch. That branch can either be on a remote repo, or (if the project allows) a branch on the main repo. Once a MR is merged, the source branch can be deleted.
>
> When you say "MR", you mean merge request, aka pull request in GitHub terminology?

Sorry, yes. I am more familiar with gitlab than git hum, and thats the 
term there.

>
> I understand that a pull request should begin its life in a branch created specifically for this purpose, in a fork of the repo.

Yes, it should be in a branch, but that branch does not *have* to be in 
a fork. You could allow that branch to be part of the main repo. It can 
be in a fork, and forks are useful for developers for their own uses, 
but when they are ready to push something back to the main repo, they 
could make a branch in that repo. In my view things get a bit easier for 
those reviewing and accepting the pull request in this way, as they 
don't have to know about the existance of the users fork.

  That's up to the person submitting the PR to get right.
>
> I'm talking about how I, as a MacPorts committer, will review, accept and otherwise deal with PRs sent by non-committers.
>
>
>>>>> What if the pull request is incomplete? I know I can tell the user what's wrong, and they can push another commit to the same branch they made to initiate the pull request, and those new commits will automatically appear in the pull request, and I can then merge it if I like it.
>>>> Yep.
>>>>> But what if the user does not respond and fix the changes? What if the user makes additional commits but they're still not sufficient? How do I take the user's pull request, make additional changes, and commit them to our master?
>>>> Instead of committing to master, you should commit to the user's fork/branch to add your changes to the pull request,
>>>
>>> I did not know that was possible. Who is able to commit to a fork? I presume only the person who made the fork, and committers of the original repo. If that's true, then how would a second non-committer contribute to and improve the first non-committer's fork / pull request?
>>
>> It depends how the owner of the fork has set up their repo.
>
> I did not know there was any way to "set up" a fork. What is there to do, other than click the "fork" button on the GitHub web site?

Again, I am more familiar with gitlab than github, but there once I have 
forked a repo, there are settings I can access for that fork, to 
configure things like access. I would be surprised if github did not 
have something similar.

Chris
>
>> It gets simpler (in my view) if you take merge requests from a temporary branch on the main repo, as then anyone who is able to create MRs can commit to other ones.
>
> Committers can certainly create branches in the official MacPorts repositories. With Subversion, committers generally just commit to trunk. We haven't yet defined any policies for whether to continue that on GitHub or to encourage the use of branches more.
>
> But we also accept contributions from non-committers. I want to make sure I understand how that will work.
>
>