BlogsGitLabGit Core Improvements and Contributions

Git Core Improvements and Contributions

Git Core Improvements and Contributions

49
posts
2014–2026

GitLab actively contributes to the core Git project, focusing on performance enhancements, new features, and improved reliability. This includes developing and upstreaming new commands like `git-replay` for efficient in-memory rebasing, optimizing commit-graph operations for faster history traversal, and preparing Git for a more robust and scalable ref backend with the 'reftable' format. The Gitaly team has also reworked the object database maintenance strategy to leverage new Git mechanisms like reftables. This release introduces tooling for migrating existing repositories to the reftable format, transactional symref updates for atomic reference operations, and subcommand-based UX improvements for `git-config`. Performance regressions related to attribute lookups in bare repositories have been addressed, and progress is being made on migrating end-to-end tests to a new C-based unit-testing framework. Bundle URI fixes have also been implemented.

2026

What's new in Git 2.55.0?

6/29/2026

This post details several new features and improvements in Git 2.55.0, with contributions from the GitLab team. Key additions include: `git-history(1)` now supports a `fixup` subcommand for amending staged changes into existing commits, simplifying commit history editing. The `fsmonitor` daemon, previously available on Windows and macOS, now supports Linux using `inotify` to improve the performance of `git status` in large repositories by monitoring filesystem changes. `git push` now supports pushing to remote groups, mirroring the functionality of `git fetch`. A new `--graph-lane-limit` option for `git log --graph` allows users to control the width of the commit history visualization by truncating excessive lanes. The post also notes the continued evolution of Rust integration within the Git codebase.

What’s new in Git 2.54.0?

4/20/2026

GitLab's contributions to Git 2.54.0 include the introduction of pluggable object databases, enabling alternative storage formats for Git objects, and the `git history` command which simplifies commit history editing with subcommands like `reword` and `split`, and automatically rebases dependent branches. Additionally, the `git repo structure` command has been enhanced to display the largest objects by type, providing detailed repository metrics.

What’s new in Git 2.53.0?

2/2/2026

This post details GitLab's contributions to Git 2.53.0, specifically: enabling geometric repacking support with promisor remotes for partial clone repositories, enhancing `git-fast-import(1)` with a `strip-if-invalid` mode for signed commits, and expanding the `git-repo structure` subcommand to collect total size information for reachable objects.

2025

What’s new in Git 2.52.0?

11/17/2025

This post details the introduction of the `git-last-modified(1)` command, which significantly improves the efficiency of retrieving the last commit for each file in a Git repository by walking the history only once. It also highlights improvements to `git-fast-export(1)` and `git-fast-import(1)` for handling cryptographic signatures, and the introduction of a "geometric" maintenance strategy for `git-maintenance(1)` to optimize large monorepos. GitLab's Git team contributed to these upstream changes.

What’s new in Git 2.51.0?

8/18/2025

This post details contributions to Git 2.51.0, specifically focusing on performance optimizations for `git-push` and `git-fetch` using batched reference updates, the transition of 'reftable' to be the default reference backend for new repositories, and the adoption of SHA-256 as the default hash function. It also notes the deprecation of `git-whatchanged` and the stabilization of `git switch` and `git restore`.

What’s new in Git 2.50.0?

6/16/2025

Introduced `git-diff-pairs(1)` command to efficiently generate patch output from `git-diff-tree(1)`'s raw format, enabling batched diff computation for improved scalability in large change sets. Added `--batch-updates` option to `git-update-ref(1)` to allow partial success of reference updates within a transaction. Introduced `--filter` option to `git-cat-file(1)` for more efficient object retrieval by type or other criteria.

How we decreased GitLab repo backup times from 48 hours to 41 minutes

6/5/2025

This post details a specific performance optimization contributed upstream to the Git project, addressing a bottleneck in `git bundle create`. The issue was an O(N^2) complexity in `object_array_remove_duplicates()` due to nested loops for duplicate reference handling. The fix replaces this with a map data structure, improving performance by up to 6x in benchmarks. This optimization was backported to GitLab for immediate customer benefit, reducing backup times for the largest repository from 48 hours to 41 minutes.

