
Resolve simple merge conflicts on GitHub - moby
https://github.com/blog/2293-resolve-simple-merge-conflicts-on-github
======
pkamb
On my team I've found that it's incredibly useful to _commit_ the merge
conflicts and conflict markers, then immediately resolve the conflicts in the
next commit. This gives you one commit that shows exactly how the two branches
merged together, followed by a commit that shows exactly how the conflicts
were resolved. The resolution commit can then be code reviewed independently
for a nice clean view of the conflicts introduced in the merge. It also allows
you to easily reset to the merge commit and resolve the conflicts differently.

The standard git workflow (and this github feature) seems to promote resolving
the conflicts alongside all of the other changes in the merge working copy.
This make me nervous, as there's no way to differentiate the _new_ lines that
were introduced to resolve merge conflicts from the thousands of lines of
(previously reviewed) code from the feature branch.

If you're not careful, completely unrelated working-copy code and behavior can
be introduced in a "merge commit" and neither you or any of your reviewers
will notice. "Looks good to me."

~~~
kovrik
Yes, that is a problem.

On the other hand, with your approach you are going to have revisions that
won't even build/compile.

If you have automatic builds or/and unit/integration tests, then you'll have
failed builds every time you have a merge conflict.

Also, you are kind of 'polluting a well': what if meanwhile someone merges
that revision into his/her branch? Or what if you have automatic merges
configured?

~~~
sethammons
And you just lost git bisect

~~~
jzwinck
You can get it back by making your bisect test function return "good" whenever
it sees a commit with merge conflicts.

~~~
robinson7d
I don't think that would work, but correct me if I'm wrong.

As far as I know, git bisect does a binary search along the commits; `good`
tells it to look at the latter half, `bad` to look at the former.

So suppose you have five commits (1,2,3,4,5), where 1 is the working state,
and 3 is a conflict commit. It will start by asking about the middle commit
(3), automatically choose `good`, and determine that 3 was the latest working
commit (after checking 4, which says `bad`).

\----

EDIT: Obviously this is simplified to explain the issue with marking "good"
those commits.

~~~
michaelmior
This is resolved if you skip the commits with a conflict instead of marking as
good.

------
messutied
So simple, so useful, I wonder if this feature wasn't already in Gitlab since
it seems to be more full featured

~~~
connorshea
GitLab does have it already:
[https://docs.gitlab.com/ce/user/project/merge_requests/resol...](https://docs.gitlab.com/ce/user/project/merge_requests/resolve_conflicts.html)

~~~
wyldfire
That's flipping awesome. Does it already have code review too?

~~~
sytse
Yes, with versions.

------
orivej
diff3 conflict style display would be considerably more useful.

~~~
bjeanes
Agreed.

It can be a bit noisier at first but once you learn to read it, I find it
makes resolving conflicts so much easier.

For those of you who haven't used it, try switching it on and/or read
[https://psung.blogspot.com.au/2011/02/reducing-merge-
headach...](https://psung.blogspot.com.au/2011/02/reducing-merge-headaches-
git-meets.html) for more details.

tl;dr it shows

~~~
dabber
That's great, thanks for sharing.

FYI: If anyone is interested in the section about git rerere (reuse recorded
resolution), the link at the bottom of that article leads to a 503; a repost
can be found here: [https://git-scm.com/2010/03/08/rerere.html](https://git-
scm.com/2010/03/08/rerere.html)

------
rosstex
Finally! This is excellent news.

~~~
Insanity
Yeah this is quite a great update.

------
jklein11
To me this feels like making a commit without unit testing first. When I find
a conflict I like to be able to resolve it and then do some unit testing to
make sure that my revision didn't miss anything.

~~~
swampthing
I suspect the use-case they have in mind are folks who have CI hooked up to
Github (so using this feature will automatically trigger tests).

~~~
euyyn
Sure, but that's a much slower cycle than running your unit tests locally.

------
mojuba
I didn't know I could merge on github.com in the first place... where is their
merge function, by the way?

~~~
aargh_aargh
It's literally the hallmark of GitHub... How else would pull requests work?
(well, there _is_ the rebase option now...)

~~~
mojuba
Hmm. I usually do merges locally as serious stuff should be built and tested
before pushing anyway, so probably why never used GitHub's hosted functions.

~~~
bjacobel
> serious stuff should be built and tested before pushing anyway

Yes and no. Build in your CI server that's set up to mirror your prod
environment after pushing, but before merging. That's what the whole industry
of CI providers and integrations built into and around GitHub and GitLab is
for.

~~~
stormbrew
To be fair, one of the annoying things about how PRs work is that they don't
test the merge, they test the commit relative to its original base. Your tests
may pass in the PR, but fail once applied to later changes in the main line.

~~~
pavel_lishin
Most CI solutions will take care of that; they'll pull in the PR, merge it
locally with master, and run tests on _that_.

~~~
x1798DE
I can't speak to the "merge-and-run" behavior of CI, but in my experience,
most of these merge conflicts arise because of a time delay between making the
PR (at which point CI is run) and merging the PR. It would be quite resource
intensive to re-build every PR against every new branch in master.

~~~
pavel_lishin
> _It would be quite resource intensive to re-build every PR against every new
> branch in master._

Depends on just how resource intensive a build is, and how often commits are
made to master.

Here at work, we don't do that, but it wouldn't be a complete clusterfuck if
we were to.

