Resolving pull request conflicts

[Clemens Lang]

Hi Ryan,

----- On 23 Feb, 2017, at 12:04, Ryan Schmidt ryandesign at macports.org wrote:

> GitHub said the pull request had a conflict. (The PR is a version update, but a
> revbump was committed to the port in the meantime.) GitHub said I could resolve
> the conflict on the command line or in a web-based editor. There was a green
> button inviting me to start resolving the conflict on the web. I clicked this
> and was brought to a web-based text editor showing the Portfile in its
> conflicted state. I edited the file, removing the conflict markers and
> incorrect lines. I clicked the button saying I have now resolved the conflicts.

That's fine, but what GitHub did under the hood (without telling you), is
attempting to merge the current state of the master branch with the PR, and
generating a merge commit with your conflict resolution.

We don't want merge commits, we want rebase + force push, but GitHub does not
give you this option when resolving conflicts on the web interface, apparently.



> Absolutely the history that appears in master should be "clean", meaning one
> commit per logical change. But it is natural, is it not, that a pull request
> might need refinement before being merged, to address feedback or in this case
> conflicts, and that that refinement would come in the form of additional
> commits?

There are multiple approaches here. Some push new commits until they are
satisfied and then squash, others prefer force-pushing until the history is
exactly like they want it.

Squashing would also merge changes that might make sense to have in separate
commits and you cannot review the exact history you are going to merge, so I
personally prefer rebase + force push.

In your case, though, you added a merge commit, which might possibly have been
preserved by the rebase merge method and would have ended up in the master
history.


HTH,
-- 
Clemens Lang