Journey through Git's 20-year history

4/14/2025

This post details the early history of Git, starting from its first commit in 2005. It describes the initial set of commands (`init-db`, `update-cache`, `write-tree`, `read-tree`, `commit-tree`, `cat-file`, `show-diff`), the early distinction between shared and private object storage, and the non-ergonomic process of creating commits. It then covers the transition to Git 0.99, the introduction of the top-level `git` command, the plumbing/porcelain distinction, and Junio Hamano taking over maintainership. The post also touches on Git 1.0, the evolution of remotes configuration (from `.git/branches` to `.git/remotes` and eventually `.git/config`), and the history of Git's branding and website redesigns, culminating in the Git 2.0 release which introduced backwards-incompatible changes like the default behavior of `git push`.

Celebrating Git's 20th anniversary with creator Linus Torvalds

4/7/2025

This post details the origin and early development of Git, including Linus Torvalds' motivations for creating it due to dissatisfaction with existing version control systems like CVS and SVN. It covers the initial design decisions, the rapid development of the first version, the handover of maintainership to Junio Hamano, and the reasons for Git's eventual dominance over Mercurial, emphasizing network effects and superior design. It also touches on key milestones after its initial release, such as the development of Git hosting sites and Windows support.

What's new in Git 2.49.0?

3/14/2025

This post details new features in Git 2.49.0, including `git-backfill(1)` which leverages a new path-walk API for efficient downloading of missing blobs in partial clones, the introduction of `zlib-ng` as a drop-in replacement for `zlib` with performance optimizations, continued work on the Meson build system, deprecation of `.git/branches/` and `.git/remotes/`, Rust bindings for libgit, a new name-hashing algorithm, the promisor remote capability, and thin clone support using `--revision`. It highlights contributions from GitLab's Git team and the wider community.

What’s new in Git 2.48.0?

1/10/2025

This post details several contributions to Git 2.48.0, including the implementation of the Meson build system for improved build configuration and IDE integration, the resolution of all memory leaks identified by the test suite, enhancements to bundle URI checks to align with fsck severities, the integration of reference consistency checks into git-fsck, performance improvements in the reftables backend through iterator reuse, the addition of reflog migration support to `git-refs migrate`, and significant optimizations to the ref-filter subsystem.

2024

Git command line on Windows with Git Bash

12/16/2024

This post details how to install and use Git Bash on Windows, explaining its functionality as a Bash terminal emulator for Git commands. It covers installation steps, basic Bash commands (`pwd`, `ls`, `cd`), and how to connect Git Bash to GitLab repositories using `git remote add origin`. It also addresses authentication for private repositories and lists common Git commands.

What's new in Git 2.47.0?

10/7/2024

This post details several contributions to Git 2.47.0, including new global configuration options (`init.defaultRefFormat`, `init.defaultObjectFormat`) for easier adoption of reftables and SHA-256 object formats, the addition of the `git refs verify` subcommand for repository consistency checks, fixes for `git-maintenance(1)` to improve its `--auto` behavior and introduce a heuristic for reference packing in the 'files' backend, and ongoing code refactoring efforts to reduce memory leaks and the use of global variables like `the_repository`.

What is GitFlow?

9/27/2024

This post introduces and contrasts GitFlow and GitLab Flow. It details GitFlow's five branch types (main, develop, feature, release, hotfix) and its structured workflow for complex releases. It then presents GitLab Flow as a simplified alternative, emphasizing its use of pre-production branches (e.g., test, acceptance) before merging to main and production, and its flexibility for versioned APIs. The post also outlines the benefits of GitFlow such as rapid bug fixes, ensured testing, streamlined development, and efficient collaboration, and provides a comparison table and FAQ to help users choose between the two workflows.

Git pull vs. git fetch: What's the difference?

9/24/2024

This post explains the fundamental differences between `git fetch` and `git pull`, detailing their individual functionalities and use cases. It clarifies that `git fetch` downloads changes without merging, allowing for review, while `git pull` combines fetching and merging (or rebasing) into a single operation. It provides guidance on when to use each command, emphasizing the safety of `git fetch` for reviewing changes before integration and the speed of `git pull` for quick synchronization, while also warning about potential merge conflicts.

