Whether to delete the branch depends largely on how the branch was merged into master. If it was merged as a regular merge (with a merge commit), then there is no reason to delete the branch, as a new pull request on the same branch (after adding some new commits) will only show any new commits since that merge. On the other hand, if MacPorts decides it likes to squash and merge pull requests, then the branch should be deleted both on GitHub and locally, otherwise further development on that branch will show both the unsquashed commits and the further development in the pull request (although the differences shouldn't show up in the files/diff section of the pull request).
Being a co-maintainer of a software project hosted on GitHub, where the main developer does not use branches leads to inconsistencies in how his contributions are handled vs other developers. I highly recommend that Clemens move to putting logically separate changes in separate topical branches, and avoid developing on master, except very tiny changes, e.g. typos in docs. There should also be a decision on the recommended way to get updates from the latest master, whether that is by merging or rebasing. I personally like rebasing, but there is a stigma associated with it. Note the possibility of a safer forced push after a rebase with --force-with-lease. (I didn't look to see if there was already a recommendation.) -Sterling On Sep 23, 2016, at 11:38AM, Ryan Schmidt <ryandes...@macports.org> 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? > > 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... > > > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
