The simple solution is to allow the "Rebase" option in GitHub. -Sterling
----- Original Message ----- > From: "Mojca Miklavec" <[email protected]> > To: "Zero King" <[email protected]> > Cc: "MacPorts Development" <[email protected]> > Sent: Wednesday, June 21, 2017 10:57:32 PM > Subject: Travis and "rebase before commit" > Hi, > > I'm so super grateful that we now have a working Travis setup :) > > As I suspected, there would be "problems" that we wouldn't be able to > discover on a test setup and this is one of them. > > It's not really important to fix, but I wanted to mention it. > > Link: > https://travis-ci.org/macports/macports-ports/builds/245646036 > > Explanation: > > What I do now for each PR is a totally cumbersome procedure: > > GH_USER=... > GH_REMOTEBR=... > GH_LOCALBR=p-${GH_USER}-${GH_REMOTEBR} > > git fetch git://github.com/$GH_USER/macports-ports.git $GH_REMOTEBR > git checkout -b $GH_LOCALBR FETCH_HEAD > git rebase master > > git push -f git://github.com/$GH_USER/macports-ports.git > $GH_LOCALBR:$GH_REMOTEBR > git push origin $GH_LOCALBR:master > > The problem is that I would force push to the PR branch seconds or > subseconds before pushing to the master branch to make the PR look > merged rather than closed. > > Now this is a problem for Travis: it will "helpfully" try to build the > PR again which neither does any good to us (harmless, but useless) nor > succeeds if the push to master happens fast enogh. > > I cannot think of a good workaround for that though, except if Travis > detects that the PR has already been deleted and won't report a > failure, but that won't be any more useful either. > > I wouldn't worry about this too much, but I wanted to mention it. > > Mojca