GitLab now supports SHA256 repositories

8/19/2024

This post introduces the ability to create new GitLab projects using the SHA256 hashing algorithm, which was previously supported on the backend in Gitaly. This feature is experimental and can be enabled via experimental settings on the project creation page.

What’s new in Git 2.46.0?

7/29/2024

This post details the introduction of tooling for migrating Git references to the reftable format using `git refs migrate`, the addition of `symref-create`, `symref-update`, `symref-delete`, and `symref-verify` instructions for transactional symref updates in `git update-ref`, and the introduction of subcommand-based UX improvements for `git-config` (list, get, set, unset, rename-section, remove-section, edit). It also covers the addressing of a performance regression in bare repositories related to `attr.tree` configuration and progress on migrating end-to-end tests to a unit-testing framework. Finally, it mentions bundle URI fixes.

What’s new in Git 2.45.0?

4/30/2024

Introduced the 'reftable' backend in Git v2.45.0, a new binary format for storing references that addresses scalability issues, atomic read/write limitations, and housekeeping inefficiencies of the traditional 'files' format. This project was led by Patrick Steinhardt, with contributions from Shawn Pearce (original inventor) and Han-Wen Nienhuys (reftable library author). Also contributed to tooling improvements: `git-for-each-ref --include-root-refs` for listing all references (led by Karthik Nayak) and `git-reflog list` for listing all reflogs (led by Patrick Steinhardt). Introduced `git pack-refs --auto` mode for more efficient packing of references, particularly for the 'reftable' backend (led by Patrick Steinhardt).

GitLab's contributions to Git 2.44.0

2/26/2024

This post details GitLab's contributions to Git 2.44.0, including the upstreaming of `git-replay` for in-memory rebasing in bare repositories, improvements to commit-graph object existence checks to mitigate performance regressions, and significant work on preparing Git for a new 'reftable' ref backend by refactoring internal Git structures and improving the reftable library.

The contributions we made to the Git 2.43 release

1/11/2024

This post details specific contributions to Git 2.43 from GitLab's Git team. Key contributions include: adding a `--filter` option to `git repack` to segment objects across packfiles, which can lead to storage optimizations; adding the `--exists` option to `git show` for generic object existence checks, crucial for the reftable backend; extending `git rev-list`'s `--missing` option to include commit objects, enabling better identification of new objects for the write-ahead log implementation; and allowing `gitattributes` to read from HEAD in bare repositories by default via the `--attr-source` flag, simplifying Gitaly's tech debt reduction efforts. Bug fixes for `git rev-list –stdin` and commit-graph object existence checks were also made.

2023

Why and how we rearchitected Git object database maintenance for scale

11/2/2023

This post details the rearchitecture of Git object database maintenance in Gitaly to leverage new Git features like geometric repacking (Git v2.32.0) and cruft packs (Git v2.37.0). It explains the inefficiencies of the old strategy (all-into-one repacks, loose objects for grace periods, expensive reachability checks) and how the new strategy addresses these by: 1. Using geometric repacking to merge packfiles without full rewrites, reducing cost and resource usage. 2. Employing cruft packs with `.mtimes` files to store unreachable objects efficiently while retaining per-object grace period tracking, thus avoiding unpacking to loose objects. 3. Enabling more efficient incremental repacks by reducing the need for full reachability checks.

Git 2.42 release: Here are four of our contributions in detail

10/12/2023

This post details four specific contributions from GitLab's Git team to the Git 2.42 release: 1. Added `--include` and `--exclude` options to `git pack-refs` to allow finer control over which references are packed, crucial for write-ahead logging in Gitaly. 2. Implemented the `-Z` option for `git cat-file --batch` to use NUL characters as delimiters for both input and output, resolving issues with newlines in filenames and error messages. 3. Enabled passing pseudo-options (e.g., `--not`, `--glob`, `--all`) via stdin to `git rev-list --stdin`, improving flexibility for tasks like calculating repository sizes for pool repositories. 4. Contributed code style improvements and refactoring to the Git codebase.

Migrating Arch Linux's packaging infrastructure to GitLab

9/11/2023

