17 ms·
Windows, because of the size of the team and the nature of the work, often has VERY large merges across branches (10,000’s of changes with 1,000’s of conflicts)
by js2 9y ago
Windows, because of the size of the team and the nature of the work, often has VERY large merges across branches (10,000’s of changes with 1,000’s of conflicts).
At a former startup, our product was built on Chromium. As the build/release engineer, one of my daily responsibilities was merging Chromium's changes with ours.
Just performing the merge and conflict resolution was anywhere from 5 minutes to an hour of my time. Ensuring the code compiled was another 5 minutes to an hour. If someone on the Chromium team had significantly refactored a component, which typically occurred every couple weeks, I knew half my day was going to be spent dealing with the refactor.
The Chromium team at the time was many dozens of engineers, landing on the order of a hundred commits per day. Our team was a dozen engineers landing maybe a couple dozen commits daily. A large merge might have on the order of 100 conflicts, but typically it was just a dozen or so conflicts.
Which is to say: I don't understand how it's possible to deal with a merge that has 1k conflicts across 10k changes. How often does this occur? How many people are responsible for handling the merge? Do you have a way to distribute the conflict resolution across multiple engineers, and if so, how? And why don't you aim for more frequent merges so that the conflicts aren't so large?
(And also, your merge tool must be incredible. I assume it displays a three-way diff and provides an easy way to look at the history of both the left and right sides from the merge base up to the merge, along with showing which engineer(s) performed the change(s) on both sides. I found this essential many times for dealing with conflicts, and used a mix of the git CLI and Xcode's opendiff, which was one of the few at the time that would display a proper three-way diff.)
- draw_down 9y agoGod, that sounds hellish.
- malnourish 9y agoFor 3 way merging, I've had good luck with beyondcompare
- Peaker 9y agoWhen you have that many conflicts, it's often due to massive renames, or just code moves. If you use git-mediate[1], you can re-apply those massive changes on the conflicted state, run git-mediate - and the conflicts get resolved. For example: if you have 300 conflicts due to some massive rename, you can type in: git-search-replace.py[2] -f oldGlobalName///newGlobalName git-mediate -d Succcessfully resolved 377 conflicts and failed resolving 1 conflict. <1 remaining conflict shown as 2 diffs here representing the 2 changes> [1] https://medium.com/@yairchu/how-git-mediate-made-me-stop-fearing-merge-conflicts-and-start-treating-them-like-an-easy-game-of-a2c71b919984 https://medium.com/@yairchu/how-git-mediate-made-me-stop-fea... [2] https://github.com/da-x/git-search-replace https://github.com/da-x/git-search-replace
- deleted 9y ago[deleted]
- lkmalkova 9y agoNot sure why companies don't develop great merge tools, looks like there is a big market for them.
- eridius 9y agoI just looked at git-mediate and I'm very confused. It appears that all it does is remove the conflict markers from the file after you've already manually fixed the conflict. Except you need to do more work than normal, because you need to apply one of the changes not only to the other branch's version but also to the base. What am I missing here, why would I actually want to use git-mediate when I'm already doing all the work of resolving the conflicts anyway?
- amag 9y agoIt looks like git-mediate does one more important thing; it checks that the conflict is actually solved. In my experience it's very easy to miss something when manually resolving a conflict and often the choices the merge tools give you are not the ones you want.
- deepsun 9y agoIntelliJ IDEA default merger knows when all conflicts in a file are handled and shows you a handy notification on top "Save changes and finish merging".
- mandeepj 9y agoTFS's conflict resolver also does this
- eridius 9y agoWell, all it checks is that you modified the base case to look like one of the two other cases. That doesn't actually tell you if you resolved the conflict though, just that you copied one of the cases over the base case.
- vtbassmatt 9y agoWindows developed an extension that lets them do conflict resolution in the web. We have a server-side API that it calls into, but the extension isn't fundamentally different from using BeyondCompare or $YOUR_FAVORTE_MERGETOOL.
- Flenser 9y agoAn extension to what? Could you open source it?
- vtbassmatt 9y agoExtension to VSTS [1], sorry. We're working with them on making the extension available to the public. It's possible we could open source it as well; I'll poke around. [1] https://www.visualstudio.com/en-us/docs/integrate/extensions/develop/contributions-overview https://www.visualstudio.com/en-us/docs/integrate/extensions...
- Luuseens 9y agoIs this CodeFlow you're talking about?
- eridius 9y agoFor 3-way merging the best tool I've found is Steve Losh's splice.vim (https://github.com/sjl/splice.vim/ https://github.com/sjl/splice.vim/).
- babuskov 9y agoMy favorite tool is Meld: http://meldmerge.org/ http://meldmerge.org/ It's open source. Also: https://stackoverflow.com/questions/572237/whats-the-best-three-way-merge-tool https://stackoverflow.com/questions/572237/whats-the-best-th...
- 72deluxe 9y agoYes back when using Linux, I used Meld a lot. I can recommend it - the directory comparison is good. Also KDiff3. Struggling to remember the other ones I used to try unfortunately.
- aanm1988 9y agoIt's not nearly as bad when you have all the people who work on it with you. You look at who caused conflicts and send out emails. Don't land the merge until all commits are resolved. People who don't resolve their changes get in trouble. Not perfect, but there it is. I worked on a chromium based product as well and had the exact same problem. Eventually we came up with a reasonable system for landing commits and just tried out best to build using chromium, but not having actual patches. Worked okay, not great. Better thant he old system of having people do it manually/just porting our changes to each release.
- MikeHolman 9y agoGenerally, it's the responsibility of whoever made the changes to resolve conflicts (basically, git blame conflicting lines and the people who changed them get notified to resolve conflicts in that file). Distributing the work like this makes the merges more reasonable.
- tokenizerrr 9y agoHow does that work?
- srathi 9y agoYou first rebase against the master locally and push the merged feature branch after resolving all the conflicts yourself. Afterwards, you go to the master and merge it against the updated feature branch. The 2nd merge should not result in any conflicts.
- nerdponx 9y agoThis model can be annoying on running feature branches. Once you rebase, you have to force-push to the remote feature branch. It's not so bad if you use --force-with-lease to prevent blowing away work on the remote, but it still means a lot of rewriting history on anything other than one-off branches.
- cryptonector 9y agoNo no, you never force push to "published" branches, e.g., upstream master. What you're doing when you rebase onto the latest upstream is this: you're making your local history the _same_ as the upstream, plus your commits as the latest commits, which means if you push that, then you're NOT rewriting the upstream's history. (In the Sun model one does rewrite project branch history, but one also leaves behind tags, and downstream developers use the equivalent of git rebase --onto. But the true upstream never rewrites its history.)
- 9y ago
- cryptonector 9y agoMost changes don't touch hundreds/thousands of files. If you were to split the repo into many (as Windows used to be) then you'd still have the problem of huge projects having MANY conflicts, but worse: now you need to do your merge/rebase for each such repo. In any case, rebasing is better than merging. (Rebasing is a series of merges, naturally, but still.)
- InclinedPlane 9y agoIt's usually not so bad. Generally a big project is actually split up into lots of different smaller projects, each of which have an owner. And typically a dev won't touch code that isn't theirs except in unusual cases. Teams that have more closely related or dependent code would typically try to work closer to each other and share code more often than teams that are more separated.
- Flenser 9y agoAre you aware of KDiff3[1]? If you are why do you prefer Xcode's opendiff? [1] http://kdiff3.sourceforge.net/ http://kdiff3.sourceforge.net/
- 72deluxe 9y agoFor me, I found I did not need to do 3 way merges that often and opendiff's native UI fits in better than kdiff3 (for me). I think kdiff3 was Qt? Despite Trolltech's best efforts, Qt does not feel native on a Mac. This isn't to say that KDiff3 isn't great - it is.
- gnud 9y agoI don't think KDiff 3 looks native anywhere, and I don't think it's because of Qt. It uses weird fonts and icons, and for some reason their toolbar buttons just look wrong. Still an extremely useful program.
- daemin 9y agoI spent the better part of a year in a team that was merging and bug fixing our companies engine releases into the customer (and owning company) code base. We also had to deal with different code repositories and version control systems. We ended up with a script that created a new git repository, checked out the base version of the code there. Then created a branch for our updated release and another for their codebase. Then attempted to do a merge between the two. For any files which couldn't be automatically merged it created a set of 4 files, the original then a triplet for doing a 3-way merge. This is also when I bought myself a copy of Beyond Compare 4, which fits perfectly for the price and feature set for what we needed.