Working with Git

[Ryan Schmidt]

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?


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


> and then you might ask another committer to look over your work and make the final merge to master, or if you are above review, you could just merge your work yourself.

For major changes yes some review process might be nice. We'll need to work that out after we move. We don't have a formal review process for that kind of thing today. 

>> Clemens, in your repository here, you committed something I had previously committed in a fork, but had not submitted a pull request for:
>> 
>> https://github.com/neverpanic/macports-svn2git-rules/commit/bfeed37956f72bf996865e414a375128186d1adf
>> 
>> The GitHub interface says "ryandesign committed with neverpanic". How did you cause that notation to appear, and is that something we should be using in our MacPorts git workflow?
> git keeps track of both author and committer (also sign-off?).  When you commit some change for the first time, then you are added as author and committer.  If a person cherry-picks or uses rebase to incorporate some commit into a branch, then the committer is changed to the person that applied the cherry pick or rebase.  If the author and committer are different, then GitHub detects that and presents the two parts as you have seen as "ryandesign committed with never panic".

Ok, so we don't need to do anything special; this happens automatically. 


>> -Ryan
> 
> When is the macports repo on GitHub supposed to appear?

I have no ETA for you yet. "When it's ready." Part of being ready includes having documentation about how we'll perform the tasks we need to perform on GitHub, so people who know how to do that should definitely contribute to the documentation, and people should ask questions about things that aren't explained in the documentation.