[MacPorts] WorkingWithGit modified

[Ryan Schmidt]

> On Sep 23, 2016, at 14:02, Clemens Lang <cal at macports.org> wrote:
> 
> Hi,
> 
> On Fri, Sep 23, 2016 at 01:38:43PM -0500, Ryan Schmidt wrote:
>>> On Sep 23, 2016, at 13:33, Clemens Lang <cal at macports.org> wrote:
>>> 
>>> I didn't include this because it's not how I normally work. I
>>> usually only create branches for larger changes. I wouldn't be
>>> opposed to include it, but I'm probably not the best person to write
>>> these docs.
>> 
>> If you commit directly to master of your fork, then submit a pull
>> request, you can't do anything else on master until your pull request
>> is accepted. If you make further changes on master they will be
>> included in the pull request, which you wouldn't want if they are
>> unrelated changes.
> 
> For most of the pull requests I've sent on GitHub so far I wanted a
> specific feature or bugfix to be integrated and did not want to make
> other changes, so the branch was just not necessary.
> 
> If you still want to make other changes, you can always work locally,
> too. You can see your local repository as yet another branch.
> 

But I can't submit a pull request for that. 

What has happened to me before is I fork, commit changes to master, pull request, upstream does not accept the pull request right away, then I realize I have another unrelated change I want to submit. Seems best to always create a branch before beginning any work, in case you find out later you have more work you want to submit. 


>> And once your pull request is merged, then what? GitHub will give you
>> a nice "you can now delete your master branch because it's been
>> merged" button...
> 
> I usually deleted the entire repository after the PR was merged.

Yes I want to do that too when I'm totally done. GitHub doesn't make this as easy though. 



> Maybe this approach will change for MacPorts, but most of our users
> probably don't update 12 different ports in 6 different PRs at the same
> time.

True but I'd like to default to assuming a user will make a valuable contribution and will want to make additional contributions in the future. And our track record of accepting patches in Trac in a timely fashion is not good. Hopefully it will improve once we go to pull requests instead of patches but I don't want our failure to timely accept a pull request to prevent a user from submitting a second unrelated pull request.