Resolving pull request conflicts

[Mojca Miklavec]

Dear Ryan,

On 23 February 2017 at 11:19, Ryan Schmidt  wrote:
> Browsing pull requests, I found this one:
>
> https://github.com/macports/macports-ports/pull/305
>
> Another commit had happened to that port in the mean time, so the PR now had conflicts and could not be applied as-is. GitHub invited me to edit the file on the web to resolve the conflict, so I did. I was then asked by the PR author not to do that. Can someone explain why resolving the conflict was bad?

It's not resolving the conflict that's bad.

I guess it's just that the GitHub's user interface is anything but
optimal when it comes to certain aspects.

I'm still confused about what exactly you did to end up in that
situation (but it's probably more clear to me now that you mentioned
it; perhaps I should this on some test repository).

I agree with Zero King that it makes more sense to keep the branches
clean. If anything it's confusing to see 20 unrelated commits when
it's about merging some trivial changes in an unrelated file.

We kind of decided that we'll try to keep our history linear & clean.
(I'm sure you still remember Andrea's 300 duplicated commits in a
failed attempt to do so and probably agree that it makes sense to do
our best to avoid repeating such type of commits?)

Ever since I discovered that GitHub won't use my email when I click on
the merge button in pull requests, I never use the GitHub's GUI to do
any operations like this one since I never know what it will do behind
the scene.


Here's what I do when I work on Pull Requests.

1.) First of all I made sure to add

    [pull]
        rebase = true

to .git/config just in case that I would forget to call "--rebase"
when I do "git pull". If that option is missing, one should always try
to run "git pull origin master --rebase" on the local master branch to
avoid ending up with weird merges.

2.) Here's what I do to fetch the changes locally and push them back:

# set these three lines manually
PR_N=123
PR_USER=some-username
PR_REMOTEBR=remote-branch-name

PR_LOCALBR=pr${PR_N}-${PR_USER}-${PR_REMOTEBR}

git fetch https://github.com/$PR_USER/macports-ports.git $PR_REMOTEBR
git checkout -b $PR_LOCALBR FETCH_HEAD
git rebase master

## then do whatever "magic" is needed
## very often using commands like
# git rebase -i HEAD~4
# git commit --amend [--date="..."]

## then check with
# git log --graph
## to make sure that the history and commit messages are OK

# then update the branch in PR first
# (this is also important to make the PR marked as "merged" rather
than "closed")
git push -f https://github.com/$PR_USER/macports-ports.git
$PR_LOCALBR:$PR_REMOTEBR

# then check if the PR looks ok on the web just in case

# and finally push the changes to master
git push origin $PR_LOCALBR:master


Maybe some software already does most of that in a more user-friendly way.

I'm not sure about the proper way to resolve conflicts, but git offers
some command line interface. When I was committing the "$Id" stuff, it
was less work to start from scratch that to keep resolving conflicts.
And very often the commits are so simple that I simple go "from
scratch".

Mojca