Arch Linux migrated its packaging infrastructure from Subversion to Git and GitLab, involving the creation of over 12,000 individual Git repositories. This migration utilized custom tooling with `git-svn` imports and `git-filter-repo` for history migration and rewriting. Additionally, a new package maintainer tool, `pkgctl`, was developed.

GitLab Gitaly project now supports the SHA 256 hashing algorithm

8/28/2023

This post details the successful integration of SHA-256 hashing algorithm support into the Gitaly project. It explains the technical reasons for migrating from SHA-1 to SHA-256 due to security vulnerabilities and regulatory requirements. The post includes technical details on how Git uses hashing algorithms, demonstrates SHA-256 in action with command-line examples, and highlights that the experimental label has been removed from SHA-256 in Git 2.42.0. While Gitaly now supports SHA-256, further work is needed in other parts of the GitLab application before SHA-256 repositories can be fully utilized.

Git 2.41 release - Here are five of our contributions in detail

6/20/2023

This post details three specific contributions from GitLab's Git team to the Git 2.41 release: 1. The addition of a `--porcelain` option to `git-fetch` to provide machine-parseable output, enabling more efficient repository mirroring by allowing Gitaly to handle reference updates in a single transaction. 2. A new `--attr-source=<tree>` option for Git attributes, allowing Gitaly to read `.gitattributes` directly from a tree-ish without needing to copy them to `info/attributes`, simplifying internal RPCs and improving performance. 3. A bug fix for a regression in commit-graph generation numbers that corrupted the commit-graph for specific repositories.

Future-proofing Git repository maintenance

3/20/2023

This post details the revamp of GitLab's repository housekeeping strategy within Gitaly. It explains the limitations of the previous client-driven RPC-based approach, especially for monorepositories, and introduces the new `OptimizeRepository` RPC. This RPC acts as a black-box, analyzing the repository's on-disk state to intelligently perform maintenance tasks like packing objects, pruning objects, packing references, and updating auxiliary data structures. The post also covers the rollout of this new strategy to GitLab.com, highlighting performance improvements and the iterative nature of refining the heuristics.

Git security audit: Inside the hunt for - and discovery of - CVEs

1/24/2023

This post details the discovery and root cause analysis of CVE-2022-41903, a heap corruption vulnerability in `git archive` related to `export-subst` and pretty format padding specifiers. It highlights the collaborative process involving GitLab, X41 D-Sec, and OSTIF, and mentions the contribution of GitLab's Gitaly team in developing fixes and extending Git's fuzzing harness.

2022

Take advantage of Git rebase

10/6/2022

This post details how to use `git rebase -i` for interactive rebasing to rework commits, making them smaller and more self-contained for easier review. It explains the interactive rebase process, editing the instruction list, and using commands like `pick`, `reword`, `edit`, `squash`, and `fixup`. It also introduces the `--exec` flag for running shell commands after each rebased commit, enabling automated testing of individual commits.

2021

The new Git default branch name

3/10/2021

This post details GitLab's adoption of the 'main' branch as the default for new projects, aligning with the Git project's move away from 'master'. It outlines the phased rollout for GitLab.com and self-managed instances, including the necessary actions for users to update CI/CD configurations. It also mentions the internal migration of GitLab's own projects to use 'main' as the default branch.

2020

How to keep your Git history clean with interactive rebase

11/23/2020

This post details how to use interactive rebase for cleaning up local commit history, including rewording commit messages, squashing multiple commits into one, and using 'fixup' with '--autosquash' to correct earlier commits without leaving 'band-aid' commits.

Migrating your version control to Git? Here’s what you need to know

11/12/2020

This post provides guidance on migrating to Git from other version control systems. It covers strategies for retaining previous systems, cloning for testing, investing in Git learning, and identifying branching strategies. It also highlights the prevalence of Git in the industry and links to further resources.

Distributed Version Control & Collaboration

10/2/2020

This post discusses how Distributed Version Control, specifically Git, allows for remote, collaborative work by enabling each developer to have a copy of the project's history. It highlights how GitLab leverages Git's capabilities, such as merge requests, to support branching strategies and Continuous Integration by facilitating frequent merges of short-lived branches into the main branch.

