Addressing Port submission failures on Travis
jonesc at hep.phy.cam.ac.uk
Wed Dec 20 15:33:13 UTC 2017
On 20/12/17 14:19, Ken Cunningham wrote:
>> On Dec 20, 2017, at 1:04 AM, Mojca Miklavec <mojca at macports.org> wrote:
>>> On 20 December 2017 at 09:04, Ken Cunningham wrote:
>>> keep the master branch up to date, but leave your PR branch alone until it's merged, then delete the branch.
>> Indeed, that's the correct advice. You only ever need one single fork
>> of macports-ports, but make sure to always keep the master branch 100%
>> clean (in sync with upstream) and then make a new branch for each PR.
>> If you PR needs an update, you push all the changes to that branch and
>> that will be properly reflected in the PR. You can even force push to
>> fix mistakes in the initial commit or after "git rebase master" etc.
>> You cannot have a single branch for multiple PRs, but more important:
>> if you modify the master branch, you'll run in all kinds of troubles
>> when merging/rebasing etc., so just remember the rule of one branch
>> per PR.
>> Sometimes people close a PR and open a new one just to fix mistakes.
>> This is not needed either as one can simply update the branch and the
>> PR will properly reflect that.
> The only hiccup comes if the PR lingers and some change is made in master that now requires a change in the PR to resolve a conflict. Frquently this is when I ran into trouble, so perhaps Mojca might describe the best approach to updating the PR for this issue (eg the qt4-mac PR that needs this done right now ).
Once you get a conflict there is in general no 'simple' way to fix it.
It has to be done by hand, by a human, who knows what is needed.
So just pull the update from master into the feature branch for a given
PR, fix the conflict by hand, commit those changes and push the feature
branch back to github. The PR will then adapt.
More information about the macports-dev