Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Resolve simple merge conflicts on GitHub

github.com

Post reply on HN
Print view View original

11–20 of 71 posts

Re: Resolve simple merge conflicts on GitHub

#14

Post by btown »

nothrabannosir wrote: post #8
pkamb wrote: post #4

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 in…

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

I'd imagine this also breaks bisect (and might make your CI system very confused), since you have a non-good commit.

Re: Resolve simple merge conflicts on GitHub

#15

Post by chrisamanse »

pkamb wrote: post #4

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 in…

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

Re: Resolve simple merge conflicts on GitHub

#16

Post by mojuba »

aargh_aargh wrote: post #13
mojuba wrote: post #11

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

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

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.

Re: Resolve simple merge conflicts on GitHub

#17

Post by StefanKarpinski »

acchow wrote: post #7
pkamb wrote: post #4

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 in…

Sounds like this would be a nightmare to rebase onto.

Not to mention breaking git bisect horribly.

Re: Resolve simple merge conflicts on GitHub

#18

Post by pkamb »

chrisamanse wrote: post #15
pkamb wrote: post #4

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 in…

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

"Diffing the commits" isn't really available in in a GitHub-style Pull Request web UI, which is where 99% of our code review is happening. I'm definitely optimizing for that view of the merge over everything else.

Re: Resolve simple merge conflicts on GitHub

#19

Post by eridius »

pkamb wrote: post #4

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 in…

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.
Post reply on HN