{"id":64204,"date":"2022-04-18T09:44:50","date_gmt":"2022-04-18T16:44:50","guid":{"rendered":"https:\/\/github.blog\/?p=64204"},"modified":"2022-04-19T08:39:26","modified_gmt":"2022-04-19T15:39:26","slug":"highlights-from-git-2-36","status":"publish","type":"post","link":"https:\/\/github.blog\/open-source\/git\/highlights-from-git-2-36\/","title":{"rendered":"Highlights from Git 2.36"},"content":{"rendered":"

The open source Git project just released Git 2.36,<\/a> with features and bug fixes from over 96 contributors, 26 of them new. We last caught up with you on the latest in Git back when 2.35 was released<\/a>.<\/p>\n

To celebrate this most recent release, here\u2019s GitHub\u2019s look at some of the most interesting features and changes introduced since last time.<\/p>\n

Review merge conflict resolution with –remerge-diff<\/span><\/a><\/h2>\n

Returning readers may remember our coverage of merge ort<\/code><\/a>, the from-scratch rewrite of Git’s recursive<\/code><\/a> merge engine.<\/p>\n

This release brings another new feature powered by ort<\/code>, which is the --remerge-diff<\/code> option. To explain what --remerge-diff<\/code> is and why you might be excited about it, let’s take a step back and talk about git show<\/code>.<\/p>\n

When given a commit git show<\/code> will print out that commit’s log message as well as its diff. But it has slightly different behavior when given a merge commit, especially one that had merge conflicts. If you’ve ever passed a conflicted merge to git show<\/code>, you might be familiar with this output:<\/p>\n

\"\"<\/p>\n

If you look closely, you might notice that there are actually two columns of diff markers (the +<\/code> and -<\/code> characters to indicate lines added and removed). These come from the output of git diff-tree -cc<\/code>, which is showing us the diff between each parent and the post-image of the given commit simultaneously.<\/p>\n

In this particular example, the conflict occurs because one side has an extra argument in the dwim_ref()<\/code> call, and the other includes an updated comment to use reflect renaming a variable from sha1<\/code> to oid<\/code>. The left-most markers show the latter resolution, and the right-most markers show the former.<\/p>\n

But this output can be understandably difficult to interpret. In Git 2.36, --remerge-diff<\/code> takes a different approach. Instead of showing you the diffs between the merge resolution and each parent simultaneously, --remerge-diff<\/code> shows you the diff between the file with merge conflicts, and the resolution.<\/p>\n

\"\"<\/p>\n

The above shows the output of git show<\/code> with --remerge-diff<\/code> on the same conflicted merge commit as before. Here, we can see the diff3<\/code>-style<\/a> conflicts (shown in red, since the merge commit removes<\/em> the conflict markers during resolution) along with the resolution. By more clearly indicating which parts of the conflict were left as-is, we can more easily see how the given commit resolved its conflicts, instead of trying to weave-together the simultaneous diff output from git diff-tree -cc<\/code>.<\/p>\n

Reconstructing these merges is made possible using ort<\/code>. The ort<\/code> engine is significantly faster than its predecessor, recursive<\/code>, and can reconstruct all conflicted merge in linux.git in about 3 seconds (as compared to diff-tree -cc<\/code>, which takes more than 30 seconds to perform the same operation
\n[source<\/a>]).<\/p>\n

Give it a whirl in your Git repositories on 2.36 by running git show --remerge-diff<\/code> on some merge conflicts in your history.<\/p>\n

[source<\/a>]<\/p>\n

More flexible fsync configuration<\/span><\/a><\/h2>\n

If you have ever looked around in your repository’s .git<\/code> directory, you’ll notice a variety of files: objects, references, reflogs, packfiles, configuration, and the like. Git writes these objects to keep track of the state of your repository, creating new object files when you make new commits, update references, repack your repository, and so on.<\/p>\n

Most likely, you haven’t had to think too hard about how these files are written and updated. If you’re curious about these details, then read on! When any application writes changes to your filesystem, those changes aren’t immediately persisted, since writing to the external storage medium is significantly slower<\/a> than updating your filesystem’s in-memory caches.<\/p>\n

Instead, changes are staged in memory<\/a> and periodically flushed to disk at which point the changes are (usually, though disks and controllers can have their own write caches, too) written to the physical storage medium.<\/p>\n

Aside from following standard best-practices (like writing new files to a temporary location and then atomically moving them into place), Git has had a somewhat limited set of configuration available to tune how and when it calls fsync<\/code>, mostly limited to core.fsyncObjectFiles<\/code><\/a>, which, when set, causes Git to call fsync()<\/code> when creating new loose object files<\/a>. (Git has had non-configurable fsync()<\/code> calls scattered throughout its codebase for things like writing packfiles, the commit-graph, multi-pack index, and so on).<\/p>\n

Git 2.36 introduces a significantly more flexible set of configuration options to tune how and when Git will explicitly fsync<\/code> lots of different kinds of files, not just if it fsync<\/code>s loose objects.<\/p>\n

At the heart of this new change are two new configuration variables:
\ncore.fsync<\/code><\/a> and core.fsyncMethod<\/code><\/a>. The former lets you pick a comma-separated list of which parts of Git’s internal data structures you want to be explicitly flushed after writing. The full list can be found in the documentation, but you can pick from things like pack<\/code> (to fsync files in $GIT_DIR\/objects\/pack<\/code>) or loose-object<\/code> (to fsync loose objects), to reference<\/code> (to fsync references in the $GIT_DIR\/refs<\/code> directory). There are also aggregate options like objects<\/code> (which implies both loose-object<\/code> and pack<\/code>), along with others like derived-metadata<\/code>, committed<\/code>, and all<\/code>.<\/p>\n

You can also tune how Git ensures the durability of components included in your core.fsync<\/code> configuration by setting the core.fsyncMethod<\/code> to either fsync<\/code> (which calls fsync()<\/code>, or issues a special fcntl()<\/code><\/a> on macOS), or writeout-only<\/code>, which schedules the written data for flushing, though does not guarantee that metadata like directory entries are updated as part of the flush operation.<\/p>\n

Most users won’t need to change these defaults. But for server operators who have many Git repositories living on hardware that may suddenly lose power, having these new knobs to tune will provide new opportunities to enhance the durability of written data.<\/p>\n

[source<\/a>, source<\/a>, source<\/a>]<\/p>\n

Stricter repository ownership checks<\/span><\/a><\/h2>\n

If you haven’t seen our blog post from last week<\/a> announcing the security patches for versions 2.35 and earlier, let me give you a brief recap.<\/p>\n

Beginning in Git 2.35.2, Git changed its default behavior to prevent you from executing git<\/code> commands in a repository owned by a different user than the current one. This is designed to prevent git<\/code> invocations from unintentionally executing commands which the repository owner configured.<\/p>\n

You can bypass this check by setting the new safe.directory<\/code> configuration<\/a> to include trusted repositories owned by other users. If you can’t upgrade immediately, our blog post<\/a> outlines some steps you can take to mitigate your risk, though the safest thing you can do is upgrade to the latest version of Git.<\/p>\n

Since publishing that blog post<\/a>, the safe.directory<\/code> option now interprets the value *<\/code> to consider all Git repositories as safe, regardless of their owner. You can set this in your --global<\/code> config to opt-out of the new behavior in situations where it makes sense.<\/p>\n

[source<\/a>]<\/p>\n

Tidbits<\/span><\/a><\/h2>\n

Now that we have looked at some of the bigger features in detail, let’s turn to a handful of smaller topics from this release.<\/p>\n