3 ms·
It happens pretty often when two different people are adding a new function in the same area of a file. It's likely that as you're working on that function, you
by simiones 4y ago
It happens pretty often when two different people are adding a new function in the same area of a file. It's likely that as you're working on that function, you'll be modifying the surrounding lines a few times (say, you have a first pass for the happy path, then start adding error handling in various passes; or, handling one case of an algorithm in each commit).
Rebase is still by far the most common case in our repo, as yes, these cases appear very rarely. But when they do happen, it's often worth it to do a merge and mess up a history a little bit (or squash, which messes with history in another way) rather than resolving conflicts over and over.
Someone else was also suggesting rerere for this use case, but I've never used it myself and I don't know how well it actually handles these types of use cases.
- broeng 4y agoIt definitely can, and it also sometimes happens to us. But we try to reduce the chance this happens quite a bit, by avoiding letting files grow too big, for example. Other things we do, is use codeformatting with rules that reduce the chance of merge conflicts. For instance, instead of having imports like: import SomePackage.{A, B, C} we format it to: import SomePackage.A import SomePackage.B import SomePackage.C That alone helps a lot. Other formatting rules that avoid dense lines, and instead splits over multiple lines also have a huge impact on merge-conflicts.