Highlights from Git 2.36

https://github.blog/2022-04-18-highlights-from-git-2-36/

by todsacerdoti • 4 years ago

128 30 4 years ago

ainar-g• 4 years ago

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.

glogla• 4 years ago

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

NeckBeardPrince• 4 years ago

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

_ZeD_• 4 years ago

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

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

tvb12• 4 years ago

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

kapilvt• 4 years ago

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

encryptluks22• 4 years ago

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

https://github.com/dandavison/delta

lilyball2• 4 years ago

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

aendruk• 4 years ago

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

tylerFowler• 4 years ago

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.

lazulicurio• 4 years ago

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

kazinator• 4 years ago

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
   }

karmakaze• 4 years ago

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

user3939382• 4 years ago

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

Too2• 4 years ago

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.

jwilk• 4 years ago

Stricter repository ownership checks discuessed on HN:

https://news.ycombinator.com/item?id=31009675

clumsysmurf• 4 years ago

Anyone know of up-to-date binaries for Mac OS ... our work machines are heavily restricted, we can not compile from sources, use homebrew, install into /usr/local, etc.

I just want something I can put in ~/.local/bin or something, like so many modern command line tools these days (fzf, rg, etc).

git-osx-installer doesn't seem to be maintained. It still seems strange to me that in 2021 such a large project doesn't have official binaries for a popular platform.

Bilal_io• 4 years ago

See if you can extract the binary from here.

https://mirrors.edge.kernel.org/pub/software/scm/git/

petepete• 4 years ago

Hate to remind you but we're a third of the way through 2022.

rektide• 4 years ago

Day 778 of March 2020; pandemic still trucking.

JamesSwift• 4 years ago

Maybe a single-user install of Nix Package Manager with a custom prefix in your home directory? Not sure if that breaks things or not

vlovich123• 4 years ago

The "More flexible fsync configuration" section made me think of [1]. I wonder how much faster Git would get by using Sqlite to manage the DB instead of using naked filesystem objects.

[1] https://www.sqlite.org/fasterthanfs.html

DiabloD3• 4 years ago

I wish it was an option, especially for git on NTFS systems

atonse• 4 years ago

Can’t imagine it’s too hard to adopt it this way?

I know folks like MS have made big changes to the underlying storage layers to better handle massive repos.

Too2• 4 years ago

Regarding fetch --refetch. Why does it need to refetch all the objects and not just the missing ones? And in that case, is it not possible for such recovery to be automatic without extra flags?

Very often with these failures it’s really just a single tree-object that is missing.

Highlights from Git 2.36

Related Stories