6 ms·
In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the
by broeng 4y ago
In your example, you pretty much have to change the same line, or neighbouring line, those 10 times to end in that scenario. If it's just somewhere else in the file, git auto-merging will handle it just fine.
It seems like a very contrived example to me. We have been running rebase/fast-forward only for close to 10 years now, and I have never experienced anything that unfortunate.
- ncann 4y agoYeah that scenario only ever happens if you have an extremely large branch that hasn't been merged into the target branch for a long time (like a feature branch that takes months to develop), which btw isn't really something that should be done anyway (always try for more frequent merge with small side branches).
- michaelt 4y agoSounds like you've never worked on a project with a file everyone wants to append to :) If every error in your system needs a separate entry in the error enum, or every change needs an entry in the changelog - loads of changes will try to modify the last line of the file.
- account42 4y agoEven multiple appends are not that bad for rebasing - if you put the remote changes before your own then after the first commit the context for your remaining commits will be the same. If order actually matters then yeah, git can't magically know where each new line should go.
- olddustytrail 4y agoDepending on the format of your files, entries like "changelog merge=union" in your .gitattributes file might work for you.
- broeng 4y agoOh, I have. :-) I'm not saying these situations are impossible. But you can work towards reducing when they arise. If everyone needs to change the same file, then it sounds like something should be refactored (it's probably a quite big file as well?). If every error needs to go to the same error enum, that sounds like an error enum that might benefit from being split up. And if every change needs to write to a common changelog file, I would personally find a new way to produce that changelog. If it's that big a painpoint, then I would look into different ways to get around it.
- simiones 4y agoIt 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.
- collinvandyck76 4y agoIt's not as contrived as you may think. I, along with what I imagine are many others, do a lot of frequent micro-commits as time goes on and the feature becomes more complete, with a lot of commits in the same area of any given file. Rebasing a development branch in this state is pretty gnarly when a conflict arises. Sadly, my current approach is to just reset my development branch to the merge base and make one huge commit, and then rebase.
- broeng 4y agoI do a lot of micro-commits as well, though I rarely find that other members of my team are doing the same, to the same files, at the same time. When that happens, we look into if it's possible to do more frequent merges (fast-forward rebases through Gerrit, to be specific) of our smaller commits to master, so we don't accumulate too much in isolation. I find it helps reducing bugs as well, if two or more members are doing active work in the same area in that way, it's not good to be working in complete isolation as it just opens up for bugs because of incompatibility with the work going on in parallel.
- Beltalowda 4y ago> It seems like a very contrived example to me. I run in to this quite frequently, even on projects where I'm the only one working on it (I tend to have a lot of things going on in parallel). Once branches diverge and commits accumulate it can become a right pain. Usually my solution is to merge master into the branch just to keep up to date and then just undo everything, make one new commit in the master, and rebase that. But in some more difficult cases it was "just merge and fuck it because life's too short". I've also just manually "copy/paste merged" things to a new branch, because that seemed quicker than dealing with all the merges/conflicts. Maybe there are better ways of doing this, and arguably I shouldn't have all these long-lived branches in the first place (but it works well for me, so...), but it's not that much of a contrived edge case.
- couchand 4y ago> arguably I shouldn't have all these long-lived branches in the first place This is the problem here. If you have multiple long-lived branches, there's no technical solution to preventing rot -- you must actively keep them in sync. Regularly merging in main is the opposite of the proper solution. Constantly rebasing on top of main is the proper solution.