dotfiles - Document and automate your Macbook setup

4/17/2020

This post details the author's personal use of dotfiles to manage their macOS development environment. It covers configuration for ZSH with OhMyZSH (including a custom git prune alias), Git configuration (including a custom log command and osxkeychain helper), and Vim configuration. It also describes using Homebrew for software installation and Alfred for enhanced workflows. The author shares their dotfiles repository as an open-source example for others to fork and adapt.

15 Git tips to improve your workflow

4/7/2020

This post details 15 tips to improve Git workflow, including using aliases for common commands, visualizing repository status in the terminal prompt, comparing commits with `git diff` and `git difftool`, stashing uncommitted changes with `git stash`, pulling frequently to avoid conflicts, using completion scripts for command autocompletion, setting up a global `.gitignore` file, enabling Git's autosquash feature by default, deleting local branches that have been removed from the remote on fetch/pull, using `git blame` more efficiently with flags, adding an alias to check out merge requests locally, using `@` as an alias for `HEAD`, resetting files with `git reset --hard HEAD` or `git checkout HEAD -- path/to/file`, utilizing the `git-open` plugin to visit the repository's website, and installing the `git-extras` plugin for additional commands.

Git Merge 2020: a celebration of Git

3/25/2020

This post details GitLab's participation and contributions to Git Merge 2020, highlighting specific technical advancements and collaborations. It discusses Tianyu Pu's talk on 'The Zen of Git' explaining Git's internals, Ed Thomson's ideas on lightweight branching models, and Derrick Stolee's presentation on Scalar for accelerating Git's workflow in large repositories, with plans to contribute it to Git's client. The post also mentions contributions to packfile handling by Peff (GitHub) and Christian Couder (GitLab), and GitLab's ongoing work on stabilizing Partial Clone. It emphasizes the collaborative nature of Git development between enterprises and the community.

The problem with Git flow

3/5/2020

Introduces GitLab Flow as a simplified branching strategy that integrates issue tracking with Git workflows. It contrasts this with Git flow, highlighting the reduction in branch switching and overhead by merging feature branches directly to master and using optional production/stable branches. Key principles include testing all commits and prioritizing code reviews before merging.

2019

How to tidy up your merge requests with Git

2/7/2019

This post introduces techniques for tidying up Git commit history using `git reset --soft`, `git commit --fixup`, and `git rebase -i --autosquash`. It also discusses using `git commit --amend` to prevent messy commits during feature development and warns about the implications of rewriting Git history with `git push --force`.

2018

Git Protocol v2 now enabled for SSH on GitLab.com

12/10/2018

GitLab has enabled Git Protocol v2 over SSH on GitLab.com, following its earlier enablement for HTTP. This protocol, supported from Git v2.18.0, improves the performance of fetch commands and enables future protocol enhancements by defining how clones, fetches, and pushes are communicated between client and server. The post demonstrates a significant reduction in network traffic, dropping from over 36,000 lines (packets) to fewer than 30 for a sample `ls-remote` command on the gitlab-org/gitlab-ce.git repository when using Protocol v2 compared to Protocol v0.

Git happens! 6 Common Git mistakes and how to fix them

8/8/2018

This post details six common Git mistakes and their solutions: amending the last commit message, adding a forgotten file to the last commit, removing an unwanted file from staging or a commit, moving commits from the master branch to a new branch, renaming a branch, and using `git reflog` to recover from a corrupted repository. It also provides general advice on Git repository security and preventing large repositories.

How (and why!) to keep your Git commit history clean

6/7/2018

This post details how to manage and clean Git commit history using commands like `git commit --amend` and `git rebase -i` to improve the clarity and maintainability of the commit log. It covers scenarios for modifying the most recent commit, editing specific past commits, and combining or removing commits, emphasizing the importance of a clean history for debugging and collaboration.

2017

Why Git is worth the learning curve

5/17/2017

This post argues that despite its learning curve, Git offers significant rewards in terms of collaboration, code quality, and efficient branching/merging. It highlights how Git's distributed nature enables faster local operations, offline work, and "cheaper" branching compared to centralized systems. It also touches upon how tools like GitLab enhance merging with features like merge requests and continuous integration, and mentions the availability of community support.

