Hacker News Reader

Comment by ainar-g | Hacker News Reader

On a related note, I seriously recommend everyone to set their merge.conflictStyle to diff3 (or even zdiff3 on newer Gits). It shows you all of your version, thier version, and the original, common-ancestor version. It really should be the default, and, as far as I know, the only reason it isn't is because there are some older diff(1) implementation that don't support three-way diffs.

See https://blog.nilbus.com/take-the-pain-out-of-git-conflict-re... and https://stackoverflow.com/q/27417656.

View on HN

I think learning diff3 has had one of the largest ROIs of anything I've perhaps _ever_ learned. I show it to interns whenever I can, which tends to remind me just how daunting it is to use for the first time.

If I didn't use JetBrains' products for anything else, I'd still use it for git -> Resolve Conflicts.

Amen. I also have Kaleidoscope which is great for diffs but nothing beats Resolve Conflicts from JetBrains.

How can this be a thing since 2008 and I didn't know? Thank you!

I just learned about push-options last week.

https://git-scm.com/docs/git-push#Documentation/git-push.txt...

https://docs.gitlab.com/ee/user/project/push_options.html

Please vote for the resulting issues from that thread in order to help others discover the feature: https://news.ycombinator.com/item?id=31040637

What do you use them for? I went through the GitLab doc, I see how it could make sense for automated PRs, but for manual ones I don't see how I would benefit from them.

Debugging a deploy job (stage) from a feature branch via an env variable.

Is there a way to change the output format? I find that "||||||| merged common ancestor" to be very noisy, visually.

You can also just type “git mergetool” and it will open up your difftool of choice with all 4 versions of the file on one screen. Assuming you have a difftool capable of 3-way merge.

Manually reading through merge conflict markers feels very old once you get used to this.

Apart from the "Ten Thousand" xkcd reference, I heavely suggest to use the venerable kdiff3[1]

[1] http://kdiff3.sourceforge.net/

I think this might be the project page now: https://invent.kde.org/sdk/kdiff3

Meld is also pretty nice https://meldmerge.org/

Even better may be to install and use git-delta which does this amongst many other things:

https://github.com/dandavison/delta

The parent comment is about merge style, not diff style. Delta displays diffs, it's not a merge tool.

It is also a tool to resolve merges as well.

It can display merge conflicts (as Git can display those) but it doesn't resolve them. It's purely a display tool. Its installation instructions recommend setting `merge.conflictstyle = diff3` but that's not an automatic process.

How so? Its documentation on merge conflicts just reiterates setting `diff3`.

Relevant: https://www.gnu.org/software/diffutils/manual/diffutils.html...

When I'm merging, and things are really messed up due to unrelated things being diffed together, in a situation in which both must survive in the merged result, I do this:

1. Find syntactic boundaries before and after the conflict, in order to delimit an area that is a complete piece of top-level syntax, in which the conflict lies. So that is to say if the conflict is flanked by fragments of syntax, I include them.

2. I make a copy of this entire area, so that I have two consecutive copies of the complete syntactic unit, and therefore two copies of the conflict.

3. Go through the first copy and edit it with a view toward one side of the conflict.

4. Repeat on the second copy, but with a view toward keeping the changes from the other side of the conflict.

Example (manually created):

   static void foo(int x)
   {
   <<<<<<<
     return x;
   }

   static void bar(int y)
   {
      return y;
   =======
      return x + 1;
   }

   static void xyzzy(int z)
   {
     return z
   >>>>>>>
   }

WTF? Ah, OK: there is originally a foo(), and one side added bar() and the other xyzzy(). We need both. Ah, and foo was tweaked t o be different.

OK, what is the complete syntactic unit? We include everything from the "static void foo" to the closing brace after the >>>>>> and copy it. We include markers:

   // COPY A
   static void foo(int x)
   {
   <<<<<<<
     return x;
   }

   static void bar(int y)
   {
      return y;
   =======
      return x + 1;
   }

   static void xyzzy(int z)
   {
     return z
   >>>>>>>
   }

   // COPY B
   static void foo(int x)
   {
   <<<<<<<
     return x;
   }

   static void bar(int y)
   {
      return y;
   =======
      return x;
   }

   static void xyzzy(int z)
   {
     return z
   >>>>>>>
   }

Now we work through COPY A, keeping the <<<<<<< side:

   // COPY A
   static void foo(int x)
   {
     return x;
   }

   static void bar(int y)
   {
      return y;
   }

   // COPY B
   static void foo(int x)
   {
   <<<<<<<
     return x + 1;
   }

   static void bar(int y)
   {
      return y;
   =======
      return x;
   }

   static void xyzzy(int z)
   {
     return z
   >>>>>>>
   }

Then through COPY B, keeping the >>>>>>> side:

   // COPY A
   static void foo(int x)
   {
     return x;
   }

   static void bar(int y)
   {
      return y;
   }

   // COPY B
   static void foo(int x)
   {
      return x + 1;
   }

   static void xyzzy(int z)
   {
     return z
   }

Now get rid of the duplicate foo. It looks like we need the one which does "return x + 1":

   static void foo(int x)
   {
     return x + 1;
   }

   static void bar(int y)
   {
      return y;
   }

   static void xyzzy(int z)
   {
     return z
   }

Reply on news.ycombinator.com