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?

[eridius]

You actually can distinguish the new lines. For any non-trivial merge conflict resolution committed as part of the merge, `git show $SHA` will actually show you the conflict resolution. More specifically, if the diff contains anything that's not just a line taken from either of the parents, then that thing is shown.

[acchow]

Sounds like this would be a nightmare to rebase onto.

[chrisamanse]

IMO, it is unnecessary to commit the conflicts. Instead, you can see how merges were resolved by diffing the commits.

[sjrd]

Or much simpler: do not allow merge conflicts to happen in the first place! Any Pull Request that shows with merge conflicts must be rebased on top of the target branch. Problem solved.

[nothrabannosir]

Great idea! Although this does break cherry-pick, doesn't it?

[fogleman]

That's a really good idea! I'm going to start doing that.

[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...

[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... for more details.

tl;dr it shows

[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.

[Ph0X]

I think they explicitly say "simple merge conflicts" in the title. At the end of the day, you should use your own best judgement for when this is useful, and for when you need to go back to your workspace. It's most definitely not meant to be used for every merge conflict.

But not everyone is working on big projects with tests, and not every merge conflict is actually complex code modification.

Sometimes it's just two commits adding something at the end of the file and there's not real conflict, or maybe you modified the same line twice and forgot to pull before doing your 2nd edit.

[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).

[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...)

[tomschlick]

I'd prefer it not be magic. Just because git COULD merge two of the same line changes doesn't mean it SHOULD.

Maybe you have two vastly different methods to solving the same problem and now they are both in there and both not working instead of leaving it up to the merger to decide.

[nilved]

How do you propose that be dealt with programmatically?