2016

Git tips and tricks

12/8/2016

This post details various Git tips and tricks used at GitLab to improve developer workflow. It covers leveraging Git's built-in help commands (`git help <command>`, `git help -g`), setting up terminal prompt enhancements with `git-prompt.sh`, enabling autocompletion for Git commands, and utilizing Git plugins like `git-extras` and `git-open`. Additionally, it explores advanced `.gitconfig` options such as setting a global `.gitignore`, enabling `fetch.prune` and `rebase.autosquash` by default, configuring submodule summaries, changing the default editor, and customizing diff tools. These practices aim to enhance efficiency and reduce friction in daily Git operations.

How to keep your fork up to date with its origin

12/1/2016

This post introduces and details the functionality of GitLab Repository Mirroring as a solution for automatically keeping a forked repository up-to-date with its upstream origin. It explains the problem of manual updates leading to merge conflicts and presents the configuration steps within GitLab's settings to enable automatic mirroring. It also touches upon the requirements for public repositories and feature visibility settings for successful mirroring.

Notes from the Git Merge Core Contributors Summit

4/6/2016

This post details GitLab's participation in the Git Merge Core Contributors Summit. Key technical discussions included scaling Git for larger repositories and more contributors, with examples of performance issues in checkout and reference reading. Solutions like `git-repack` were mentioned. The post also touches on the growing adoption of Git through web interfaces like GitLab and the importance of protecting the Git trademark. Technical details on submodule improvements and the `submitgit` tool for email-based patch submission were also discussed.

2015

Did you install GitLab from source? Check your Git version

6/12/2015

This post addresses a specific security vulnerability (CVE-2014-9390) in Git versions that might have been installed from source following older GitLab installation guides. It urges users who installed GitLab from source and compiled Git themselves to check their Git version and upgrade if necessary to prevent their GitLab server from pushing 'poisoned' repositories to vulnerable client systems. It clarifies that Omnibus packages are not affected and provides a link to an upgrade guide.

8 Tips to help you work better with Git

2/19/2015

This post provides practical tips for improving Git workflow efficiency. It details how to use Git aliases for common commands, the `git stash` command for temporarily storing uncommitted changes, `git diff` and `git difftool` for comparing commits and files, and `git reset` and `git checkout` for reverting changes. It also explains how to use `git blame` more efficiently with flags to ignore whitespace, moved text, and text moved into other files. Finally, it offers workflow advice on pulling frequently, committing often but not pushing every commit, and pushing tested changes.

GitLab Annex enables versioning of large binaries with git

2/17/2015

This post introduces the integration of git-annex with GitLab Enterprise Edition 7.8, enabling versioning of large binaries by storing symlinks in Git and the actual binaries separately. It details how this integration works, its benefits for managing large files, and provides usage examples. It also notes the deprecation and eventual removal of this feature in favor of git-lfs.

2014

3 reasons GitLab isn't vulnerable to Gollum + 1 tip

12/9/2014

This post addresses a specific vulnerability in Gollum, a git-powered wiki, and explains why GitLab is not affected. The reasons cited are: 1. GitLab uses its own search implementation, not Gollum's. 2. GitLab employs `Shellwords.shellescape(query)` for search queries. 3. Since GitLab 7.4, the company has transitioned to using the `rugged` library, completely avoiding the `grit` library. It also notes that GitLab installations prior to version 6.6 are also not vulnerable. The post also highlights that the `gitlab-grit` gem, developed by GitLab, was the source of the vulnerability and recommends adopting GitLab's guidelines for combating remote code execution vulnerabilities, further emphasizing the move to `Rugged`.

WANdisco integrates GitLab Enterprise in Git MultiSite

9/22/2014

This post details a partnership with WANdisco to integrate Git MultiSite with GitLab Enterprise Edition. This integration leverages WANdisco's active-active replication and Distributed Coordination Engine (DConE) to provide seamless, efficient, and highly available Git workflows for large, distributed development teams by turning every server into a writable Git peer node, resolving conflicts transparently and quickly, and offering LAN-speed performance regardless of location.