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.

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/

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
   }

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

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.

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

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.

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

Day 778 of March 2020; pandemic still trucking.

See if you can extract the binary from here.

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

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

Stricter repository ownership checks discuessed on HN:

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

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.