On Wed, May 31, 2017 at 10:38:45AM -0400, Craig Treleaven wrote:
On May 31, 2017, at 8:52 AM, Zero King <l...@macports.org> wrote: I wrote a Gist about making changes to PRs, feedback via email is welcome. https://gist.github.com/l2dy/7da9621954ebcf1a19869f391662a41eI currently know very little about the GitHub pull request process. I’d like to understand better and this write-up helps a lot. Some observations, ... 0) The wiki currently includes the following: https://trac.macports.org/wiki/WorkingWithGit I presume we would adapt your Gist to become something like “WorkingWithGitHubPullRequests”? I think the current page would be unweildy if the gist was tacked on. 1) Gist lines 1-18 are similar to the existing Basic Setup and Cloning a Repository sections of the WorkingWithGit (WWG) wiki page. Could we avoid repeating by modifiying the existing page?
If adapted to wiki, yes.
2) I like your Disaster Recovery sections. I wonder if we could use wiki formatting to make them standalone boxes with emphasis. 3) Around line 24, I think there should be some preamble giving an overview of the typical workflow for a PR. Ie, after the PR is initially proposed, the initiator and review may go back and forth a number of times amending the PR to address issues, etc. When ready, the intermediate commits are squashed (I don’t know GitHub well, is this the right term?) so that the history in MacPorts doesn’t include extraneous commits. I don’t see how this is addressed in the gist.
We disabled "squash and merge" on GitHub's web interface so we have to do `git merge --squash` locally to complete the typical workflow, much harder than clicking a button twice. As such, my personal preference would be that PRs stay in a clean state (ready for "rebase and merge"), so the typical workflow would worth a separate Gist. Perhaps I should write about resolving conflicts with `git mergetool` in another Gist too.
4) Line 101-103 - I don’t understand why one would need to do this? After a PR has been commited, wouldn’t one just delete the local branch?
See `man git-gc`. Usually `git gc` would work but if you need to squeeze more disk space out of the repository you can use this *aggressive* command. Note that it shouldn't be used regularly.
Craig
-- Best regards, Zero King Don't trust the From address.
smime.p7s
Description: S/MIME cryptographic signature
