Addressing Port submission failures on Travis

Chris Jones 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.
>>
>> Mojca
> 
> 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.

Chris


More information about the macports-dev mailing list