9 ms·
Resolve simple merge conflicts on GitHub
- rosstex 10y agoFinally! This is excellent news.
- Insanity 10y agoYeah this is quite a great update.
- bklyn11201 10y agoSorry, I want more from software in 2017. I want the software to provide me a good suggestion how the merge would be auto-resolved and then I want to visually confirm and accept/reject. Hopefully this is the first step in training a model.
- pkamb 10y agoOn 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."
- fogleman 10y agoThat's a really good idea! I'm going to start doing that.
- acchow 10y agoSounds like this would be a nightmare to rebase onto.
- StefanKarpinski 10y agoNot to mention breaking git bisect horribly.
- nothrabannosir 10y agoGreat idea! Although this does break cherry-pick, doesn't it?
- aargh_aargh 10y agoWhy would it? You can get a conflict on a cherry-pick as well.
- nothrabannosir 10y agoI meant to write bisect---I was in the middle of an actual git workflow and accidentally wrote this instead. :)
- btown 10y agoI'd imagine this also breaks bisect (and might make your CI system very confused), since you have a non-good commit.
- azernik 10y agoBisect knows how to deal with this; you can tell it to ignore a commit that you know is broken for reasons unrelated to the issue upper investigating (and try adjacent ones instead).
- kovrik 10y agoYes, 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?
- phpnode 10y agoPresumably in this model the dev wouldn't push their branch until the merge is actually complete, and there's presumably a convention like prepending `[CONFLICT]` to those commits to discourage people from checking them out directly.
- sethammons 10y agoAnd you just lost git bisect
- jzwinck 10y agoYou can get it back by making your bisect test function return "good" whenever it sees a commit with merge conflicts.
- robinson7d 10y agoI 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 10y ago
- chrisamanse 10y agoIMO, it is unnecessary to commit the conflicts. Instead, you can see how merges were resolved by diffing the commits.
- pkamb 10y ago"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.
- squidbidness 10y agoI love how github fosters discovery and remote collaboration, though one of its liabilities is when great git command-line features are effectively lost unless github re-implements or exposes them, because some conventions incentivize only doing what github itself can do.
- eridius 10y agoYou 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.
- pkamb 10y agoYeah, 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.
- deeplyoptional 10y agoThe PR UI does this. After resolving conflicts, the resulting merge commit will show just the resolution.
- joatmon-snoo 10y agoIf you don't rewrite commit history (it sounds like you don't) you can see it by looking at the diff of the latest commit on the PR. Also, I haven't used it extensively since its release, but doesn't the Reviews feature resolve this now?
- sjrd 10y agoOr 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.
- orivej 10y agodiff3 conflict style display would be considerably more useful.
- bjeanes 10y agoAgreed. 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-headaches-git-meets.html https://psung.blogspot.com.au/2011/02/reducing-merge-headach... for more details. tl;dr it shows
- dabber 10y agoThat'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
- mojuba 10y agoI didn't know I could merge on github.com in the first place... where is their merge function, by the way?
- aargh_aargh 10y agoIt's literally the hallmark of GitHub... How else would pull requests work? (well, there _is_ the rebase option now...)
- mojuba 10y agoHmm. 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.
- aargh_aargh 10y agoIf you write tests diligently, you can integrate CI with GitHub. Travis CI might be the most popular option.
- bjacobel 10y ago> 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 10y agoTo 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 10y ago
- messutied 10y agoSo simple, so useful, I wonder if this feature wasn't already in Gitlab since it seems to be more full featured
- connorshea 10y agoGitLab does have it already: https://docs.gitlab.com/ce/user/project/merge_requests/resolve_conflicts.html https://docs.gitlab.com/ce/user/project/merge_requests/resol...
- Anardo 10y agoThis 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.
- tomschlick 10y agoI'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.
- Bartweiss 10y agoThis seems like a clear case of unequal tradeoffs. There are a couple of conflict patterns that are particularly easy to identify, which git could merge smoothly. For instance, two unrelated code blocks are appended to the bottom of the same file - whoever merged those two probably wants to keep both in any order. But if you don't want that behavior, git is going to quietly auto-merge a bad change. That's easily 10x as bad as the time savings is good, maybe 100x. So I agree - this should not be magic, and I'm pretty sure the design for auto-merge hits practical limits long before technical ones.
- nilved 10y agoHow do you propose that be dealt with programmatically?
- BinaryIdiot 10y agoTo 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 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.
- jklein11 10y agoTo 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 10y agoI 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 10y agoSure, but that's a much slower cycle than running your unit tests locally.
- Ph0X 10y agoI 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.