TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

Git Core Improvements and Contributions

55 posts · Sep 2014 – Sep 2026

What this trail covers

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-backfill` for efficient partial clone recovery, optimizing path-walk API for faster history traversal, and introducing `zlib-ng` for improved compression performance. Continued iteration on the Meson build system aims to eventually replace Autoconf, CMake, and Make.

All GitLab trails
  1. What's new in Git 2.56.0?This post details new features in Git 2.56.0, including `git history drop` for easier commit deletion, `--forked` and `--delete-merged` flags for `git branch` to clean up merged branches, and expanded capabilities for `git refs` to create, delete, update, and rename references. It also highlights Google Summer of Code projects co-mentored by GitLab engineers, such as adding `remote-object-info` to `git cat-file` for partial clone metadata retrieval and improving disk space recovery for partial clones with `git repack --drop-filtered`. The post also discusses the roadmap for Git 3.0, including SHA-256 as the default object hash and reftable as the default reference storage format.
  2. Avoid the massive end-to-end tax of default full history clonesThis post introduces the Git Clone Override Policy, a new mechanism to automatically enforce optimized Git clone strategies. It details the development of a lightweight Go binary that intercepts default `git clone` commands and applies a repository-defined policy (TOML file) to perform shallow, partial, and sparse clones. The post also outlines the seven stages of maximum Git clone optimization and discusses the benefits of declarative configuration for standardization and reliability.
  3. What's new in Git 2.55.0?This post details contributions to Git 2.55.0, including the implementation of `git-history(1)`'s `fixup` subcommand, the addition of fsmonitor daemon support for Linux using inotify, enabling `git push` to work with remote groups, and the introduction of the `--graph-lane-limit` option for `git log --graph` to manage wide commit histories. It also touches on the ongoing evolution of Rust in the Git codebase and faster `git-grep` and `git-cherry` in partial clones.
  4. What’s new in Git 2.54.0?Introduced pluggable object databases to Git, enabling alternative storage formats for objects. Developed `git history` subcommands (`reword`, `split`) for easier commit history editing, inspired by Jujutsu. Enhanced `git repo structure` to display largest objects by type, making it a native replacement for `git-sizer(1)`.
  5. What’s new in Git 2.53.0?This post details specific contributions to Git 2.53.0: 1. Geometric repacking support with promisor remotes, enabling geometric repacking to work with partial clone repositories by handling promisor packfiles separately. 2. Enhancements to `git-fast-import(1)`'s `--signed-commits=<mode>` option with a new `strip-if-invalid` mode, allowing preservation of valid signatures for unchanged commits/tags. 3. Expansion of the `git-repo-structure` command to collect total size information for reachable objects (inflated and disk sizes) by object type, and improved human-readable output.
  7. What’s new in Git 2.52.0?This post details the introduction of the `git-last-modified(1)` command in Git 2.52, which significantly improves the efficiency of retrieving the last commit for each file in a tree by performing a single history walk. It also highlights improvements to `git-fast-export(1)` and `git-fast-import(1)` for handling cryptographic commit and tag signatures during history rewriting, and the addition of a new 'geometric' maintenance strategy for `git-maintenance(1)` to enhance scalability for large monorepos.
  8. What’s new in Git 2.51.0?Git 2.51.0 introduces performance optimizations for `git-push` and `git-fetch` by using batched reference updates instead of separate transactions, leading to significant speed improvements, especially for repositories with many references. This change improves the performance of the 'reftable' backend, making it outperform the 'files' backend. The release also marks the transition to 'reftable' as the default reference backend for new repositories and wires up SHA-256 as the default hash function for Git 3.0. The deprecated `git-whatchanged(1)` command is marked for removal in Git 3.0, and `git switch` and `git restore` are no longer experimental.
  9. What’s new in Git 2.50.0?This post details three new features in Git 2.50.0 that originated from GitLab's contributions: `git-diff-pairs(1)` for batched diff computation, `--batch-updates` for `git-update-ref(1)` to allow partial reference updates, and `--filter` for `git-cat-file(1)` to efficiently query specific object types. These features address scalability challenges in diff generation, provide more flexible reference updates, and improve the efficiency of object inspection in large repositories.
  10. How we decreased GitLab repo backup times from 48 hours to 41 minutesThis post details a fix for an O(N^2) complexity in Git's `object_array_remove_duplicates()` function, which was causing extremely long repository backup times. The fix replaces nested loops with a map data structure, improving performance by 6x in benchmarks and reducing GitLab's largest repository backup time from 48 hours to 41 minutes. This improvement was upstreamed to Git and backported for immediate customer benefit.
  11. Journey through Git's 20-year historyThis post details the early history of Git, from its first commit in 2005 to the introduction of Git 0.99 and Git 1.0. It highlights the evolution of core commands, the transition from direct command execution to the top-level `git` command, the introduction of plumbing and porcelain commands, and the handover of maintainership from Linus Torvalds to Junio Hamano. It also touches on the early mechanisms for remotes and Git branding.
  12. What's new in Git 2.49.0?This post details new features in Git 2.49.0, including `git-backfill` which leverages a new path-walk API for efficient blob downloading in partial clones, the introduction of `zlib-ng` for ~25% faster compression, continued work on the Meson build system for improved CI coverage and contrib support, and the deprecation of `.git/branches/` and `.git/remotes/`. It also mentions Rust bindings for libgit, a new name-hashing algorithm, and the promisor remote capability.
  13. What’s new in Git 2.48.0?This post details several contributions to Git 2.48.0: the implementation of Meson as a new build system option to replace Autoconf and CMake, achieving memory leak-free status for the test suite, enhancing bundle URI checks with fsck severities, adding reference consistency checks to git-fsck, improving performance in reftables by reusing iterators, adding support for reflog migration in `git-refs migrate`, and optimizing the ref-filter subsystem for significant speedups. These contributions were led by Patrick Steinhardt, Xing Xin, Justin Tobler, Jialuo She, and Karthik Nayak.
  14. GitLab now supports SHA256 repositoriesThis post announces the ability to create new GitLab projects using the SHA256 hashing algorithm, building upon the previous backend support in Gitaly. It highlights that this is an experimental feature for test projects and encourages users to file issues for any anomalies.
  15. What’s new in Git 2.46.0?This post details the introduction of the `git refs migrate` command for converting reference backends to the reftable format, the addition of `symref-create`, `symref-update`, `symref-delete`, and `symref-verify` instructions for transactional symref updates in `git update-ref`, UX improvements to `git-config` with subcommand syntax, and the partial reversion of the `attr.tree` configuration to address performance regressions in bare repositories. It also mentions ongoing unit-test migration efforts and bundle URI fixes.
  16. What’s new in Git 2.45.0?This post details the introduction of the 'reftable' backend for Git references in version 2.45.0. It explains the limitations of the existing 'files' format (scalability issues with large repositories, atomic read/write problems, inefficient housekeeping, filesystem-specific behavior) and how 'reftable' addresses these by using a new binary format stored in tables. It also highlights improvements to Git tooling, including `--include-root-refs` for `git-for-each-ref` to list all references (including pseudo-refs) and a new `list` subcommand for `git-reflog` to enumerate existing reflogs. Finally, it discusses the optimization of `git pack-refs --auto` for the 'reftable' backend, which leverages self-optimizing heuristics rather than a full repack.
  17. GitLab's contributions to Git 2.44.0This post details GitLab's contributions to Git 2.44.0, specifically highlighting the upstreaming of `git-replay` for in-memory rebasing without requiring a worktree, and improvements to commit-graph object existence checks to prevent performance regressions. It also discusses the ongoing work to prepare Git for a new 'reftable' ref backend, addressing limitations of the current 'files' backend in large monorepos.
  18. The contributions we made to the Git 2.43 releaseGitLab's Git team contributed several features and fixes to Git 2.43: - Added `--filter` and `--filter-to` options to `git repack` for segmenting objects across packfiles, enabling storage optimizations. - Added the `--exists` option to `git show` for a generic way to check object existence, crucial for the reftable backend. - Extended the `--missing` option in `git rev-list` to work with commit objects, supporting Gitaly's next-generation repository replication. - Enabled `gitattributes` to read from HEAD by default in bare repositories, reducing tech debt in Gitaly. - Fixed a bug in `git rev-list --stdin`. - Addressed an issue in commit-graphs where parsed commits weren't always checked for existence, introducing `GIT_COMMIT_GRAPH_PARANOIA`.
  19. Why and how we rearchitected Git object database maintenance for scaleThis post details the rearchitecture of Git object database maintenance within Gitaly to leverage new Git features like cruft packs and geometric repacking. It explains the inefficiencies of the old all-into-one repacks and the challenges with deleting unreachable objects, and how the new strategy addresses these by storing unreachable objects more efficiently and avoiding full rewrites. Real-world results show significant improvements in repository maintenance time and resource usage.
  20. Git 2.42 release: Here are four of our contributions in detailGitLab's Git team contributed to Git 2.42 by adding `--include` and `--exclude` options to `git pack-refs` to manage temporary references for Gitaly's write-ahead logging, implementing the `-Z` option for `git cat-file --batch` to use NUL delimiters for safer input/output parsing, and enabling the passing of pseudo-options via stdin to `git rev-list --stdin` for improved disk usage calculations. They also contributed code style and refactoring improvements to the Git codebase.
  21. Migrating Arch Linux's packaging infrastructure to GitLabArch 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.
  22. GitLab Gitaly project now supports the SHA 256 hashing algorithmThis post details the integration of SHA-256 hashing algorithm support into the Gitaly project, a significant step towards enabling SHA-256 repositories within GitLab. It explains the technical differences between SHA-1 and SHA-256, the security implications of SHA-1's deprecation, and the regulatory drivers for adopting SHA-256. The post also provides practical examples of generating SHA-256 hashes and creating SHA-256 repositories locally.
  23. Git 2.41 release - Here are five of our contributions in detailThis post details three specific contributions from GitLab's Git team to the Git 2.41 release: 1. Addition of a `--porcelain` option to `git-fetch` to enable machine-parseable output, improving efficiency in Gitaly Cluster's repository mirroring by allowing atomic reference updates. 2. Introduction of a `--attr-source=<tree>` option to read Git attribute files directly from a specified tree, simplifying Gitaly's handling of `.gitattributes` for bare repositories and reducing RPC complexity. 3. A bug fix in commit-graph generation numbers to address a regression that corrupted commit-graphs for specific repositories.
  24. Future-proofing Git repository maintenanceThis 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.
  25. Git security audit: Inside the hunt for - and discovery of - CVEsThis post details the discovery and mitigation of CVE-2022-41903, a heap corruption vulnerability in Git's `git archive` command related to `export-subst` attributes and padding specifiers in pretty formats. It describes the collaborative process involving GitLab, X41 D-Sec, and OSTIF, the technical details of identifying the vulnerability through code analysis and proof-of-concept, and the subsequent collaboration with the git-security mailing list for fixes and further fuzzing harness extension.
  26. Take advantage of Git rebaseThis post introduces the `git rebase -i` command as a method to rework commits for cleaner merge requests, improving review efficiency and code quality. It explains the interactive rebase process, including editing commit instructions, continuing or aborting the rebase, and using various instructions like `reword`, `edit`, `squash`, and `fixup`. It also highlights the `--exec` flag for running shell commands (e.g., tests) after each rebased commit, ensuring code integrity.
  27. The new Git default branch nameThis post details the change in GitLab's default branch name from 'master' to 'main' for new projects, aligning with Git project maintainers' efforts and community feedback. It outlines the phased rollout for GitLab.com and self-managed instances, including required actions for users with existing CI/CD configurations referencing the 'master' branch. It also mentions the internal change for the GitLab project's default branch.
  28. How we prevented security fixes leaking into our public repositoriesThis post details a critical fix to GitLab's push mirroring functionality. Previously, the use of `git fetch` for mirroring branches to a private security repository inadvertently exposed Git objects (and thus security fixes) in the public repository. The solution involved switching to `git ls-remote` for branches, similar to how tags were handled, which only retrieves remote references without persisting local objects. This change was implemented and validated through a feature flag experiment, followed by a phased rollout and the eventual removal of the old behavior. A subsequent bug related to `ls-remote` taking too long and causing transient divergence errors was resolved by swapping the order of reference gathering.
  29. How to keep your Git history clean with interactive rebaseThis post details the practical application of Git's interactive rebase command for cleaning up local commit history. It explains how to correct old commit messages, combine multiple commits into one (squashing), and fix mistakes by applying changes from a new commit to an older one (fixup). The post emphasizes that these operations should only be performed on local history before it's shared remotely.
  30. Migrating your version control to Git? Here’s what you need to knowThis post provides guidance on migrating to Git, emphasizing the importance of retaining previous version control systems for history, cloning for testing processes (CI, code review, security testing, release), investing in Git training (command line, branching, GUIs), and selecting a branching strategy (e.g., GitLab Flow). It highlights Git's popularity and its impact on productivity and code quality.
  31. dotfiles - Document and automate your Macbook setupThis 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.
  32. 15 Git tips to improve your workflowThis post provides 15 practical tips for improving Git workflows. It covers creating Git aliases for common commands (`checkout`, `commit`, `branch`), visualizing repository status in the terminal prompt, comparing commits using `git diff` and `git difftool`, stashing uncommitted changes with `git stash`, the importance of frequent pulling to avoid conflicts, enabling command autocompletion, setting up a global `.gitignore` file, enabling Git's `autosquash` feature, automatically deleting local branches removed from 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` and `git checkout`, utilizing the `git-open` plugin to visit repository websites, and exploring the `git-extras` plugin for additional commands.
  33. The problem with Git flowIntroduces 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.
  34. How to tidy up your merge requests with GitThis post details techniques for tidying Git merge requests by consolidating commits. It introduces `git reset --soft HEAD~2` to revert commits while preserving changes, `git commit --fixup <commit-hash>` to create fixup commits, and `git rebase -i --autosquash <commit-hash>` to apply these fixups. It also mentions `git commit --amend` as an alternative for single-commit amendments and highlights the necessity of `git push --force` when rewriting history on remote repositories.
  35. Git Protocol v2 now enabled for SSH on GitLab.comEnabled Git Protocol v2 over SSH on GitLab.com, following its earlier enablement over HTTP. This protocol improves fetch performance and enables future protocol improvements. The post provides commands to compare network traffic between Protocol v0 and v2, demonstrating a significant reduction in lines sent.
  36. Git happens! 6 Common Git mistakes and how to fix themThis post details six common Git mistakes and their solutions: correcting commit messages (`git commit --amend`), adding forgotten files to the last commit (`git add <file> && git commit --amend`), removing unwanted staged files (`git reset <file>`), undoing commits to a wrong branch (`git branch <new-branch> && git reset HEAD~ --hard && git checkout <new-branch>`), renaming branches (`git branch -m <old-name> <new-name>`), and using `git reflog` as a last resort to recover from corrupted repositories. It also touches on Git repository security and preventing repository bloat.
  37. How (and why!) to keep your Git commit history cleanThis post details how to manage and clean Git commit history using interactive rebase (`git rebase -i`). It covers scenarios for changing the most recent commit (`git commit --amend`), changing specific commits (`git rebase -i` with `edit`), and combining/fixing up multiple commits (`git rebase -i` with `fixup` or `squash`). It also emphasizes the importance of clear commit messages and the use of `git push --force-with-lease` when rewriting history.
  38. Git: Not just for developersThis post details how Eko uses GitLab CE to enable non-developers (video editors, designers) to collaborate on Interactive Video projects using Git as a backend. Eko Studio acts as a Git client, translating user actions into Git commits. Developers use standard Git clients. GitLab's API and webhooks are leveraged to connect Eko's infrastructure, and the open-source nature allowed for minimal changes. The use of GitLab CE's AMI simplified instance setup.
  39. Axosoft launches GitKraken integration with GitLabThis post details the integration of GitKraken with GitLab, enabling users to manage SSH keys, initialize new repositories directly on GitLab.com, clone GitLab repositories, and display remote avatars within the GitKraken GUI. This integration leverages GitLab's API for remote repository management and SSH key operations, enhancing developer productivity by reducing context switching.
  40. Tower launches GitLab integration on WindowsThis post details the integration of GitLab with the Tower Git client for Windows. It highlights features like a Services Manager for account management and cloning, productivity boosters such as automatic fetching and stashing, and an Undo and Conflict Wizard for resolving merge conflicts visually. It also mentions beginner-friendly features and advanced options for professionals, and offers a discount for users purchasing Tower with the GitLab integration.
  41. Git tips and tricksThis post provides a collection of Git tips and tricks used daily at GitLab, aimed at improving developer workflows. It covers utilizing Git's built-in help commands (`git help`, `git help -g`), setting up terminal prompts with `git-prompt.sh`, enabling autocompletion for Git commands, and exploring useful Git plugins like `git-extras` and `git-open`. It also details various `.gitconfig` settings, including global `.gitignore`, automatic pruning of stale branches, enabling autosquash for rebasing, displaying submodule summaries, changing the default editor, and configuring diff tools. The post emphasizes learning and leveraging Git's extensive capabilities for more efficient development.
  42. How to keep your fork up to date with its originThis post introduces and details the setup of GitLab's repository mirroring feature to automatically keep a fork up-to-date with its upstream repository. It explains the problem of manual updates leading to merge conflicts and presents repository mirroring as a solution. The post outlines the steps to configure mirroring in project settings, including adding the upstream Git repository URL and setting up a mirror user. It also specifies the necessary visibility settings for the upstream project to allow unauthenticated pulls.
  43. Customer Story: Stack OverflowThis post details how Stack Overflow adopted GitLab as their primary source control solution, superseding Git-web and Kiln due to GitLab's performance improvements. They use it on-premises and self-managed, integrating with Team City for CI. Stack Overflow developers have experienced increased development time, quicker code reviews, and easier collaboration. They are also part of ongoing GitLab developments and have seen an increase in the use of merge requests. The team uses LDAP integration and is implementing GitLab Geo for multi-datacenter replication, with ongoing analysis.
  44. Notes from the Git Merge Core Contributors SummitThis post details GitLab's participation in the Git Merge Core Contributors Summit. Key technical discussions included scaling Git for larger repositories and improving checkout performance through techniques like repacking. The post also touches on growing Git adoption via web interfaces and the importance of protecting the Git trademark. It mentions ongoing work on submodules, including potential UI and initialization improvements, and parallel download enhancements. The development of 'Submit Git', a Scala app bridging GitHub pull requests with the Git mailing list for patch submission, is also highlighted.
  45. Feature Highlight: Create files and directories from the Files pageThis post introduces the capability to create new files, upload files, create new directories, create new branches, and create new tags directly from the GitLab UI's file browser. It details the user interface elements and workflows for each of these actions, including options for committing changes, starting new merge requests, and adding commit messages and release notes. This enhances the developer experience by providing in-browser Git operations.
  46. Did you install GitLab from source? Check your Git versionThis post addresses a specific security vulnerability (CVE-2014-9390) in Git, highlighting that installations of GitLab from source using Git 2.1.2 are vulnerable. It instructs users to check their Git version and upgrade if necessary, emphasizing that Omnibus packages are not affected. The post also notes that while GitLab itself is not affected, a vulnerable Git version on a GitLab server could be used to deliver poisoned Git repositories to users on vulnerable systems.
  47. 8 Tips to help you work better with GitThis post provides practical tips for improving Git workflow efficiency. It details how to configure Git aliases for common commands (`checkout`, `commit`, `branch`), use `git stash` to temporarily store uncommitted changes, compare commits using `git diff` and `git difftool`, reset files to previous states with `git reset --hard HEAD` or `git checkout HEAD -- path/to/file`, and use `git blame` more efficiently with flags like `-w`, `-M`, and `-C`. It also advises on frequent pulling from the master branch to avoid merge conflicts and committing often without pushing every commit, recommending pushing only after changes are tested and tests pass.
  48. GitLab Annex enables versioning of large binaries with gitThis 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.
  49. 3 reasons GitLab isn't vulnerable to Gollum + 1 tipThis post details how GitLab avoids a specific Remote Code Execution (RCE) vulnerability in the Gollum wiki by not using Gollum's search functionality, by using `Shellwords.shellescape(query)` for search queries, and by switching to the Rugged library instead of Grit. It also recommends adopting secure coding guidelines for Ruby developers to prevent similar vulnerabilities.
  50. How GitLab Permissions and Protected Branches Keep Your Code SafeThis post introduces GitLab's permission system, defining roles from Guest to Owner with varying levels of access to repositories and branches. It details the implementation of Protected Branches, which prevent force pushes and deletions on critical branches, enforcing code review workflows via merge requests. The underlying authorization mechanism is explained, highlighting the use of the 'Six' gem and its 'Ability' class for defining and checking user permissions. The post emphasizes how these features protect code from accidental misuse, such as the Jenkins incident described, and promote better collaboration.
  51. WANdisco integrates GitLab Enterprise in Git MultiSiteThis post announces a partnership between WANdisco and GitLab to integrate WANdisco's Git MultiSite with GitLab Enterprise Edition. Git MultiSite leverages WANdisco's active-active replication and Distributed Coordination Engine (DConE) to enable writable Git peer nodes at every location, removing bottlenecks in Git's master repository architecture. This provides 100% uptime and LAN-speed performance for distributed development teams, with transparent conflict resolution. The integration aims to provide a scalable, cost-effective solution for global collaboration on code review and repository management.