diff3 is the way to go. When there are not trivial changes, it is hard to resolve conflicts if you do not know where the conflicting changes come from.
I knew quite a few people that do not know that this option even exists. In my opinion it could make the life of engineers a lot better if this was the default.
I wonder how hard it would be to build a nice diff tool for IB files. If you could (semi) visually view the changes in a meaningful way, maybe a lot of this would be helped. Conflicts would still be hard to merge, but maybe something could be done about that as well.
I've found configuring merge.conflictstyle diff3 without a tool to be superior than tools like kdiff3 and such. This was without any fancy merge conflict rendering. Nowadays some editors will also highlight the changes in a 3-way diff.
The reason no-tool is better is that you don't have to read files in whatever order kdiff3 shows them to you -- they're just files, and you open them.
Sure, diff3 is better than nothing. zdiff3 is even better. But there's so much scope for better diffs still. For starters we could have semantically aware diffs that take into account where blocks are (I think there are some efforts to do this).
But even diff3 is missing information. Lets say the code started as A, you changed it to B. Then you rebase and `master` is C. You'll get basically "It's C now! But you changed it from A to B."
That's not enough information. Why was it changed to C? I don't know how to update my diff without that information. Really you need to see the change that changed it to C too.
There's so much scope for an advanced conflict resolution tool. Git gets it wrong in so many situations where you could do better.
For me diffs are more viewable with decent visualization. '14c57' doesn't compare so much with a visual expansion marker connecting the previous and current states.
I haven't thought about this in detail much before but honestly that "view" the author proposed does look pretty nice.
Though I think that something like difftastic is still a bit better, though I haven't properly integrated it into my workflow.
I'm still surprised merge conflicts show up so often. At its core, diff and diff3 haven't changed since the 1980s. Complicated, heuristic-based algorithms that don't take into account the rich metadata and semantics we can understand today.
diff3 is not
- idempotent
- semantic
- stable (formally, stability means that there exists a constant such that for small enough changes there is a guaranteed small merge)
I like the idea but it is clearly incomplete. It gets the fact that there are 3 versions (and that it wants you to generate a 4th) but it misses the important thing which is that you want to see the differences. This option basically leaves you to do the diff yourself. Now the sinple option of just showing the two diffs probably isn't optimal either as the context will be duplicated noise, but I think that is already better. In fact I think the merge diff representation would work well here except for the fact that you want to be able to compile and test the code which you can do with the diff markers.
reply