Working with Git

[Sterling Smith]

On Oct 6, 2016, at 1:22AM, Ryan Schmidt <ryandesign at macports.org> 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:
>>> 
>>> 
>>> 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?

I see that using other branches through `git checkout` is not yet present in the wiki.  I will try to add something along the lines of what I wrote here about trying out other people's changes.

> 
> Sounds like the list of remotes is going to get unwieldy. How should one keep it sane?
You can delete remotes as easily as adding them.  

More recently, GitHub has provided finer grained control over pushing to specific branches in a given repo, and the MacPorts committers could choose to restrict pushes to their own major development branches while still allowing all users to create new branches on the main MacPorts repo.  This might significantly lessen the number of remotes.  However, I doubt that is the path that is desirable, because it allows too many people opportunity to screw up someone else's work (accidentally or on purpose).
> 
> 
> 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.
Permissions on each fork can be set by the owner of the fork.  The starting permissions are those you indicate.
> If that's true, then how would a second non-committer contribute to and improve the first non-committer's fork / pull request?
> 
The second non-committer would commit to their own branch and push to their own fork, then file a pull request from their fork to the 1st non-committer fork.  An example was
https://github.com/QuadmasterXLII/matplotlib/pull/1
It no longer appears as a clean pull request of a few commits because I ended up rebasing my branch to be able to merge it into the main repo, as there was a takeover of the pull request as
https://github.com/matplotlib/matplotlib/pull/6988

> 
>> 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. 
Presumably whoever hits the merge button (or merges at the command line) reviewed the code.  GitHub has also recently formalized pull request reviews.
> 
> 
>>> -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. 
OK.  I went looking for it, but couldn't find it.  Hopefully lack of documentation is not the show-stopper for converting to git, as the best way for developers to realize what is missing is by using git and GitHub.

-Sterling