[{"data":1,"prerenderedAt":788},["ShallowReactive",2],{"/en-us/blog/journey-through-gits-20-year-history":3,"navigation-en-us":36,"banner-en-us":436,"footer-en-us":446,"blog-post-authors-en-us-Patrick Steinhardt":688,"blog-related-posts-en-us-journey-through-gits-20-year-history":702,"assessment-promotions-en-us":738,"next-steps-en-us":778},{"id":4,"title":5,"authorSlugs":6,"body":8,"categorySlug":9,"config":10,"content":14,"description":8,"extension":25,"isFeatured":12,"meta":26,"navigation":12,"path":27,"publishedDate":20,"seo":28,"stem":33,"tagSlugs":34,"__hash__":35},"blogPosts/en-us/blog/journey-through-gits-20-year-history.yml","Journey Through Gits 20 Year History",[7],"patrick-steinhardt",null,"open-source",{"slug":11,"featured":12,"template":13},"journey-through-gits-20-year-history",true,"BlogPost",{"title":15,"description":16,"authors":17,"heroImage":19,"date":20,"body":21,"category":9,"tags":22},"Journey through Git's 20-year history","Follow along as we reminisce about the first commit, the unique aspects of the earliest releases, and the confusion sparked by an update to the git-push(1) default behavior.",[18],"Patrick Steinhardt","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097380/Blog/Hero%20Images/Blog/Hero%20Images/git-20-years-opt2_TWNsNk8KH43b3jP0KLD0U_1750097380123.png","2025-04-14","The Git project has just turned 20 years old. A lot has happened during these years, and while the conceptual design of Git hasn't changed significantly since its inception, the way users interact with the tool has changed quite significantly. We at GitLab are proud to build on top of this critical piece of software and to be part of its history.\n\nJoin us on a journey through Git's history to explore how it has evolved over the years.\n\n## The first commit\n\nThe first commit was made on April 7, 2005, by Linus Torvalds, the creator of the Linux kernel: `e83c5163316 (Initial revision\nof \"git\", the information manager from hell, 2005-04-07)`.\n\nAs we can see, this\ncommit does not contain a lot of files:\n\n```shell\n$ git ls-tree e83c5163316\n100644 blob a6bba79ba1f46a1bbf7773449c3bd2bb9bf48e8b\tMakefile\n100644 blob 27577f76849c09d3405397244eb3d8ae1d11b0f3\tREADME\n100644 blob 98a32a9ad39883c6d05a000a68511d4b1ee2b3c7\tcache.h\n100644 blob 74a0a234dd346fff51c773aa57d82fc4b83a8557\tcat-file.c\n100644 blob 840307af0cfaab31555795ce7175d5e9c9f981a0\tcommit-tree.c\n100644 blob 25dc13fe101b219f74007f3194b787dd99e863da\tinit-db.c\n100644 blob c924a6e0fc4c36bad6f23cb87ee59518c771f936\tread-cache.c\n100644 blob 1b47742d8cbc0d98903777758b7b519980e7499e\tread-tree.c\n100644 blob b8522886a15db861508fb6d03d4d88d6de912a4b\tshow-diff.c\n100644 blob 5085a5cb53ee52e1886ff6d46c609bdb2fc6d6cd\tupdate-cache.c\n100644 blob 921f981353229db0c56103a52609d35aff16f41b\twrite-tree.c\n```\n\nIn addition to build infrastructure, the first commit provides seven top-level commands:\n\n- `init-db` to initialize a new Git repository\n- `update-cache` to add files to the index\n- `write-tree` to take what is in the index and create a new tree from it\n- `read-tree` to read a tree object\n- `commit-tree` to create a commit from a tree\n- `cat-file` to read a specific object into a temporary file\n\nNote that the `git` command itself did not yet exist at this point in time.\nInstead, these commands had to be executed directly.\n\nAs example, let's create a\nnew repository:\n\n```shell\n$ mkdir repo\n$ cd repo\n$ init-db\ndefaulting to private storage area\n$ ls -a\n.  ..  .dircache\n```\n\nThat looks quite unfamiliar: There is no `.git` directory, but there is a\n`.dircache` directory. And where was the private storage area?\n\nThe early design of Git distinguished between a \"shared\" and \"private\" object\nstorage area. This object storage area was where all of your Git objects went. For example, your\ncommits and blobs.\n\nBy default, `init-db` created a private object storage area that was only used for\nthe managed directory that it was created in. A \"shared\" object storage area, on\nthe other hand, shared object content across multiple managed directories so\nthat the same object did not need to be stored twice.\n\n### Create a commit\n\nSo, now that we have a repository, how did we create a commit? Well, it isn't as\neasy as today's `git add . && git commit`. Instead, you had to:\n\n1. Update the index by calling `update-cache` for every file that you want to\n   add.\n1. Write a new tree by calling `write-tree`, which takes everything you have\n   added to the index.\n1. Set up environment variables to tell Git who you are.\n1. Write a commit object by calling `commit-tree`.\n\nLet’s create a commit in the repository:\n\n```shell\n$ echo content-1 >file-a\n$ update-cache file-a\n$ echo content-2 >file-b\n$ update-cache file-b\n$ write-tree\n3f143dfb48f2d84936626e2e5402e1f10c2050fb\n$ export COMMITTER_NAME=\"Patrick Steinhardt\"\n$ export COMMITER_EMAIL=ps@pks.im\n$ echo \"commit message\" | commit-tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nCommitting initial tree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\n5f8e928066c03cebe5fd0a0cc1b93d058155b969\n```\n\nThis isn't exactly ergonomic, but it works! Let's have a look at the generated\ncommit:\n\n```shell\n$ cat-file 5f8e928066c03cebe5fd0a0cc1b93d058155b969\ntemp_git_file_rlTXtE: commit\n$ cat temp_git_file_rlTXtE\ntree 3f143dfb48f2d84936626e2e5402e1f10c2050fb\nauthor Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\ncommitter Patrick Steinhardt \u003Cps@pks.im> Wed Mar 26 13:10:16 2025\n\ncommit message\n```\n\nNote that `cat-file` didn't print the contents directly, but instead wrote\nit into a temporary file first. But the contents of the file looked exactly how a\nmodern commit would look.\n\n### Making changes\n\nNow that we have files, how do we get their status? You might have guessed it:\nthis could be done with `show-diff`:\n\n```shell\n$ show-diff\nfile-a: ok\nfile-b: ok\n\n$ echo modified-content >file-a\n$ show-diff\n--- -\t2025-03-26 13:14:53.457611094 +0100\n+++ file-a\t2025-03-26 13:14:52.230085756 +0100\n@@ -1 +1 @@\n-content-1\n+modified-content\nfile-a:  46d8be14cdec97aac6a769fdbce4db340e888bf8\nfile-b: ok\n```\n\nAmazingly, `show-diff` even knew to already generate diffs between the old and\nnew state of modified files! Funny enough though, Git achieved this by simply\nexecuting the diff(1) Unix tool.\n\nIn summary, all of this was still rather bare-bones, but it performed all of the\nnecessary duties to track history. There were still many limitations:\n\n- There was no easy way yet to switch between commits.\n- There was no way to show logs.\n- There were no branches, tags, or even references. Users were expected to manually\n  keep track of object IDs.\n- There was no way to synchronize two repositories with one another. Instead,\n  users were expected to use rsync(1) to synchronize the `.dircache` directories.\n- There was no way to perform merges.\n\n## Git 0.99\n\nThe first test release of Git was Version 0.99. This release came only two months after\nthe initial commit, but already contained 1,076 commits. There had been almost 50\ndifferent developers involved. The most frequent committer at this point was\nLinus himself, but he was closely followed by Junio Hamano, the current maintainer.\n\nA lot of things had changed since the initial commit:\n\n- Git started to track different development branches by using references, which\n  in most cases removes the need to manually track object IDs.\n- There was a new remote protocol that allows two repositories to exchange\n  objects with one another.\n- The `.dircache` directory was renamed to `.git`.\n- It became possible to merge single files with one another.\n\nThe most important visible change, though, was the introduction of\nthe top-level `git` command and its subcommands. Interestingly, this release\nalso created the notion of \"plumbing\" and \"porcelain\" commands:\n\n- \"Plumbing\" tools are the low-level commands that access the underlying Git\n  repository.\n- \"Porcelain\" tools are shell scripts that wrap the plumbing commands to provide\n  a nicer, high-level user interface.\n\nThis split still exists nowadays as documented in\n[`git(1)`](https://git-scm.com/docs/git#_high_level_commands_porcelain), but because most porcelain tools have been rewritten from shell scripts to C, the line between these two\ncategories has started to blur significantly.\n\n## Linus hands over maintainership\n\nLinus never started Git out of love for version control systems, but because there was a need to replace BitKeeper for Linux kernel development. As such, he never planned to keep maintaining Git forever. The intent was to maintain it until someone trustworthy stepped up.\n\nThat someone was Junio Hamano. Junio got involved in Git about a week after Linus’s first commit and already had a couple of hundred commits in the history after the Git 0.99 release. So, on July 26, 2005, [Linus made Junio the new maintainer of the Git project](https://lore.kernel.org/git/Pine.LNX.4.58.0507262004320.3227@g5.osdl.org/). While Linus has continued to contribute to Git, his involvement with the project faded over time, which is only natural considering that he is quite busy as head of the Linux project.\n\nJunio is still leading the Git project today.\n\n## Git 1.0\n\nThe first major release of Git happened on December 21, 2005, by\nJunio. Interestingly enough, there had been 34 releases between Version 0.99\nand Version 1.0: 0.99.1 to 0.99.7, 0.99.7a to 0.99.7d, 0.99.8 to 0.99.8g, and\n0.99.9 up to 0.99.9n.\n\nOne of the more important milestones since 0.99 was probably the addition of the `git-merge(1)`\ncommand that allows one to merge two trees with one another. This is in stark\ncontrast to before, where one had to basically script the merges file by file.\n\n### Remotes\n\nAnother significant change was the introduction of shorthand notation for\nremote repositories. While Git already knew how to talk to remote repositories,\nusers always had to specify the URL to fetch from every single time they wanted\nto fetch changes from it. This was quite unfriendly to the users, because, typically, they wanted to interact with the same remote over and over again.\n\nYou may know about how remotes work now, but the mechanism that existed at  this point in time was still significantly different. There was no `git-remote(1)`  command that you could use to manage your remotes. Remotes weren't even stored  in your `.git/config` file. In fact, when remotes were first introduced in  Version 0.99.2, Git didn't even *have* config files.\n\nInstead, you had to configure remotes by writing a file into the  `.git/branches` directory, which nowadays feels somewhat counterintuitive. But  the mechanism still works today:\n\n```shell\n$ git init repo --\nInitialized empty Git repository in /tmp/repo/.git/\n$ cd repo\n$ mkdir .git/branches\n$ echo https://gitlab.com/git-scm/git.git >.git/branches/origin\n$ git fetch origin refs/heads/master\n```\n\nBut that isn't all! The directory was soon renamed in Git Version 0.99.5 to \"remotes\", so there are a total of three different ways to configure remotes in a modern Git client.\n\nMost of you have probably never used either `.git/branches` nor `.git/remotes`,  and both of these mechanisms have been deprecated since 2005 and 2011,  respectively. Furthermore, these directories will finally be removed in Git 3.0.\n\n## Git branding\n\nIn 2007, the first Git logo was created. It’s arguable if you can call it a logo, because it only consisted of three red minus signs above three green plus signs, reflecting what the output of `git diff` looks like:\n\n![three red minus signs above three green plus signs, reflecting what the output of `git diff`](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097387927.png)\n\nA bit later, in 2008, the website [git-scm.com](https://git-scm.com) was launched:\n\n![landing page for git-scm.com in 2006](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097387930.png)\n\nIn 2012, the Git website was [revamped](https://lore.kernel.org/git/CAP2yMaJy=1c3b4F72h6jL_454+0ydEQNXYiC6E-ZeQQgE0PcVA@mail.gmail.com/) by Scott Chacon and Jason Long. It looks pretty similar to how it looks today:\n\n![git website revamped in 2012](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097387932.png)\n\nThis site redesign sports the new red-orange logo designed by Jason Long; the same logo that's currently used:\n\n![git logo](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097388/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097387934.png)\n\n## Git 2.0\n\nGit already started to look a lot like modern Git at the 1.0 release, so we\nare going to do a big historical jump to Git 2.0. This version was\nreleased around 10 years after Git 1.0 and was the first release that\nintentionally contained backwards-incompatible changes in central workflows.\n\n### `git-push(1)` default behavior\n\nThe change that arguably caused most the confusion in this release was the\nupdated default behavior of `git-push(1)`.\n\nThere are a couple of different actions that Git could take when you push\ninto a remote repository and don’t specify exactly what you want to push:\n\n- Git could refuse to do anything, asking you to provide more information of\n  what exactly you want to push.\n- Git could push the currently checked out branch.\n- Git could push the currently checked out branch, but only if it knows that it\n  has an equivalent on the remote side.\n- Git could push all of your branches that have an equivalent on the remote side.\n\nThe behavior of modern Git is the so-called \"simple\" strategy, which is the third\noption above. But before Git 2.0, the default behavior was the \"matching\"\nstrategy, which is the last option.\n\nThe “matching” strategy was significantly more risky. You always had to make sure that you\nwere fine with pushing all of your local branches that have an equivalent on the\nremote side before pushing. Otherwise, you might have ended up\npushing changes unintentionally. As such, it was decided to change the strategy\nto \"simple\" to reduce the risk and help out Git beginners.\n\n### `git-add(1)`\n\nAnother big change was the default behavior of `git-add(1)` when it comes to  tracked files that have been deleted. Before Git 2.0, `git-add(1)` wouldn't  stage deleted files automatically, but you instead had to manually add each  deleted file by using `git-rm(1)` to make them part of a commit. With Git 2.0, this behavior was changed so that `git-add(1)` also adds deleted files to the index.\n\n## Celebrating the Git community\n\nI won’t bore you with the details around how Git works nowadays – you probably use it daily anyway, and, if you don’t, there are many tutorials out there that can help you get started. Instead, let’s celebrate the Git community, which has ensured that Git works as well as it does 20 years later.\n\nOver time, Git has:\n\n- Accumulated 56,721 commits as of the Git 2.49 release.\n- Received contributions from more than 2,000 different individuals.\n- Published 60 major releases.\n\nThe Git project also has a steady influx of new contributors by taking part in [Google Summer of Code](https://summerofcode.withgoogle.com/) and [Outreachy](https://www.outreachy.org/). New contributors like these are what will ensure that the Git project will remain healthy in the long term.\n\nAs such, let me extend a big thank you to all contributors. It is your contributions that have made Git possible.\n\n## Going forward\n\nIt should be an uncontroversial take to say that Git has essentially won the competition of version control systems. It has significant market share, and it isn't easy to find open source projects that are using a version control system other than Git. So it has clearly done a lot of things right.\n\nThat being said, its development hasn't stood still, and there are still many challenges ahead of Git. On the one hand, we have technical challenges:\n- modernization of an aging code base  - scaling with the ever-growing size of monorepos  - handling large binary files better\n\nAnd on the other hand, there are problems of a more social type:\n- improving the usability of Git  - fostering the Git community so that the project remains healthy in the long    term\n\nThere always remains work to be done and we at GitLab are proud to be part  of these efforts to make sure that Git continues to be a great version control  system for the next 20 years.\n\n## Read more about Git\n\n- [Celebrating Git's 20th anniversary with creator Linus Torvalds](https://about.gitlab.com/blog/celebrating-gits-20th-anniversary-with-creator-linus-torvalds/)\n- [What's new in Git 2.49.0?](https://about.gitlab.com/blog/whats-new-in-git-2-49-0/)  - [What’s new in Git 2.48.0?](https://about.gitlab.com/blog/whats-new-in-git-2-48-0/)  - [A beginner's guide to the Git reftable format](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/)",[23,24],"open source","git","yml",{},"/en-us/blog/journey-through-gits-20-year-history",{"title":15,"description":16,"ogTitle":15,"ogDescription":16,"noIndex":29,"ogImage":19,"ogUrl":30,"ogSiteName":31,"ogType":32,"canonicalUrls":30},false,"https://about.gitlab.com/blog/journey-through-gits-20-year-history","https://about.gitlab.com","article","en-us/blog/journey-through-gits-20-year-history",[9,24],"RxMYZrqWYreBtF-OG61DopVJoxhHu57j6X1zuARTFZ0",{"data":37},{"logo":38,"freeTrial":43,"sales":48,"login":53,"items":58,"search":366,"minimal":397,"duo":416,"pricingDeployment":426},{"config":39},{"href":40,"dataGaName":41,"dataGaLocation":42},"/","gitlab logo","header",{"text":44,"config":45},"Get free trial",{"href":46,"dataGaName":47,"dataGaLocation":42},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":49,"config":50},"Talk to sales",{"href":51,"dataGaName":52,"dataGaLocation":42},"/sales/","sales",{"text":54,"config":55},"Sign in",{"href":56,"dataGaName":57,"dataGaLocation":42},"https://gitlab.com/users/sign_in/","sign in",[59,86,181,186,287,347],{"text":60,"config":61,"cards":63},"Platform",{"dataNavLevelOne":62},"platform",[64,70,78],{"title":60,"description":65,"link":66},"The intelligent orchestration platform for DevSecOps",{"text":67,"config":68},"Explore our Platform",{"href":69,"dataGaName":62,"dataGaLocation":42},"/platform/",{"title":71,"description":72,"link":73},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":74,"config":75},"Meet GitLab Duo",{"href":76,"dataGaName":77,"dataGaLocation":42},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":79,"description":80,"link":81},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":82,"config":83},"Learn more",{"href":84,"dataGaName":85,"dataGaLocation":42},"/why-gitlab/","why gitlab",{"text":87,"left":12,"config":88,"link":90,"lists":94,"footer":163},"Product",{"dataNavLevelOne":89},"solutions",{"text":91,"config":92},"View all Solutions",{"href":93,"dataGaName":89,"dataGaLocation":42},"/solutions/",[95,119,142],{"title":96,"description":97,"link":98,"items":103},"Automation","CI/CD and automation to accelerate deployment",{"config":99},{"icon":100,"href":101,"dataGaName":102,"dataGaLocation":42},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[104,108,111,115],{"text":105,"config":106},"CI/CD",{"href":107,"dataGaLocation":42,"dataGaName":105},"/solutions/continuous-integration/",{"text":71,"config":109},{"href":76,"dataGaLocation":42,"dataGaName":110},"gitlab duo agent platform - product menu",{"text":112,"config":113},"Source Code Management",{"href":114,"dataGaLocation":42,"dataGaName":112},"/solutions/source-code-management/",{"text":116,"config":117},"Automated Software Delivery",{"href":101,"dataGaLocation":42,"dataGaName":118},"Automated software delivery",{"title":120,"description":121,"link":122,"items":127},"Security","Deliver code faster without compromising security",{"config":123},{"href":124,"dataGaName":125,"dataGaLocation":42,"icon":126},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[128,132,137],{"text":129,"config":130},"Application Security Testing",{"href":124,"dataGaName":131,"dataGaLocation":42},"Application security testing",{"text":133,"config":134},"Software Supply Chain Security",{"href":135,"dataGaLocation":42,"dataGaName":136},"/solutions/supply-chain/","Software supply chain security",{"text":138,"config":139},"Software Compliance",{"href":140,"dataGaName":141,"dataGaLocation":42},"/solutions/software-compliance/","software compliance",{"title":143,"link":144,"items":149},"Measurement",{"config":145},{"icon":146,"href":147,"dataGaName":148,"dataGaLocation":42},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[150,154,158],{"text":151,"config":152},"Visibility & Measurement",{"href":147,"dataGaLocation":42,"dataGaName":153},"Visibility and Measurement",{"text":155,"config":156},"Value Stream Management",{"href":157,"dataGaLocation":42,"dataGaName":155},"/solutions/value-stream-management/",{"text":159,"config":160},"Analytics & Insights",{"href":161,"dataGaLocation":42,"dataGaName":162},"/solutions/analytics-and-insights/","Analytics and insights",{"title":164,"items":165},"GitLab for",[166,171,176],{"text":167,"config":168},"Enterprise",{"href":169,"dataGaLocation":42,"dataGaName":170},"/enterprise/","enterprise",{"text":172,"config":173},"Small Business",{"href":174,"dataGaLocation":42,"dataGaName":175},"/small-business/","small business",{"text":177,"config":178},"Public Sector",{"href":179,"dataGaLocation":42,"dataGaName":180},"/solutions/public-sector/","public sector",{"text":182,"config":183},"Pricing",{"href":184,"dataGaName":185,"dataGaLocation":42,"dataNavLevelOne":185},"/pricing/","pricing",{"text":187,"config":188,"link":190,"lists":194,"feature":274},"Resources",{"dataNavLevelOne":189},"resources",{"text":191,"config":192},"View all resources",{"href":193,"dataGaName":189,"dataGaLocation":42},"/resources/",[195,228,246],{"title":196,"items":197},"Getting started",[198,203,208,213,218,223],{"text":199,"config":200},"Install",{"href":201,"dataGaName":202,"dataGaLocation":42},"/install/","install",{"text":204,"config":205},"Quick start guides",{"href":206,"dataGaName":207,"dataGaLocation":42},"/get-started/","quick setup checklists",{"text":209,"config":210},"Learn",{"href":211,"dataGaLocation":42,"dataGaName":212},"https://university.gitlab.com/","learn",{"text":214,"config":215},"Product documentation",{"href":216,"dataGaName":217,"dataGaLocation":42},"https://docs.gitlab.com/","product documentation",{"text":219,"config":220},"Best practice videos",{"href":221,"dataGaName":222,"dataGaLocation":42},"/getting-started-videos/","best practice videos",{"text":224,"config":225},"Integrations",{"href":226,"dataGaName":227,"dataGaLocation":42},"/integrations/","integrations",{"title":229,"items":230},"Discover",[231,236,241],{"text":232,"config":233},"Customer success stories",{"href":234,"dataGaName":235,"dataGaLocation":42},"/customers/","customer success stories",{"text":237,"config":238},"Blog",{"href":239,"dataGaName":240,"dataGaLocation":42},"/blog/","blog",{"text":242,"config":243},"Remote",{"href":244,"dataGaName":245,"dataGaLocation":42},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":247,"items":248},"Connect",[249,254,259,264,269],{"text":250,"config":251},"GitLab Services",{"href":252,"dataGaName":253,"dataGaLocation":42},"/services/","services",{"text":255,"config":256},"Community",{"href":257,"dataGaName":258,"dataGaLocation":42},"/community/","community",{"text":260,"config":261},"Forum",{"href":262,"dataGaName":263,"dataGaLocation":42},"https://forum.gitlab.com/","forum",{"text":265,"config":266},"Events",{"href":267,"dataGaName":268,"dataGaLocation":42},"/events/","events",{"text":270,"config":271},"Partners",{"href":272,"dataGaName":273,"dataGaLocation":42},"/partners/","partners",{"backgroundColor":275,"textColor":276,"text":277,"image":278,"link":282},"#2f2a6b","#fff","Insights for the future of software development",{"altText":279,"config":280},"the source promo card",{"src":281},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":283,"config":284},"Read the latest",{"href":285,"dataGaName":286,"dataGaLocation":42},"/the-source/","the source",{"text":288,"config":289,"lists":291},"Company",{"dataNavLevelOne":290},"company",[292],{"items":293},[294,299,305,307,312,317,322,327,332,337,342],{"text":295,"config":296},"About",{"href":297,"dataGaName":298,"dataGaLocation":42},"/company/","about",{"text":300,"config":301,"footerGa":304},"Jobs",{"href":302,"dataGaName":303,"dataGaLocation":42},"/jobs/","jobs",{"dataGaName":303},{"text":265,"config":306},{"href":267,"dataGaName":268,"dataGaLocation":42},{"text":308,"config":309},"Leadership",{"href":310,"dataGaName":311,"dataGaLocation":42},"/company/team/e-group/","leadership",{"text":313,"config":314},"Team",{"href":315,"dataGaName":316,"dataGaLocation":42},"/company/team/","team",{"text":318,"config":319},"Handbook",{"href":320,"dataGaName":321,"dataGaLocation":42},"https://handbook.gitlab.com/","handbook",{"text":323,"config":324},"Investor relations",{"href":325,"dataGaName":326,"dataGaLocation":42},"https://ir.gitlab.com/","investor relations",{"text":328,"config":329},"Trust Center",{"href":330,"dataGaName":331,"dataGaLocation":42},"/security/","trust center",{"text":333,"config":334},"AI Transparency Center",{"href":335,"dataGaName":336,"dataGaLocation":42},"/ai-transparency-center/","ai transparency center",{"text":338,"config":339},"Newsletter",{"href":340,"dataGaName":341,"dataGaLocation":42},"/company/contact/#contact-forms","newsletter",{"text":343,"config":344},"Press",{"href":345,"dataGaName":346,"dataGaLocation":42},"/press/","press",{"text":348,"config":349,"lists":350},"Contact us",{"dataNavLevelOne":290},[351],{"items":352},[353,356,361],{"text":49,"config":354},{"href":51,"dataGaName":355,"dataGaLocation":42},"talk to sales",{"text":357,"config":358},"Support portal",{"href":359,"dataGaName":360,"dataGaLocation":42},"https://support.gitlab.com","support portal",{"text":362,"config":363},"Customer portal",{"href":364,"dataGaName":365,"dataGaLocation":42},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":367,"login":368,"suggestions":375},"Close",{"text":369,"link":370},"To search repositories and projects, login to",{"text":371,"config":372},"gitlab.com",{"href":56,"dataGaName":373,"dataGaLocation":374},"search login","search",{"text":376,"default":377},"Suggestions",[378,380,384,386,390,394],{"text":71,"config":379},{"href":76,"dataGaName":71,"dataGaLocation":374},{"text":381,"config":382},"Code Suggestions (AI)",{"href":383,"dataGaName":381,"dataGaLocation":374},"/solutions/code-suggestions/",{"text":105,"config":385},{"href":107,"dataGaName":105,"dataGaLocation":374},{"text":387,"config":388},"GitLab on AWS",{"href":389,"dataGaName":387,"dataGaLocation":374},"/partners/technology-partners/aws/",{"text":391,"config":392},"GitLab on Google Cloud",{"href":393,"dataGaName":391,"dataGaLocation":374},"/partners/technology-partners/google-cloud-platform/",{"text":395,"config":396},"Why GitLab?",{"href":84,"dataGaName":395,"dataGaLocation":374},{"freeTrial":398,"mobileIcon":403,"desktopIcon":408,"secondaryButton":411},{"text":399,"config":400},"Start free trial",{"href":401,"dataGaName":47,"dataGaLocation":402},"https://gitlab.com/-/trials/new/","nav",{"altText":404,"config":405},"Gitlab Icon",{"src":406,"dataGaName":407,"dataGaLocation":402},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":404,"config":409},{"src":410,"dataGaName":407,"dataGaLocation":402},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":412,"config":413},"Get Started",{"href":414,"dataGaName":415,"dataGaLocation":402},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":417,"mobileIcon":422,"desktopIcon":424},{"text":418,"config":419},"Learn more about GitLab Duo",{"href":420,"dataGaName":421,"dataGaLocation":402},"/gitlab-duo/","gitlab duo",{"altText":404,"config":423},{"src":406,"dataGaName":407,"dataGaLocation":402},{"altText":404,"config":425},{"src":410,"dataGaName":407,"dataGaLocation":402},{"freeTrial":427,"mobileIcon":432,"desktopIcon":434},{"text":428,"config":429},"Back to pricing",{"href":184,"dataGaName":430,"dataGaLocation":402,"icon":431},"back to pricing","GoBack",{"altText":404,"config":433},{"src":406,"dataGaName":407,"dataGaLocation":402},{"altText":404,"config":435},{"src":410,"dataGaName":407,"dataGaLocation":402},{"title":437,"button":438,"config":443},"See how agentic AI transforms software delivery",{"text":439,"config":440},"Watch GitLab Transcend now",{"href":441,"dataGaName":442,"dataGaLocation":42},"/events/transcend/virtual/","transcend event",{"layout":444,"icon":445},"release","AiStar",{"data":447},{"text":448,"source":449,"edit":455,"contribute":460,"config":465,"items":470,"minimal":677},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":450,"config":451},"View page source",{"href":452,"dataGaName":453,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":456,"config":457},"Edit this page",{"href":458,"dataGaName":459,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":461,"config":462},"Please contribute",{"href":463,"dataGaName":464,"dataGaLocation":454},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":466,"facebook":467,"youtube":468,"linkedin":469},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[471,518,572,616,643],{"title":182,"links":472,"subMenu":487},[473,477,482],{"text":474,"config":475},"View plans",{"href":184,"dataGaName":476,"dataGaLocation":454},"view plans",{"text":478,"config":479},"Why Premium?",{"href":480,"dataGaName":481,"dataGaLocation":454},"/pricing/premium/","why premium",{"text":483,"config":484},"Why Ultimate?",{"href":485,"dataGaName":486,"dataGaLocation":454},"/pricing/ultimate/","why ultimate",[488],{"title":489,"links":490},"Contact Us",[491,494,496,498,503,508,513],{"text":492,"config":493},"Contact sales",{"href":51,"dataGaName":52,"dataGaLocation":454},{"text":357,"config":495},{"href":359,"dataGaName":360,"dataGaLocation":454},{"text":362,"config":497},{"href":364,"dataGaName":365,"dataGaLocation":454},{"text":499,"config":500},"Status",{"href":501,"dataGaName":502,"dataGaLocation":454},"https://status.gitlab.com/","status",{"text":504,"config":505},"Terms of use",{"href":506,"dataGaName":507,"dataGaLocation":454},"/terms/","terms of use",{"text":509,"config":510},"Privacy statement",{"href":511,"dataGaName":512,"dataGaLocation":454},"/privacy/","privacy statement",{"text":514,"config":515},"Cookie preferences",{"dataGaName":516,"dataGaLocation":454,"id":517,"isOneTrustButton":12},"cookie preferences","ot-sdk-btn",{"title":87,"links":519,"subMenu":528},[520,524],{"text":521,"config":522},"DevSecOps platform",{"href":69,"dataGaName":523,"dataGaLocation":454},"devsecops platform",{"text":525,"config":526},"AI-Assisted Development",{"href":420,"dataGaName":527,"dataGaLocation":454},"ai-assisted development",[529],{"title":530,"links":531},"Topics",[532,537,542,547,552,557,562,567],{"text":533,"config":534},"CICD",{"href":535,"dataGaName":536,"dataGaLocation":454},"/topics/ci-cd/","cicd",{"text":538,"config":539},"GitOps",{"href":540,"dataGaName":541,"dataGaLocation":454},"/topics/gitops/","gitops",{"text":543,"config":544},"DevOps",{"href":545,"dataGaName":546,"dataGaLocation":454},"/topics/devops/","devops",{"text":548,"config":549},"Version Control",{"href":550,"dataGaName":551,"dataGaLocation":454},"/topics/version-control/","version control",{"text":553,"config":554},"DevSecOps",{"href":555,"dataGaName":556,"dataGaLocation":454},"/topics/devsecops/","devsecops",{"text":558,"config":559},"Cloud Native",{"href":560,"dataGaName":561,"dataGaLocation":454},"/topics/cloud-native/","cloud native",{"text":563,"config":564},"AI for Coding",{"href":565,"dataGaName":566,"dataGaLocation":454},"/topics/devops/ai-for-coding/","ai for coding",{"text":568,"config":569},"Agentic AI",{"href":570,"dataGaName":571,"dataGaLocation":454},"/topics/agentic-ai/","agentic ai",{"title":573,"links":574},"Solutions",[575,577,579,584,588,591,595,598,600,603,606,611],{"text":129,"config":576},{"href":124,"dataGaName":129,"dataGaLocation":454},{"text":118,"config":578},{"href":101,"dataGaName":102,"dataGaLocation":454},{"text":580,"config":581},"Agile development",{"href":582,"dataGaName":583,"dataGaLocation":454},"/solutions/agile-delivery/","agile delivery",{"text":585,"config":586},"SCM",{"href":114,"dataGaName":587,"dataGaLocation":454},"source code management",{"text":533,"config":589},{"href":107,"dataGaName":590,"dataGaLocation":454},"continuous integration & delivery",{"text":592,"config":593},"Value stream management",{"href":157,"dataGaName":594,"dataGaLocation":454},"value stream management",{"text":538,"config":596},{"href":597,"dataGaName":541,"dataGaLocation":454},"/solutions/gitops/",{"text":167,"config":599},{"href":169,"dataGaName":170,"dataGaLocation":454},{"text":601,"config":602},"Small business",{"href":174,"dataGaName":175,"dataGaLocation":454},{"text":604,"config":605},"Public sector",{"href":179,"dataGaName":180,"dataGaLocation":454},{"text":607,"config":608},"Education",{"href":609,"dataGaName":610,"dataGaLocation":454},"/solutions/education/","education",{"text":612,"config":613},"Financial services",{"href":614,"dataGaName":615,"dataGaLocation":454},"/solutions/finance/","financial services",{"title":187,"links":617},[618,620,622,624,627,629,631,633,635,637,639,641],{"text":199,"config":619},{"href":201,"dataGaName":202,"dataGaLocation":454},{"text":204,"config":621},{"href":206,"dataGaName":207,"dataGaLocation":454},{"text":209,"config":623},{"href":211,"dataGaName":212,"dataGaLocation":454},{"text":214,"config":625},{"href":216,"dataGaName":626,"dataGaLocation":454},"docs",{"text":237,"config":628},{"href":239,"dataGaName":240,"dataGaLocation":454},{"text":232,"config":630},{"href":234,"dataGaName":235,"dataGaLocation":454},{"text":242,"config":632},{"href":244,"dataGaName":245,"dataGaLocation":454},{"text":250,"config":634},{"href":252,"dataGaName":253,"dataGaLocation":454},{"text":255,"config":636},{"href":257,"dataGaName":258,"dataGaLocation":454},{"text":260,"config":638},{"href":262,"dataGaName":263,"dataGaLocation":454},{"text":265,"config":640},{"href":267,"dataGaName":268,"dataGaLocation":454},{"text":270,"config":642},{"href":272,"dataGaName":273,"dataGaLocation":454},{"title":288,"links":644},[645,647,649,651,653,655,657,661,666,668,670,672],{"text":295,"config":646},{"href":297,"dataGaName":290,"dataGaLocation":454},{"text":300,"config":648},{"href":302,"dataGaName":303,"dataGaLocation":454},{"text":308,"config":650},{"href":310,"dataGaName":311,"dataGaLocation":454},{"text":313,"config":652},{"href":315,"dataGaName":316,"dataGaLocation":454},{"text":318,"config":654},{"href":320,"dataGaName":321,"dataGaLocation":454},{"text":323,"config":656},{"href":325,"dataGaName":326,"dataGaLocation":454},{"text":658,"config":659},"Sustainability",{"href":660,"dataGaName":658,"dataGaLocation":454},"/sustainability/",{"text":662,"config":663},"Diversity, inclusion and belonging (DIB)",{"href":664,"dataGaName":665,"dataGaLocation":454},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":328,"config":667},{"href":330,"dataGaName":331,"dataGaLocation":454},{"text":338,"config":669},{"href":340,"dataGaName":341,"dataGaLocation":454},{"text":343,"config":671},{"href":345,"dataGaName":346,"dataGaLocation":454},{"text":673,"config":674},"Modern Slavery Transparency Statement",{"href":675,"dataGaName":676,"dataGaLocation":454},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":678},[679,682,685],{"text":680,"config":681},"Terms",{"href":506,"dataGaName":507,"dataGaLocation":454},{"text":683,"config":684},"Cookies",{"dataGaName":516,"dataGaLocation":454,"id":517,"isOneTrustButton":12},{"text":686,"config":687},"Privacy",{"href":511,"dataGaName":512,"dataGaLocation":454},[689],{"id":690,"title":18,"body":8,"config":691,"content":693,"description":8,"extension":25,"meta":697,"navigation":12,"path":698,"seo":699,"stem":700,"__hash__":701},"blogAuthors/en-us/blog/authors/patrick-steinhardt.yml",{"template":692},"BlogAuthor",{"name":18,"config":694},{"headshot":695,"ctfId":696},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749661952/Blog/Author%20Headshots/pks-gitlab-headshot.png","pksgitlab",{},"/en-us/blog/authors/patrick-steinhardt",{},"en-us/blog/authors/patrick-steinhardt","SV9Yd_vW69UbvntDP-SEOV9NKT_VwUAj5nfftf2ElSw",[703,715,727],{"content":704,"config":713},{"title":705,"description":706,"authors":707,"date":709,"body":710,"heroImage":711,"category":9,"tags":712},"What’s new in Git 2.53.0?","Learn about release contributions, including fixes for geometric repacking, updates to git-fast-import(1) commit signature handing options, and more.",[708],"Justin Tobler","2026-02-02","The Git project recently released [Git 2.53.0](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u). Let's look at a few notable highlights from this release, which includes\ncontributions from the Git team at GitLab.\n\n## Geometric repacking support with promisor remotes\n\nNewly written objects in a Git repository are often stored as individual loose files. To ensure good performance and optimal use of disk space, these loose objects are regularly compressed into so-called packfiles. The number of packfiles in a repository grows over time as a result of the user’s activities, like writing new commits or fetching from a remote. As the number of packfiles in a repository increases, Git has to do more work to look up individual objects. Therefore, to preserve optimal repository performance, packfiles are periodically repacked via git-repack(1) to consolidate the objects into fewer packfiles. When repacking there are two strategies: “all-into-one” and “geometric”.\n\nThe all-into-one strategy is fairly straightforward and the current default. As its name implies, all objects in the repository are packed into a single packfile. From a performance perspective this is great for the repository as Git only has to scan through a single packfile when looking up objects. The main downside of such a repacking strategy is that computing a single packfile for a repository can take a significant amount of time for large repositories.\n\nThe geometric strategy helps mitigate this concern by maintaining a geometric progression of packfiles based on their size instead of always repacking into a single packfile. To explain more plainly, when repacking Git maintains a set of packfiles ordered by size where each packfile in the sequence is expected to be at least twice the size of the preceding packfile. If a packfile in the sequence violates this property, packfiles are combined as needed until the progression is restored. This strategy has the advantage of still minimizing the number of packfiles in a repository while also minimizing the amount of work that must be done for most repacking operations.\n\nOne problem with the geometric repacking strategy was that it was not compatible with partial clones. Partial clones allow the user to clone only parts of a repository by, for example, skipping all blobs larger than 1 megabyte. This can significantly reduce the size of a repository, and Git knows how to backfill missing objects that it needs to access at a later point in time.\n\nThe result is a repository that is missing some objects, and any object that may not be fully connected is stored in a “promisor” packfile.  When repacking, this promisor property needs to be retained going forward for packfiles containing a promisor object so it is known whether a missing object is expected and can be backfilled from the promisor remote. With an all-into-one repack, Git knows how to handle promisor objects properly and stores them in a separate promisor packfile. Unfortunately, the geometric repacking strategy did not know to give special treatment to promisor packfiles and instead would merge them with normal packfiles without considering whether they reference promisor objects. Luckily, due to a bug the underlying git-pack-objects(1) dies when using geometric repacking in a partial clone repository. So this means repositories in this configuration were not able to be repacked anyways which isn’t great, but better than repository corruption.\n\nWith the release of Git 2.53, geometric repacking now works with partial clone repositories. When performing a geometric repack, promisor packfiles are handled separately in order to preserve the promisor marker and repacked following a separate geometric progression. With this fix, the geometric strategy moves closer towards becoming the default repacking strategy. For more information check out the corresponding [mailing list thread](https://lore.kernel.org/git/20260105-pks-geometric-repack-with-promisors-v1-0-c4660573437e@pks.im/).\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n## git-fast-import(1) learned to preserve only valid signatures\n\nIn our [Git 2.52 release article](https://about.gitlab.com/blog/whats-new-in-git-2-52-0/), we covered signature related improvements to git-fast-import(1) and git-fast-export(1). Be sure to check out that post for a more detailed explanation of these commands, how they are used, and the changes being made with regards to signatures.\n\nTo quickly recap, git-fast-import(1) provides a backend to efficiently import data into a repository and is used by tools such as [git-filter-repo(1)](https://github.com/newren/git-filter-repo) to help rewrite the history of a repository in bulk. In the Git 2.52 release, git-fast-import(1) learned the `--signed-commits=\u003Cmode>` option similar to the same option in git-fast-export(1). With this option, it became possible to unconditionally retain or strip signatures from commits/tags.\n\nIn situations where only part of the repository history has been rewritten, any signature for rewritten commits/tags becomes invalid. This means git-fast-import(1) is limited to either stripping all signatures or keeping all signatures even if they have become invalid. But retaining invalid signatures doesn’t make much sense, so rewriting history with git-repo-filter(1) results in all signatures being stripped, even if the underlying commit/tag is not rewritten. This is unfortunate because if the commit/tag is unchanged, its signature is still valid and thus there is no real reason to strip it. What is really needed is a means to preserve signatures for unchanged objects, but strip invalid ones.\n\nWith the release of Git 2.53, the git-fast-import(1) `--signed-commits=\u003Cmode>` option has learned a new `strip-if-invalid` mode which, when specified, only strips signatures from commits that become invalid due to being rewritten. Thus, with this option it becomes possible to preserve some commit signatures when using git-fast-import(1). This is a critical step towards providing the foundation for tools like git-repo-filter(1) to preserve valid signatures and eventually re-sign invalid signatures.\n\nThis project was led by [Christian Couder](https://gitlab.com/chriscool).\n\n## More data collected in git-repo-structure\n\nIn the Git 2.52 release, the “structure” subcommand was introduced to git-repo(1). The intent of this command was to collect information about the repository and eventually become a native replacement for tools such as [git-sizer(1)](https://github.com/github/git-sizer). At GitLab, we host some extremely large repositories, and having insight into the general structure of a repository is critical to understand its performance characteristics. In this release, the command now also collects total size information for reachable objects in a repository to help understand the overall size of the repository. In the output below, you can see the command now collects both the total inflated and disk sizes of reachable objects by object type.\n\n```shell\n$ git repo structure\n\n| Repository structure | Value      |\n| -------------------- | ---------- |\n| * References         |            |\n|   * Count            |   1.78 k   |\n|     * Branches       |      5     |\n|     * Tags           |   1.03 k   |\n|     * Remotes        |    749     |\n|     * Others         |      0     |\n|                      |            |\n| * Reachable objects  |            |\n|   * Count            | 421.37 k   |\n|     * Commits        |  88.03 k   |\n|     * Trees          | 169.95 k   |\n|     * Blobs          | 162.40 k   |\n|     * Tags           |    994     |\n|   * Inflated size    |   7.61 GiB |\n|     * Commits        |  60.95 MiB |\n|     * Trees          |   2.44 GiB |\n|     * Blobs          |   5.11 GiB |\n|     * Tags           | 731.73 KiB |\n|   * Disk size        | 301.50 MiB |\n|     * Commits        |  33.57 MiB |\n|     * Trees          |  77.92 MiB |\n|     * Blobs          | 189.44 MiB |\n|     * Tags           | 578.13 KiB |\n```\n\nThe keen-eyed among you may have also noticed that the size values in the table output are also now listed in a more human-friendly manner with units appended. In subsequent releases we hope to further expand this command's output to provide additional data points such as the largest individual objects in the repository.\n\nThis project was led by [Justin Tobler](https://gitlab.com/justintobler).\n\n## Read more\n\nThis article highlighted just a few of the contributions made by GitLab and\nthe wider Git community for this latest release. You can learn about these from\nthe [official release announcement](https://lore.kernel.org/git/xmqq4inz13e3.fsf@gitster.g/T/#u) of the Git project. Also, check\nout our [previous Git release blog posts](https://about.gitlab.com/blog/tags/git/)\nto see other past highlights of contributions from GitLab team members.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663087/Blog/Hero%20Images/git3-cover.png",[23,24,258],{"featured":12,"template":13,"slug":714},"whats-new-in-git-2-53-0",{"content":716,"config":725},{"title":717,"description":718,"authors":719,"heroImage":711,"date":722,"body":723,"category":9,"tags":724},"What’s new in Git 2.52.0?","Learn about release contributions, including the new git-last-modified(1) command, improvements to history-rewriting tools, and a new maintenance strategy.",[720,721,18],"Christian Couder","Toon Claes","2025-11-17","The Git project recently released [Git 2.52](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/). After a relatively short 8-week [release cycle for 2.51](https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/), due to summer in the Northern Hemisphere, this release is back to the usual 12-week cycle. Let’s look at some notable changes, including contributions from the GitLab Git team and the wider Git community.\n\n## New git-last-modified(1) command\n\nMany Git forges like GitLab display files in a tree view like this:\n\n\n| Name        | Last commit                                             | Last update  |\n| ------------- | --------------------------------------------------------- | -------------- |\n| README.md   | README: *.txt -> *.adoc fixes                           | 4 months ago |\n| RelNotes    | Start 2.51 cycle, the first batch                       | 4 weeks ago  |\n| SECURITY.md | SECURITY: describe how to report vulnerabilities        | 4 years      |\n| abspath.c   | abspath: move related functions to abspath              | 2 years      |\n| abspath.h   | abspath: move related functions to abspath              | 2 years      |\n| aclocal.m4  | configure: use AC_LANG_PROGRAM consistently             | 15 years ago |\n| add-patch.c | pager: stop using `the_repository`                      | 7 months ago |\n| advice.c    | advice: allow disabling default branch name advice      | 4 months ago |\n| advice.h    | advice: allow disabling default branch name advice      | 4 months ago |\n| alias.h     | rebase -m: fix serialization of strategy options        | 2 years      |\n| alloc.h     | git-compat-util: move alloc macros to git-compat-util.h | 2 years ago  |\n| apply.c     | apply: only write intents to add for new files          | 8 days ago   |\n| archive.c   | Merge branch 'ps/parse-options-integers'                | 3 months ago |\n| archive.h   | archive.h: remove unnecessary include                   | 1 year       |\n| attr.h      | fuzz: port fuzz-parse-attr-line from OSS-Fuzz           | 9 months ago |\n| banned.h    | banned.h: mark `strtok()` and `strtok_r()` as banned    | 2 years      |\n\n\n\u003Cbr>\u003C/br>\n\nNext to the files themselves, we also display which commit last modified each respective file. This information is easy to extract from Git by executing the following command:\n\n\n```shell\n\n$ git log --max-count=1 HEAD -- \u003Cfilename>\n\n```\n\nWhile nice and simple, this has a significant catch: Git does not have a way to extract this information for each of these files in a single command. So to get the last commit for all the files in the tree, we'd need to run this command for each file separately. This results in a command pipeline similar to the following:\n\n```shell\n\n$ git ls-tree HEAD --name-only | xargs --max-args=1 git log --max-count=1 HEAD --\n\n```\n\nNaturally, this isn't very efficient:\n\n\n* We need to spin up a fresh Git command for each file.\n\n\n* Git has to step through history for each file separately.\n\n\n\nAs a consequence, this whole operation is quite costly and generates significant load for GitLab.\n\n\n\nTo overcome these issues, a new Git subcommand `git-last-modified(1)` has been introduced. This command returns the commit for each file of a given commit:\n\n\n\n```shell\n\n$ git last-modified HEAD\n\n\ne56f6dcd7b4c90192018e848d0810f091d092913        add-patch.c\n373ad8917beb99dc643b6e7f5c117a294384a57e        advice.h\ne9330ae4b820147c98e723399e9438c8bee60a80        advice.c\n5e2feb5ca692c5c4d39b11e1ffa056911dd7dfd3        alloc.h\n954d33a9757fcfab723a824116902f1eb16e05f7        RelNotes\n4ce0caa7cc27d50ee1bedf1dff03f13be4c54c1f        apply.c\n5d215a7b3eb0a9a69c0cb9aa43dcae956a0aa03e        archive.c\nc50fbb2dd225e7e82abba4380423ae105089f4d7        README.md\n72686d4e5e9a7236b9716368d86fae5bf1ae6156        attr.h\nc2c4138c07ca4d5ffc41ace0bfda0f189d3e262e        archive.h\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.c\n5d1344b4973c8ea4904005f3bb51a47334ebb370        abspath.h\n60ff56f50372c1498718938ef504e744fe011ffb        banned.h\n4960e5c7bdd399e791353bc6c551f09298746f61        alias.h\n2e99b1e383d2da56c81d7ab7dd849e9dab5b7bf0        SECURITY.md\n1e58dba142c673c59fbb9d10aeecf62217d4fc9c        aclocal.m4\n```\n\n\n\nThe benefit of this is obviously that we only have to execute a single Git process now to derive all of that information. But even more importantly, it only requires us to walk the history once for all files together instead of having to walk it multiple times. This is achieved by:\n\n\n1. Start walking the history from the specified commit.\n\n\n2. For each commit:\n   1. If it doesn't modify any of the paths we're interested in we continue to the next commit.\n   2. If it does, we print the commit ID together with the path. Furthermore, we remove the path from the set of interesting paths.\n3. When the list of interesting paths becomes empty we stop.\n\n\n\nGitaly has already been adjusted to use the new command, but the logic is still guarded by a feature flag. Preliminary testing has shown that `git-last-modified(1)` is in most situations at least twice as fast compared to using `git log --max-count=1`.\n\n\n\n*These changes were [originally written](https://github.com/ttaylorr/git/tree/tb/blame-tree) by multiple developers from GitHub and were [upstreamed](https://lore.kernel.org/git/20250805093358.1791633-1-toon@iotcl.com/) into Git by [Toon Claes](https://gitlab.com/toon).*\n\n\n\n## git-fast-export(1) and git-fast-import(1) signature-related improvements\n\n\n\nThe `git-fast-export(1)` and `git-fast-import(1)` commands are designed to be mostly used by interoperability or history rewriting tools. The goal of interoperability tools is to make Git interact nicely with other software, usually a different version control system, that stores data in a different format than Git. For example [hg-fast-export.sh](https://github.com/frej/fast-export) is a “Mercurial to Git converter using git-fast-import.\"\n\n\n\nAlternately, history-rewriting tools let users — usually admins — make changes to the history of their repositories that are not possible or not allowed by the version control system. For example, [reposurgeon](http://www.catb.org/esr/reposurgeon/) says in its [introduction](https://gitlab.com/esr/reposurgeon/-/blob/master/repository-editing.adoc?ref_type=heads#introduction) that its purpose is “to enable risky operations that version-control systems don't want to let you do, such as (a) editing past comments and metadata, (b) excising commits, (c) coalescing and splitting commits, (d) removing files and subtrees from repo history, (e) merging or grafting two or more repos, and (f) cutting a repo in two by cutting a parent-child link, preserving the branch structure of both child repos.\"\n\n\n\nWithin GitLab, we use [git-filter-repo](https://github.com/newren/git-filter-repo) to let admins perform some risky operations on their Git repositories. Unfortunately, until Git 2.50 (released last June), both `git-fast-export(1)` and `git-fast-import(1)` didn't handle cryptographic commit signatures at all. So, although `git-fast-export(1)` had a `--signed-tags=\u003Cmode>` option that allows users to change how cryptographic tag signatures are handled, commit signatures were simply ignored.\n\n\n\nCryptographic signatures are very fragile because they are based on the exact commit or tag data that was signed. When the signed data or any of its preceding history changes, the cryptographic signature becomes invalid. This is a fragile but necessary requirement to make these signatures useful.\n\n\n\nBut in the context of rewriting history this is a problem:\n\n\n\n* We may want to keep cryptographic signatures for both commits and tags that are still valid after the rewrite (e.g. because the history leading up to them did not change).\n\n\n* We may want to create new cryptographic signatures for commits and tags where the previous signature has become invalid.\n\n\n\nNeither `git-fast-import(1)` nor `git-fast-export(1)` allow for these use cases though, which limits what tools like [git-filter-repo](https://github.com/newren/git-filter-repo) or [reposurgeon](http://www.catb.org/esr/reposurgeon/) can achieve.\n\n\n\nWe have made some significant progress:\n\n\n\n* In Git 2.50 we added a `--signed-commits=\u003Cmode>` option to `git-fast-export(1)` for exporting commit signatures, and support in `git-fast-import(1)` for importing them.\n\n\n* In Git 2.51 we improved the format used for exporting and importing commit signatures, and we made it possible for `git-fast-import(1)` to import both a signature made on the SHA-1 object ID of the commit and one made on its SHA-256 object ID.\n\n\n* In Git 2.52 we added the `--signed-commits=\u003Cmode>` and `--signed-tags=\u003Cmode>` options to `git-fast-import(1)`, so the user has control over how to handle signed data at import time.\n\n\n\nThere is still more to be done. We need to add the ability to:\n\n\n\n* Retain only those commit signatures that are still valid to `git-fast-import(1)`.\n\n\n* Re-sign data where the signature became invalid.\n\n\n\nWe have already started to work on these next steps and expect this to land in Git 2.53. Once done, tools like `git-filter-repo(1)` will finally start to handle cryptographic signatures more gracefully. We will keep you posted in our next Git release blog post.\n\n\n\n*This project was led by [Christian Couder](https://gitlab.com/chriscool).*\n\n\n\n## New and improved git-maintenance(1) strategies\n\n\n\nGit repositories require regular maintenance to ensure that they perform well. This maintenance performs a bunch of different tasks: references get optimized, objects get compressed, and stale data gets pruned.\n\n\n\nUntil Git 2.28, these maintenance tasks were performed by `git-gc(1)`. The problem with this command is that it wasn't built with customizability in mind: While certain parameters can be configured, it is not possible to control which parts of a repository should be optimized. This means that it may not be a good fit for all use cases. Even more importantly, it made it very hard to iterate on how exactly Git performs repository maintenance.\n\n\n\nTo fix this issue and allow us to iterate again, [Derrick Stolee](https://github.com/derrickstolee) introduced `git-maintenance(1)`. In contrast to `git-gc(1),` it is built with customizability in mind and allows the user to configure which tasks specifically should be running in a certain repository. This new tool was made the default for Git’s automated maintenance in Git 2.29, but, by default, it still uses `git-gc(1)` to perform the maintenance.\n\n\n\nWhile this default maintenance strategy works well in small or even medium-sized repositories, it is problematic in the context of large monorepos. The biggest limiting factor is how `git-gc(1)` repacks objects: Whenever there are more than 50 packfiles, the tool will merge all of them together into a single packfile. This operation is quite CPU-intensive and causes a lot of I/O operations, so for large monorepos this operation can easily take many minutes or even hours to complete.\n\n\n\nGit already knows how to minimize these repacks via “geometric repacking.” The idea is simple: The packfiles that exist in the repository must follow a geometric progression where every packfile must contain at least twice as many objects as the next smaller one. This allows Git to amortize the number of repacks required while still ensuring that there is only a relatively small number of packfiles overall. This mode was introduced by [Taylor Blau](https://github.com/ttaylorr) in Git 2.32, but it was not wired up as part of the automated maintenance.\n\n\n\nAll the parts exist to make repository maintenance way more scalable for large monorepos: We have the flexible `git-maintenance(1)` tool that can be extended to have a new maintenance strategy, and we have a better way to repack objects. All that needs to be done is to combine these two.\n\n\n\nAnd that's exactly what we did with Git 2.52! We have introduced a new “geometric” maintenance strategy that you can configure in your Git repositories. This strategy is intended as a full replacement for the old strategy based on `git-gc(1)`. Here is the config code you need:\n\n\n\n```shell\n\n$ git config set maintenance.strategy geometric\n\n```\n\n\n\nFrom hereon, Git will use geometric repacking to optimize your objects. This should lead to less churn while ensuring that your objects are in a better-optimized state, especially in large monorepos.\n\n\n\nIn Git 2.53, we aim to make this the default strategy. So stay tuned!\n\n\n\n*This project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).*\n\n\n\n## New subcommand for git-repo(1) to display repository metrics\n\n\n\nPerformance of Git operations in a repository are often dependent on certain characteristics of its underlying structure. At GitLab, we host some extremely large repositories and having insight into the general structure of a repository is critical to understand performance. While it is possible to compose various Git commands and other tools together to surface certain repository metrics, Git lacks a means to surface info about a repository's shape/structure via a single command. This has led to the development of other external tools, such as [git-sizer(1)](https://github.com/github/git-sizer), to fill this gap.\n\n\n\nWith the release of Git 2.52, a new “structure” subcommand has been added to git-repo(1) with the aim to surface information about a repository's structure. Currently, it displays info about the number of references and objects in the repository in the following form:\n\n\n\n```shell\n\n$ git repo structure\n\n\n| Repository structure | Value  |\n| -------------------- | ------ |\n| * References         |        |\n|   * Count            |   1772 |\n|     * Branches       |      3 |\n|     * Tags           |   1025 |\n|     * Remotes        |    744 |\n|     * Others         |      0 |\n|                      |        |\n| * Reachable objects  |        |\n|   * Count            | 418958 |\n|     * Commits        |  87468 |\n|     * Trees          | 168866 |\n|     * Blobs          | 161632 |\n|     * Tags           |    992 |\n\n```\n\n\n\nIn subsequent releases we hope to expand on this and provide other interesting data points like the largest objects in the repository.\n\n\n\n*This project was led by [Justin Tobler](https://gitlab.com/justintobler).*\n\n\n\n## Improvements related to the Google Summer of Code 2025\n\n\n\nWe had three successful projects with the Google Summer of Code.\n\n\n\n### Refactoring in order to reduce Git's global state\n\n\n\nGit contains several global variables used throughout the codebase. This increases the complexity of the code and reduces the maintainability. As part of this project, [Ayush Chandekar](https://ayu-ch.github.io/) worked on reducing the usage of the `the_repository` global variable via a series of patches.\n\n\n\n*The project was mentored by [Christian Couder](https://gitlab.com/chriscool) and [Ghanshyam Thakkar](https://in.linkedin.com/in/ghanshyam-thakkar).*\n\n\n\n### Machine-readable Repository Information Query Tool\n\n\n\nGit lacks a centralized way to retrieve repository information, requiring users to piece it together from various commands. While `git-rev-parse(1)` has become the de-facto tool for accessing much of this information, doing so falls outside its primary purpose.\n\n\n\nAs part of this project, [Lucas Oshiro](https://lucasoshiro.github.io/en/) introduced a new command, `git-repo(1),` which will house all repository-level information. Users can now use `git repo info` to obtain repository information:\n\n\n\n```shell\n\n$ git repo info layout.bare layout.shallow object.format references.format\n\nlayout.bare=false\nlayout.shallow=false\nobject.format=sha1\nreferences.format=reftable\n\n```\n\n\n\n*The project was mentored by [Patrick Steinhardt](https://gitlab.com/pks-gitlab) and [Karthik Nayak](https://gitlab.com/knayakgl).*\n\n\n\n### Consolidate ref-related functionality into git-refs\n\n\n\nGit offers multiple commands for managing references, namely `git-for-each-ref(1)`, `git show-ref(1)`, `git-update-ref(1)`, and `git-pack-refs(1)`. This makes them harder to discover and creates overlapping functionality. To address this, we introduced the `git-refs(1)` command to consolidate these operations under a single interface. As part of this this project, [Meet Soni](https://inosmeet.github.io/) extended the command by adding the following subcommands:\n\n\n\n* `git refs optimize` to optimize the reference backend\n\n\n* `git refs list` to list all references\n\n\n* `git refs exists` to verify the existence of a reference\n\n\n\n*The project was mentored by [Patrick Steinhardt](https://gitlab.com/pks-gitlab) and [shejialuo](https://luolibrary.com/).*\n\n\n\n## What's next?\n\n\n\nReady to experience these improvements? Update to Git 2.52.0 and start using `git last-modified`.\n\n\n\nAt GitLab, we will of course ensure that all of these improvements will eventually land in a GitLab instance near you!\n\n\n\nLearn more in the [official Git 2.52.0 release notes](https://lore.kernel.org/git/xmqqh5usmvsd.fsf@gitster.g/) and explore our [complete archive of Git development coverage](https://about.gitlab.com/blog/tags/git/).\n",[23,24,258],{"featured":12,"template":13,"slug":726},"whats-new-in-git-2-52-0",{"content":728,"config":736},{"title":729,"description":730,"authors":731,"heroImage":711,"date":733,"body":734,"category":9,"tags":735},"What’s new in Git 2.51.0?","Learn about the latest contributions from GitLab's Git team and the Git community, including performance optimizations for git-push(1) and git-fetch(1).",[732],"Karthik Nayak","2025-08-18","The Git project recently released [Git 2.51](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u). Due to summer in the Northern Hemisphere and slower progress, this release cycle was on the shorter side of 8 weeks (typically a release cycle lasts about 12 weeks). Let’s look at some notable changes in this release, including contributions from the Git team at GitLab and also the wider Git community.\n\n## Performance optimizations for `git-push(1)` and `git-fetch(1)`\n\nThe `git-push(1)` and `git-fetch(1)` commands allow users to synchronize local and remote repositories. Part of the operation involves updating references in the repository. In repositories with many references, this can take significant time, especially for users who work with large development environments, monorepos, or repositories with extensive CI/CD pipelines.\nGit reference transactions can include multiple reference updates, but they follow an all-or-nothing approach. If any single update within the transaction fails, the entire transaction fails and none of the reference updates are applied. But reference updates as part of `git-push(1)` and `git-fetch(1)` are allowed to fail, which allows repositories to synchronize a subset of references even in the case where a different subset has diverged. To facilitate this behavior, Git creates a separate transaction for each reference update, allowing some transactions to fail while the rest succeed. \nCreating a separate transaction per update incurs significant overhead, as each transaction includes an initiation and teardown phase and also checks for whether there are conflicting reference names. The “reftable” backend also performs auto-compaction at the end of a transaction, so multiple transactions would trigger multiple auto-compactions, which would drastically increase the latency of the command. \nIn Git 2.51.0, these commands now use batched updates instead of separate transactions. Batched updates allow updating multiple references under a single transaction, while still allowing some updates to fail. This removes the overhead and scales better with the number of references to be updated, since only a single transaction is used. This significantly improves the performance of the “reftable” backend, which now outperforms the “files” backend. Users can reap these performance improvements without needing to make any changes.\nFor `git-fetch(1)` we see a *22x performance improvement for the “reftable” backend* and *1.25x improvement for the “files” backend* when used in a repository with 10,000 references.\n\n```text\nBenchmark 1: fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      3.403 s ±  0.775 s    [User: 1.875 s, System: 1.417 s]\n  Range (min … max):    2.454 s …  4.529 s    10 runs\n\nBenchmark 2: fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     154.3 ms ±  17.6 ms    [User: 102.5 ms, System: 56.1 ms]\n  Range (min … max):   145.2 ms … 220.5 ms    18 runs\n\nSummary\n  fetch: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   22.06 ± 5.62 times faster than fetch: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: fetch: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):     605.5 ms ±   9.4 ms    [User: 117.8 ms, System: 483.3 ms]\n  Range (min … max):   595.6 ms … 621.5 ms    10 runs\n\nBenchmark 2: fetch: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     485.8 ms ±   4.3 ms    [User: 91.1 ms, System: 396.7 ms]\n  Range (min … max):   477.6 ms … 494.3 ms    10 runs\n\nSummary\n  fetch: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.25 ± 0.02 times faster than fetch: many refs (refformat = files, refcount = 10000, revision = master)\n\n```\n\nFor `git-push(1)` we see a *18x performance improvement for the reftable backend* and *1.21x improvement for the “files” backend* when used in a repository with 10,000 references.\n\n```text\nBenchmark 1: push: many refs (refformat = reftable, refcount = 10000, revision = master)\n  Time (mean ± σ):      4.276 s ±  0.078 s    [User: 0.796 s, System: 3.318 s]\n  Range (min … max):    4.185 s …  4.430 s    10 runs\n\nBenchmark 2: push: many refs (refformat = reftable, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     235.4 ms ±   6.9 ms    [User: 75.4 ms, System: 157.3 ms]\n  Range (min … max):   228.5 ms … 254.2 ms    11 runs\n\nSummary\n  push: many refs (refformat = reftable, refcount = 10000, revision = HEAD) ran\n   18.16 ± 0.63 times faster than push: many refs (refformat = reftable, refcount = 10000, revision = master)\n\nBenchmark 1: push: many refs (refformat = files, refcount = 10000, revision = master)\n  Time (mean ± σ):      1.121 s ±  0.021 s    [User: 0.128 s, System: 0.975 s]\n  Range (min … max):    1.097 s …  1.156 s    10 runs\n\nBenchmark 2: push: many refs (refformat = files, refcount = 10000, revision = HEAD)\n  Time (mean ± σ):     927.9 ms ±  22.6 ms    [User: 99.0 ms, System: 815.2 ms]\n  Range (min … max):   903.1 ms … 978.0 ms    10 runs\n\nSummary\n  push: many refs (refformat = files, refcount = 10000, revision = HEAD) ran\n    1.21 ± 0.04 times faster than push: many refs (refformat = files, refcount = 10000, revision = master)\n\n```\n\nThis [project](https://lore.kernel.org/git/20250514-501-update-git-fetch-1-to-use-partial-transactions-v1-0-7c65f46493d4@gmail.com/) was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## Planning towards Git 3.0\n\n11 years ago, Git 2.0 was released, which was the last major version release of Git. While we don’t have a specific timeline for the next major Git release, this release includes decisions made towards Git 3.0.\n\nThe Git 3.0 release planning allows us to plan for and implement breaking changes and communicate them to the extended Git community. Next to documentation, Git can also be compiled with these breaking changes for those who want to experiment with these changes. More information can be found in the [BreakingChanges document](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/BreakingChanges.adoc). \n\nThe Git 2.51.0 release makes some significant changes towards Git 3.0. \n\n### Reftable as the default reference backend\n\nIn the [Git 2.45.0](https://gitlab.com/gitlab-org/git/-/blob/master/Documentation/RelNotes/2.45.0.adoc?ref_type=heads) release, the “reftable” format was introduced as a new backend for storing references like branches or tags in Git, which fixes many of the issues with the existing \"files\" backend. Please read our [beginner's guide to how reftables work](https://about.gitlab.com/blog/a-beginners-guide-to-the-git-reftable-format/) for more insight into the “reftable” backend.\n\nThe Git 2.51.0 release marks the switch to using the \"reftable\" format as default in Git 3.0 for newly created repositories and also wires up the change behind a feature flag. The “reftable” format provides the following improvements over the traditional “files” backend:\n\n* It is impossible to store two references that only differ in casing on case-insensitive filesystems with the \"files\" format. This issue is common on Windows and macOS platforms. As the \"reftable\" backend does not use filesystem paths to encode reference names this problem goes away.\n* Similarly, macOS normalizes path names that contain unicode characters, which has the consequence that you cannot store two names with unicode characters that are encoded differently with the \"files\" backend. Again, this is not an issue with the \"reftable\" backend.\n* Deleting references with the \"files\" backend requires Git to rewrite the complete \"packed-refs\" file. In large repositories with many references this file can easily be dozens of megabytes in size; in extreme cases it may be gigabytes. The \"reftable\" backend uses tombstone markers for deleted references and thus does not have to rewrite all of its data.\n* Repository housekeeping with the \"files\" backend typically performs all-into-one repacks of references. This can be quite expensive, and consequently housekeeping is a tradeoff between the number of loose references that accumulate and slow down operations that read references, and compressing those loose references into the \"packed-refs\" file. The \"reftable\" backend uses geometric compaction after every write, which amortizes costs and ensures that the backend is always in a well-maintained state.\n* Operations that write multiple references at once are not atomic with the \"files\" backend. Consequently, Git may see in-between states when it reads references while a reference transaction is in the process of being committed to disk.\n* Writing many references at once is slow with the \"files\" backend because every reference is created as a separate file. The \"reftable\" backend significantly outperforms the \"files\" backend by multiple orders of magnitude.\n* The “reftable” backend uses a binary format with prefix compression for reference names. As a result, the format uses less space compared to the \"packed-refs\" file.\n\nThis project was led by [Patrick Steinhardt](https://gitlab.com/pks-gitlab).\n\n### SHA-256 as the default hash function\n\nThe Git version control system stores objects in a content-addressable filesystem. This means it uses the hash of an object to address content such as files, directories, and revisions, unlike traditional filesystems, which use sequential numbers. Using a hash function has the following advantages: \n\n* Easy integrity checks as a single bit flip would change the hash output completely.\n* Fast object lookup as objects can be indexed by their hash.\n* Object names can be signed and third parties can trust the hash to address the signed object and all objects it references.\n* Communication using Git protocol and out of band communication methods have a short reliable string that can be used to reliably address stored content.\n\nSince its inception, Git has used the SHA-1 hashing algorithm. However, security researchers have discovered some flaws in SHA-1, specifically the [SHAttered attack](https://shattered.io), which shows a practical SHA-1 hash collision. We moved to using a hardened SHA-1 implementation by default since Git 2.13.0. However, SHA-1 is still a weak hashing algorithm and it is only a matter of time before additional attacks will further reduce its security.\n\nSHA-256 was identified as the successor to SHA-1 in late 2018. Git 2.51.0 marks it as the default hash algorithm to be used in Git 3.0.\n\nThis project was led by [brian m. carlson](https://github.com/bk2204).\n\n### Removal of `git-whatchanged(1)`\n\nThe `git-whatchanged(1)` command shows logs with differences each commit introduces. While this is now succeeded by `git log --raw`, the command was kept around for historical reasons. \n\nGit 2.51.0 requires users of the command to explicitly use the `--i-still-use-this` flag to capture any users who still use the deprecated command, and also marks the command for removal in Git 3.0. \n\nThis project was led by [Junio C Hamano](https://simple.wikipedia.org/wiki/Junio_Hamano).\n\n## `git switch` and `git restore` are no longer experimental\n\nThe `git-checkout(1)` command can be used for multiple different use cases. It can be used for switching references:\n\n```shell\n$ git status On branch master Your branch is up to date with 'origin/master'.\nnothing to commit, working tree clean\n$ git checkout next Switched to branch 'next' Your branch is up to date with 'origin/next'.\n```\n\nOr for restoring files:\n\n```shell\n$ echo \"additional line\" >> git.c\n$ git status On branch master Your branch is up to date with 'origin/master’.\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git checkout git.c Updated 1 path from the index\n$ git status On branch master Your branch is up to date with 'origin/master’.\nnothing to commit, working tree clean\n```\n\nFor new users of Git, this can cause a lot of confusion. So in Git 2.33.0, these were split into two new commands, `git-switch(1)` and `git-restore(1)`.\nThe `git-switch(1)` command allows users to switch to a specific branch: \n\n```shell\n$ git status On branch master Your branch is up to date with 'origin/master'.\nnothing to commit, working tree clean\n$ git switch next Switched to branch 'next' Your branch is up to date with 'origin/next'.\n```\n\nAnd the `git-restore(1)` command allows users to restore working tree files: \n\n```shell\n$ echo \"additional line\" >> git.c\n$ git status On branch master Your branch is up to date with 'origin/master’.\nChanges not staged for commit:\n  (use \"git add \u003Cfile>...\" to update what will be committed)\n  (use \"git restore \u003Cfile>...\" to discard changes in working directory)\n    modified:   git.c\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$ git restore git.c\n$ git status On branch master Your branch is up to date with 'origin/master’.\nnothing to commit, working tree clean\n```\n\nWhile the two commands have existed since 2019, they were marked as experimental. The effect is that the Git project doesn’t guarantee backwards compatibility for those commands: the behavior may change at any point in time. While the intent originally was to stabilize those commands after a couple of releases, this hasn’t happened up to this point.\nThis has led to several discussions on the Git mailing list where users are unsure whether they can start using these new commands, or whether they might eventually go away again. But given that no significant changes have ever been proposed, and that some users are already using these commands, we have decided to no longer declare them as experimental in Git 2.51.\nThis project was led by [Justin Tobler](https://gitlab.com/justintobler).\n\n## `git for-each-ref(1)` receives pagination support\n\nThe `git for-each-ref` command is used to list all references present in the repository. As it is part of the plumbing layer of Git, this command is frequently used for example by hosting forges to list references that exist in the repository in their UI. But as repositories grow, it becomes less realistic to list all references at once – after all, the largest repositories may contain millions of them! So instead, forges tend to paginate the references.\n\nThis surfaces an important gap: `git-for-each-ref` does not know to skip references from previous pages that have already been shown. Consequently, it may have to list a large number of uninteresting references before it finally starts to yield the references required for the current page. This is inefficient and leads to higher-than-necessary latency or even timeouts.\n\nGit 2.51.0 supports a new `--start-after` flag for `git for-each-ref`, which allows paginating the output. This can also be combined with the `--count` flag to iterate over a batch of references. \n\n```shell\n$ git for-each-ref --count=10 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-001 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-002 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-003 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-004 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-005 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-006 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-007 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-008 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-009 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-010\n$ git for-each-ref --count=10 --start-after=refs/heads/branch-010 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-011 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-012 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-013 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-014 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-015 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-016 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-017 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-018 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-019 9751243fba48b34d29aabfc9784803617a806e81 commit    refs/heads/branch-020\n```\n\nThis project was led by [Karthik Nayak](https://gitlab.com/knayakgl).\n\n## What's next?\n\nReady to experience these improvements? Update to Git 2.51.0 and start using `git switch` and `git restore` in your daily workflow. \n\nFor GitLab users, these performance enhancements will automatically improve your development experience once your Git version is updated.\n\nLearn more in the [official Git 2.51.0 release notes](https://lore.kernel.org/git/xmqqikikk1hr.fsf@gitster.g/T/#u) and explore our [complete archive of Git development coverage](https://about.gitlab.com/blog/tags/git/).\n",[24,23,258],{"featured":29,"template":13,"slug":737},"what-s-new-in-git-2-51-0",{"promotions":739},[740,754,766],{"id":741,"categories":742,"header":744,"text":745,"button":746,"image":751},"ai-modernization",[743],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":747,"config":748},"Get your AI maturity score",{"href":749,"dataGaName":750,"dataGaLocation":240},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":752},{"src":753},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":755,"categories":756,"header":758,"text":745,"button":759,"image":763},"devops-modernization",[757,556],"product","Are you just managing tools or shipping innovation?",{"text":760,"config":761},"Get your DevOps maturity score",{"href":762,"dataGaName":750,"dataGaLocation":240},"/assessments/devops-modernization-assessment/",{"config":764},{"src":765},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":767,"categories":768,"header":770,"text":745,"button":771,"image":775},"security-modernization",[769],"security","Are you trading speed for security?",{"text":772,"config":773},"Get your security maturity score",{"href":774,"dataGaName":750,"dataGaLocation":240},"/assessments/security-modernization-assessment/",{"config":776},{"src":777},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"header":779,"blurb":780,"button":781,"secondaryButton":786},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":782,"config":783},"Get your free trial",{"href":784,"dataGaName":47,"dataGaLocation":785},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":492,"config":787},{"href":51,"dataGaName":52,"dataGaLocation":785},1772652082363]