[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)