Travis and "rebase before commit"

[Sterling P. Smith]

The simple solution is to allow the "Rebase"  option in GitHub.

-Sterling

----- Original Message -----
> From: "Mojca Miklavec" <mojca at macports.org>
> To: "Zero King" <l2dy at macports.org>
> Cc: "MacPorts Development" <macports-dev at lists.macports.org>
> 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