On 20/12/17 14:19, Ken Cunningham wrote:


On Dec 20, 2017, at 1:04 AM, Mojca Miklavec <mo...@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

Reply via email to