[HN Gopher] Take the pain out of Git conflict resolution: use di... ___________________________________________________________________ Take the pain out of Git conflict resolution: use diff3 (2017) Author : harporoeder Score : 76 points Date : 2022-04-18 19:53 UTC (2 days ago) (HTM) web link (blog.nilbus.com) (TXT) w3m dump (blog.nilbus.com) | usr1106 wrote: | We never use merge except fast forward merges. So we never have | merge conflicts. | | Of course that means that we might need to rebase and that could | hit conflicts. With diff3 style rebase conflicts are generally | [1] easy to understand. When a commit does not apply cleanly the | diff3 style output gives you 3 sections: | | 1. What the code looks like after the previous commit that has | already been rebased to the new branch under work | | 2. What the code looked like in the original branch | | 3. What it looked like 1 commit later in the original branch. | | Now the question the human is: You (or some one else) changed it | from 2 to 3 in the past. Now your code is not 2 but 1. How do you | introduce an equivalent change from 1 to something that works | like 3? | | Once I have learned that principle I could no longer understand | why diff3 is not the default or how anyone can survive without | it. | | [1] Of course there can always be tricky changes. If an automatic | diff tool choses unlucky alignments the result is not ideal for | humans. But diff3 does not make things worse and generally it | does not happen that often. | | Edit: A couple of iterations needed. Don't try to type somewhat | complex comments on your phone... | thriftwy wrote: | kdiff3 is ok-ish as a GUI option. | usr1106 wrote: | Or meld. | | But I fall back to GUI only in nasty cases. Over 90% I feel | comfortable with diff3 formatted output by git. | miked85 wrote: | I'm not clear how this solution removes pain, it could make | things more confusing for many. | kevincox wrote: | 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. | [deleted] | IshKebab wrote: | 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. | exclipy wrote: | If you know A and B, and you know C, then you know the diff | from A to C. | metadat wrote: | Not sure if I like this better. | | It seems even more complicated to track 3 context points in time | rather than 2. | | I'm open to changing my mind, but would need reasons. Botched | rebases aren't a common issue for me (though merge conflict | resolution can be unpleasant). | exclipy wrote: | I don't see how there is any room for opinion. If you read the | article, it opens with an example where it is _impossible_ to | determine the correct merge from the given information without | diff3. | patrickthebold wrote: | Oh, I love diff3. Having the common base (usually) makes it | easier to see "what _change_ happened in the other branch", and | "what _change_ happened in my branch". Then it's (usually) | straight forward to apply one change to the other. | | Of course, if seeing my code and their code works for you, then | by all means keep doing what works. ___________________________________________________________________ (page generated 2022-04-20 23:00 UTC)