---
title: "Git: my git stash -p optimization in Git 2.55"
url: https://daily.dev/posts/git-my-git-stash--p-optimization-in-git-2-55-5z1hilnp7
source_url: https://adamj.eu/tech/2026/08/07/git-stash-p-optimization-story
type: article
source: "Adam Johnson"
published: 2026-08-07T20:10:22.615Z
updated: 2026-08-07T20:10:51.948Z
tags: ["general-programming", "open-source", "performance", "git"]
reading_time: 5
upvotes: 14
comments: 1
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Git: my git stash -p optimization in Git 2.55

**[Adam Johnson](https://daily.dev/sources/adamj)** · 5 min read · 14 upvotes · 1 comments

## Summary

A developer contributed a performance optimization to Git 2.55 that speeds up `git stash -p` by 53× in large repositories. The root cause was that `git stash -p` built a temporary index via a `git read-tree HEAD` subprocess, producing an index with no cached stat data or fsmonitor validity bits, forcing Git to `lstat()` every file before showing the first interactive prompt. The fix replaces the subprocess with an in-process function using `oneway_merge()` to copy cached index entries, allowing unchanged files to be skipped. In a monorepo with ~200,000 files, time-to-first-prompt dropped from ~35 seconds to ~0.66 seconds. The patch was developed with AI assistance (GPT 5.5 and Claude 4.8), reviewed by Git maintainer Junio Hamano, and shipped in Git 2.55 (released June 2026). A performance test with 100,000 files confirmed the improvement: mean time dropped from 6.90s to 0.55s without fsmonitor, and from 6.83s to 0.28s with it.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://adamj.eu/tech/2026/08/07/git-stash-p-optimization-story>

## Questions this post answers

### Why is `git stash -p` so slow in a large monorepo?

`git stash -p` was slow because it built its temporary index by spawning a `git read-tree HEAD` subprocess, which produced an index with no cached file stat data and no fsmonitor validity bits. When the patch-selection machinery later refreshed that index, Git had to `lstat()` every single file — ~200,000 in one large monorepo — before showing the first prompt. Git 2.55 fixes this by building the index in-process, reusing cached entries.

_Teams hitting this in large repos can track Git version rollouts on daily.dev._

### What changed in Git 2.55 to make `git stash -p` faster?

Git 2.55 replaced the `git read-tree HEAD` subprocess in `stash_patch()` with an in-process function using `oneway_merge()` to copy cached index entries for paths matching HEAD. This preserves cached stat data and fsmonitor validity bits, so the index refresh can skip unchanged files. In a test repo with 100,000 files, mean time dropped from 6.90s to 0.55s without fsmonitor, and from 6.83s to 0.28s with fsmonitor enabled.

_Developers upgrading Git in CI or local tooling can follow Git release coverage on daily.dev._

## Community discussion

Top comments from developers on daily.dev.

**@agustinbarrientos** · 0 upvotes

> Nice work. Fifty-three times faster is wild

## Similar posts on daily.dev

- [Highlights from Git 2.55](https://daily.dev/posts/highlights-from-git-2-55-rp044xsqm) · GitHub Blog · 81 upvotes · 11 comments
- [Staging patches with git add](https://daily.dev/posts/staging-patches-with-git-add-mi2ryspiw) · Hacker News · 0 upvotes · 0 comments
- [Git Stashes](https://daily.dev/posts/git-stashes-zj1renzdr) · RUBYLAND · 32 upvotes · 0 comments

---

Tags: [#general-programming](https://daily.dev/tags/general-programming), [#open-source](https://daily.dev/tags/open-source), [#performance](https://daily.dev/tags/performance), [#git](https://daily.dev/tags/git)

[View this post on daily.dev](https://daily.dev/posts/git-my-git-stash--p-optimization-in-git-2-55-5z1hilnp7)