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

41–50 of 71 posts

Re: Resolve simple merge conflicts on GitHub

#41

Post by palunon »

BinaryIdiot wrote: post #36
nilved wrote: post #33

Earlier quoted context omitted.

How do you propose that be dealt with programmatically?

To be fair git could be given a tiny bit of "smarts" per language it's looking at. So say 2 different people add attributes to an HTML item it could use some sort of system that let's it run an HTML merge resolution routine that says "hey that's cool let me just combine those". At the same time adding extra smarts like that, while providing a better UX when it works , the times where it doesn't work especially if you…

Git supports external merge tools (per file type too). They don't need to be packaged with the base install IMO, and git won't support every language under the sun.

For example Unity3D are distributing one for their assets (which are not nice to merge as simple text)

Re: Resolve simple merge conflicts on GitHub

#42

Post by [deleted] »

BinaryIdiot wrote: post #36
nilved wrote: post #33

Earlier quoted context omitted.

How do you propose that be dealt with programmatically?

To be fair git could be given a tiny bit of "smarts" per language it's looking at. So say 2 different people add attributes to an HTML item it could use some sort of system that let's it run an HTML merge resolution routine that says "hey that's cool let me just combine those". At the same time adding extra smarts like that, while providing a better UX when it works , the times where it doesn't work especially if you…

[deleted]

Re: Resolve simple merge conflicts on GitHub

#44

Post by swampthing »

jklein11 wrote: post #43

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.

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

Re: Resolve simple merge conflicts on GitHub

#45

Post by jzwinck »

sethammons wrote: post #39
kovrik wrote: post #9

Earlier quoted context omitted.

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?

And you just lost git bisect

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

Re: Resolve simple merge conflicts on GitHub

#46

Post by nothrabannosir »

aargh_aargh wrote: post #10
nothrabannosir wrote: post #8

Earlier quoted context omitted.

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

Why would it? You can get a conflict on a cherry-pick as well.

I meant to write bisect---I was in the middle of an actual git workflow and accidentally wrote this instead. :)

Re: Resolve simple merge conflicts on GitHub

#47

Post by robinson7d »

jzwinck wrote: post #45
sethammons wrote: post #39

Earlier quoted context omitted.

And you just lost git bisect

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

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.

Re: Resolve simple merge conflicts on GitHub

#48

Post by paulddraper »

sethammons wrote: post #39
kovrik wrote: post #9

Earlier quoted context omitted.

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?

And you just lost git bisect

Not really; git bisect skip still works.

I agree I don't like it either.

Re: Resolve simple merge conflicts on GitHub

#49

Post by stormbrew »

bjacobel wrote: post #24
mojuba wrote: post #16

Earlier quoted context omitted.

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.

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

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.

Re: Resolve simple merge conflicts on GitHub

#50

Post by pkamb »

sethammons wrote: post #39
kovrik wrote: post #9

Earlier quoted context omitted.

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?

And you just lost git bisect

`git bisect skip`
Post reply on HN