Re: Agenda: Verifiable Claims Teleconference - Tuesday, December 13th, 2016

My personal opinions:

On Tue, Dec 13, 2016 at 1:08 PM, Steven Rowat <steven_rowat@sunshine.net>
wrote:

> On 12/13/16 7:34 AM, Daniel Burnett wrote:
>
>> Attached is part I of my PR tutorial, planned for today.
>>
>>
> Thank you for doing this. I've read it through and it looks *doable*!  :-)
>
> Last week I did almost two full days reading about git and GitHub and gave
> up after encountering all the things you cover here and more, but never in
> an order that allowed me to understand how I would actually proceed. You
> appear to have done that very well.
>
> Three things I encountered that aren't mentioned (they might be coming in
> part 2, but I'll ask anyway:)
>
> 1. When my commit is for a specific open Issue, I've read it's possible to
> include the issue number so that if the pull request is accepted the Issue
> is closed automatically.
>
> https://help.github.com/articles/closing-issues-via-commit-messages/
>
> However, this may not work using the Fork and Pull model since my commit
> is entering via somebody else's pull. Not sure.
>
> Do you recommend adding 'closes #xx' to the commit message, in either
> event? Or some other reference to the Issue?
>

I would rather have commit messages say what they actually contain.  If you
put a "fixes #xxx" or "closes #xxx" as part of the PR description we can
always close the issues manually if needed since any cross reference to an
issue (or another PR) in the description or discussion of a PR
automatically shows up in the referenced issue as well.

>
> 2. Is it recommended to do a commit that covers several minor open Issues
> at once (e.g., ones like typos that aren't controversial), and, for
> example, put "closes #13" "closes #15" and "closes #22", all in the same
> commit message?  Or is it preferable to do a separate commit and pull
> request for each?
>

As with my comment above, I would prefer that the commit describe what you
did (even if just "fixed typos").  Items that are truly typos can be lumped
together.  Beyond trivial typo fixes, it is better to have separate PRs for
separate issues (or at least separate topics) if possible.  The key here is
not to lump together into one PR multiple changes where some might be
uncontroversial and others might require discussion, thus delaying the
introduction of the former.

>
> 3. Do I always do *one* Pull Request for *one* commit? Or can I do several
> commits in a row on my branch, and then do a Pull Request that covers all
> of them?
>

The rule is *one* Pull Request for *one*  ***branch***.
You can do as many commits on a (PR) branch as you want.  So edit and
commit away.  Note that even after the PR has been created you can still
make new commits on the same branch and they will automatically be
considered part of the same PR.

>
> Thanks
>
> Steven
>