> On Sep 23, 2016, at 14:02, Clemens Lang <c...@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 <c...@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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
