{"id":77738,"date":"2024-04-29T10:14:27","date_gmt":"2024-04-29T17:14:27","guid":{"rendered":"https:\/\/github.blog\/?p=77738"},"modified":"2024-04-30T06:42:43","modified_gmt":"2024-04-30T13:42:43","slug":"highlights-from-git-2-45","status":"publish","type":"post","link":"https:\/\/github.blog\/open-source\/git\/highlights-from-git-2-45\/","title":{"rendered":"Highlights from Git 2.45"},"content":{"rendered":"\n

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

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

Preliminary reftable support<\/span><\/a><\/h2>\n

Git 2.45 introduces preliminary support for a new reference storage backend called “reftable,” promising faster lookups, reads, and writes for repositories with any number of references.<\/p>\n

If you’re unfamiliar with our previous coverage of the new reftable format, don’t worry, this post will catch you up to speed (and then some!). But if you just want to play around with the new reference backend, you can initialize a new repository with --ref-format=reftable<\/code> like so:<\/p>\n

$ git init --ref-format=reftable \/path\/to\/repo\nInitialized empty Git repository in \/path\/to\/repo\/.git\n$ cd \/path\/to\/repo\n$ git commit --allow-empty -m 'hello reftable!'\n[main (root-commit) 2eb0810] hello reftable!\n$ ls -1 .git\/reftable\/\n0x000000000001-0x000000000002-565c6bf0.ref\ntables.list\n$ cat .git\/reftable\/tables.list\n0x000000000001-0x000000000002-565c6bf0.ref\n<\/code><\/pre>\n
With that out of the way, let’s jump into the details. If you’re new to this series, or didn’t catch our initial coverage of the reftable feature, don’t worry, here’s a refresher. When we talk about references<\/a> in Git, we’re referring to the branches and tags that make up your repository. In essence, a reference is nothing more than a name (like refs\/heads\/my-feature<\/code>, or refs\/tags\/v1.0.0<\/code>) and the object ID of the thing that reference points at.<\/p>\n
Git has historically stored references in your repository in one of two ways: either “loose” as a file inside of $GIT_DIR\/refs<\/code> (like $GIT_DIR\/refs\/heads\/my-feature<\/code>) or “packed” as an entry inside of the file at $GIT_DIR\/packed_refs<\/code>.<\/p>\n
For most repositories today, the existing reference backend works fine. For repositories with a truly gigantic number of references, however, the existing backend has some growing pains. For instance, storing a large number of references as “loose” can lead to directories with a large number of entries (slowing down lookups within that directory) and\/or inode exhaustion<\/a>. Likewise, storing all references in a single packed_refs<\/code> file can become expensive to maintain, as even small reference updates require a significant I\/O-cost to rewrite the entire packed_refs<\/code> file on each update.<\/p>\n
That’s where the reftable format comes in. Reftable is an entirely new format for storing Git references. Instead of storing loose references, or constantly updating a large packed_refs<\/code> file, reftable implements a binary format for storing references that promises to achieve:<\/p>\n