On 06/10/16 09:22, Ryan Schmidt wrote:
On Oct 6, 2016, at 02:33, Sterling Smith <smit...@fusion.gat.com> wrote:
Ryan,
On Oct 5, 2016, at 7:53PM, Ryan Schmidt <ryandes...@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.
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. 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.
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.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
