31–40 of 71 posts
Finally! This is excellent news.
This is the dumbest shit I swear! GIT is super dumb when dealing with conflicts. Maybe GIT needs to get smarter. When another dev, and I work on the exact same line of code. I add a class, and he adds an ID. GIT goes like oh crap a conflict I have zero idea what to do! Here is a bunch of commented crap in your code, and let me tank grunt for you real quick.
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.
This is the dumbest shit I swear! GIT is super dumb when dealing with conflicts. Maybe GIT needs to get smarter. When another dev, and I work on the exact same line of code. I add a class, and he adds an ID. GIT goes like oh crap a conflict I have zero idea what to do! Here is a bunch of commented crap in your code, and let me tank grunt for you real quick.
Earlier quoted context omitted.
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.
Yeah, I have no doubt that you can somehow show this information via the command line. The problem is that it's hidden in GitHub's Pull Request web UI, where all of our code review happens. Committing the conflicts and then resolving in the next commit surfaces the conflict resolutions to the PR where it can be reviewed like all of the other code we write.
Also, I haven't used it extensively since its release, but doesn't the Reviews feature resolve this now?
diff3 conflict style display would be considerably more useful.
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
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
This is the dumbest shit I swear! GIT is super dumb when dealing with conflicts. Maybe GIT needs to get smarter. When another dev, and I work on the exact same line of code. I add a class, and he adds an ID. GIT goes like oh crap a conflict I have zero idea what to do! Here is a bunch of commented crap in your code, and let me tank grunt for you real quick.
How do you propose that be dealt with programmatically?
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 don't notice it stopped working in a specific way...that all scares me.
I'm not sure we're ready for smarts in our merging.
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…
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?
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 rerere (reuse recorded resolution): https://git-scm.com/2010/03/08/rerere.html
"it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you."
[1] This isn't explicitly against the rules but if it's in bad taste I'll happily remove it.
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…
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?
Earlier quoted context omitted.
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…
I posted this in a comment above but because it's relevant I feel it's worth putting here as well[1]: git rerere (reuse recorded resolution): https://git-scm.com/2010/03/08/rerere.html "it allows you to ask Git to remember how you've resolved a hunk conflict so that the next time it sees the same conflict, Git can automatically resolve it for you." [1] This isn't explicitly against the rules but if it's in bad taste…