I fully agree with Mojca, that it is better to work on a private fork for the start and let others - like Clemens suggested - take part in reviewing on that forked repository. This way one can train what would have to be done on the main macports-ports repo before causing trouble there...
On 24 Oct 2016, at 19:58 , Clemens Lang <c...@macports.org> wrote: > Yes, that's also my preference. So we can agree on: > - rebase when merging PRs > - rewrite history on PR branches until it looks good A description of how exactly one would rebase (potentially squash and history-rewrite) a submitted PR onto current master should be on our WorkingWithGit wiki page. At the moment it is not very clear to me how a MacPorts committer would actually deal with a pull request submitted by a port maintainer to the central repository. But I’ve got to admit that I haven’t read much more than our wiki page up to now. There are surely more details in GitHub’s help... _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
