On 2016-09-23 20:38, 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. > > How can you not work that way?
I usually do the work on my local master. Only when I want to submit a pull request, I create a new branch starting from upstream/master to which I cherry-pick or rebase the changes I want to send in the pull request. I do it this way because I also want to keep all the fixes in the local copy I use. Of course that means I need to keep rebasing my local master from upstream/master. > 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. 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... You could also push from your master to a new remote branch that did not exist locally: $ git push origin master:foo-fix Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
