keep the master branch up to date, but leave your PR branch alone until it's merged, then delete the branch.
> On Dec 19, 2017, at 11:54 PM, Andrew L. Moore <slew...@gmail.com> wrote: > > I’m thinking that rebasing against my GitHub fork of MacPorts is what sent my > pull request into a tail spin (second question below). If so, then it > appears that I need to maintain two MacPorts clones: a private one for > rebasing that only I see, and another on GitHub for submitting pull requests. > Is there a more efficient workflow? > -AM > >> On Dec 20, 2017, at 2:22 AM, Andrew L. Moore <slew...@gmail.com> wrote: >> >> Hi, >> A couple weeks ago, I made a couple Port submissions (devel/libwebsockets >> and net/mosquitto). Travis is reporting build failures for Xcode 7 and 8. >> I don’t, unfortunately, have the resources to easily test on other systems, >> and the Travis report doesn’t seem to offer much guidance what the issue is, >> at least that I could see. How to proceed? >> >> On a separate note, I notice that my pull request appears to be tracking my >> entire macports-ports fork, which includes changes to several other ports. >> Should I create a new fork for each pull request? >> >> For reference, here’s what i did: >> >> * Created a fork of macports-ports on GitHub >> >> * Cloned that fork to my local system >> >> * Added an upstream reference >> (https://github.com/macports/macports-ports.git) >> >> * Then to sync with upstream, I use: >> >> git fetch upstream >> git rebase upstream/master >> >> * And to push to my GitHub fork, I just use: >> >> git push >> >> Got now my pull request appears to have picked up all that activity. Where >> did I go wrong? >> -AM >> >> >