{"id":54839,"date":"2020-10-19T09:44:04","date_gmt":"2020-10-19T16:44:04","guid":{"rendered":"https:\/\/github.blog\/?p=54839"},"modified":"2021-01-12T14:25:08","modified_gmt":"2021-01-12T22:25:08","slug":"git-2-29-released","status":"publish","type":"post","link":"https:\/\/github.blog\/open-source\/git\/git-2-29-released\/","title":{"rendered":"Highlights from Git 2.29"},"content":{"rendered":"

The open source Git project\u00a0just released Git 2.29<\/a>\u00a0with features and bug fixes from over 89 contributors, 24 of them new. Last time\u00a0we caught up<\/a>\u00a0with you, Git 2.28 had just been released. One version later, let’s take a look at the most interesting features and changes that have happened since then.<\/p>\n

<\/a>Experimental SHA-256 support<\/span><\/a><\/h2>\n

Git 2.29 includes experimental support for writing your repository’s objects using a SHA-256 hash of their contents, instead of using SHA-1.<\/p>\n

What does all of that mean? To explain, let’s start from the beginning.<\/p>\n

When you add files to a repository, Git copies their contents into\u00a0blob<\/code>\u00a0objects in its local database, and creates\u00a0tree<\/code>\u00a0objects that refer to the blobs. Likewise, when you run\u00a0git commit<\/code>, this creates a\u00a0commit<\/code>\u00a0object that refers to the tree representing the committed state. How do these objects “refer” to each other, and how can you identify them when interacting with Git? The answer is that each object is given a unique name, called its\u00a0object id<\/em>, based on a hash of its contents. Git uses SHA-1 as its hash algorithm of choice, and depends on the object ids of different objects to be unique.<\/p>\n

Back in\u00a0this blog post<\/a>, we estimated that even if you had five million programmers writing one commit every second, you would only have a 50% chance of accidentally generating a collision before the Sun engulfs the Earth.\u00a0Some<\/a>\u00a0published<\/a>\u00a0attacks<\/a>\u00a0exist which use tricks that exploit weaknesses in SHA-1 that can reduce the effort required to generate a collision, but these attacks still cost tens of thousands of dollars to execute, and no known examples have been published which target Git.<\/p>\n

Like we stated back in that earlier blog post, Git (and providers that use it, like GitHub) checks each object it hashes to see if there is evidence that that object is part of a colliding pair. This prevents GitHub from accepting both the benign and malicious halves of the pair, since the mathematical tricks required to generate a collision in any reasonable amount of time can be detected and rejected by Git.<\/p>\n

Even so, any weaknesses in a cryptographic hash are a bad sign. Even though Git has implemented detections that prevent the known attacks from being carried out, there’s no guarantee that new attacks won’t be found and used in the future. So the Git project has been preparing a transition plan to begin using a new object format with no known attacks: SHA-256.<\/p>\n

In Git 2.29, you can try out a SHA-256 enabled repository for yourself:<\/p>\n

\n
$ git --version<\/span>\ngit version 2.29.0<\/span>\n$ git init --object-format=sha256 repo<\/span>\nInitialized empty Git repository in \/home\/ttaylorr\/repo\/.git\/<\/span>\n$ cd<\/span> repo<\/span>\n\n$ echo<\/span> '<\/span>Hello, SHA-256!'<\/span><\/span> ><\/span>README.md<\/span>\n$ git add README.md<\/span>\n$ git commit -m \"<\/span>README.md: initial commit\"<\/span><\/span><\/span>\n[master (root-commit) 6e92961] README.md: initial commit<\/span>\n 1 file changed, 1 insertion(+)<\/span>\n create mode 100644 README.md<\/span>\n\n$ git rev-parse HEAD<\/span>\n6e929619da9d82c78dd854dfe237c61cbad9e95148c1849b1f96ada5ee800810<\/span><\/pre>\n<\/div>\n
As of version 2.29, Git can operate in either a full SHA-1 or full SHA-256 mode. It is currently not possible for repositories using different object formats to interoperate with one another, but eventual support is planned. It is also important to note that there are no major providers (including GitHub) which support hosting SHA-256-enabled repositories at the time of writing.<\/p>\n
In future releases, Git will support interoperating between repositories with different object formats by computing both a SHA-1 and SHA-256 hash of each object it writes, and storing a translation table between them. This will eventually allow repositories that store their objects using SHA-256 to interact with (sufficiently up-to-date) SHA-1 clients, and vice-versa. It will also allow converted SHA-256 repositories to have their references to older SHA-1 commits still function as normal (e.g., if I write a commit whose message references an earlier commit by its SHA-1 name, then Git will still be able to follow that reference even after the repository is converted to use SHA-256 by consulting the translation table).<\/p>\n
For more about SHA-256 in Git, and what some of the future releases might look like, you can read\u00a0Git’s transition plan<\/a>.<\/p>\n
[source<\/a>,\u00a0source<\/a>,\u00a0source<\/a>,\u00a0source<\/a>, and\u00a0so<\/a>,\u00a0much<\/a>,\u00a0more<\/a>]<\/p>\n
<\/a>Negative refspecs<\/span><\/a><\/h2>\n
When you run\u00a0git fetch origin<\/code>, all of the branches from the remote\u00a0origin<\/code>\u00a0repository are fetched into your local\u00a0refs\/remotes\/origin\/<\/code>\u00a0hierarchy. How does Git know which branches to fetch, and where to put them?<\/p>\n
The answer is that your configuration file contains one or more “refspecs” for each remote (remember that a “ref” is Git’s word for any named point in history: branches, tags, etc). When you run\u00a0git clone<\/code>, it sets up a default refspec to be used when you fetch from your origin repository:<\/p>\n
\n
$ git config remote.origin.fetch<\/span>\n+refs\/heads\/*:refs\/remotes\/origin\/*<\/span><\/pre>\n<\/div>\n
This refspec tells Git to fetch what’s on the left side of the colon (everything in\u00a0refs\/heads\/<\/code>; i.e., all branches) and to write them into the hierarchy on the right-hand side. The\u00a0*<\/code>\u00a0means “match everything” on the left-hand side and “replace with the matched part” on the right-hand side.<\/p>\n
You can have multiple refspecs, and they can refer to individual refs. For example, this command instructs Git to additionally fetch any\u00a0git notes<\/a>\u00a0from the remote (the\u00a0--add<\/code>\u00a0is important so that we don’t overwrite the default refspec that fetches branches):<\/p>\n
\n
$ git config --add remote.origin.fetch refs\/notes\/commits:refs\/notes\/origin-notes<\/span><\/pre>\n<\/div>\n
Refspecs are used by\u00a0git push<\/code>, as well. Even if you type only\u00a0git push origin mybranch<\/code>, that last\u00a0mybranch<\/code>\u00a0is really a shorthand for\u00a0refs\/heads\/mybranch:refs\/heads\/mybranch<\/code>. This allows you to express more complicated scenarios. Say you’re tagging and want to push all of the tags you have, but you’re not quite ready to share the tips of all of your branches. Here, you could write something like:<\/p>\n
\n
$ git push origin '<\/span>refs\/tags\/*:refs\/tags\/*'<\/span><\/span><\/span><\/pre>\n<\/div>\n
Prior to Git 2.29, refspecs could only be used to say which selection of reference(s) you want. So, if you wanted to fetch all branches except one, you’d have to list them out as arguments one by one. Of course, that assumes that you know the names of all the other references beforehand, so in practice this would look something like:<\/p>\n
\n
$ git ls-remote origin '<\/span>refs\/heads\/*'<\/span><\/span> |<\/span><\/span>\n  grep -v ref-to-exclude |<\/span>\n  awk '{ print $2:$2 }' |<\/span>\n  xargs git fetch origin<\/span><\/pre>\n<\/div>\n
to get all refs in\u00a0refs\/heads\/*<\/code>\u00a0except for\u00a0refs\/heads\/ref-to-exclude<\/code>. Yeesh; there must be a better way.<\/p>\n
In Git 2.29, there is: negative refspecs. Now, if a refspec begins with\u00a0^<\/code>\u00a0it indicates which references are to be excluded. So, instead of the above, you could write instead something like:<\/p>\n
\n
$ git fetch origin '<\/span>refs\/heads\/*:refs\/heads\/*'<\/span><\/span> ^refs\/heads\/ref-to-exclude<\/span><\/pre>\n<\/div>\n
and achieve the same result. When a negative refspec is present, the server considers a reference worth sending if it matches at least one positive refspec and does not match any negative refspecs. Negative refspecs behave exactly as you expect, with a couple of caveats:<\/p>\n