Git's autostash replays a three-day-old working tree over the fix it just fetched

A stash is a diff, and a diff carries no age ^[7]. That is the whole of it. Autostash saves the dirty tree, moves HEAD to the fetched upstream tip, then replays the saved diff over the files it just wrote ^[7]. If your stale hunks and upstream's hunks sit in different regions of the file, the three-way merge succeeds and nothing in the result marks which lines came from the fetch and which came from your tree ^[7]. In the author's reproducer, `tool.sh` ends up with the fetched fix on line one and the working copy's three-day-old footer at the bottom, while `git show HEAD:tool.sh` still holds the committed line ^[4][5].

The timestamp follows from the same mechanism. The replay is a write, and the write happens now, so `stat` and `date -u` agree to the second ^[6]. Arithmetic on the two facts the post supplies: the content is three days old, the mtime is the current second, so the file's timestamp understates the age of that line by roughly 72 hours ^[13]. Ilya Mozerov, writing on dev.to, notes that his earlier argument was that mtime can lie; this post names a binary in everyone's `$PATH` that makes it lie as a convenience feature ^[14].

Now the channel a script actually reads. The clean replay exits zero ^[3]. The conflicted replay prints "Applying autostash resulted in conflicts", leaves `UU tool.sh` and three lines of whitespace-and-marker complaints from `git diff --check`, and also exits zero ^[8]. So the exit status distinguishes neither case from a healthy pull ^[12], which is why `git pull && make` walks straight through both, as the author puts it ^[10]. Git does say so, but only in a line of text on stdout; the exit status carries none of it.

Reaching this failure mode takes several conditions lining up at once: `pull.rebase` and `rebase.autoStash` both set ^[1], upstream ahead of you, a dirty tree at the moment you pull, and hunks that do not collide ^[7]. A team that only pulls clean never fires the path. Treat the reproducer as a claim about a config pair, not about git being broken.

For me, the forensics settle it. In the conflict case git says your changes are safe in the stash, and they are ^[8]. In the clean case it drops the stash: `git stash list` is empty, there is no stash reflog, and the only remaining record is a dangling commit awaiting `git gc` ^[9]. So in my repos autostash stays off and a dirty pull is allowed to fail. If you keep it on, the cheap mitigation is a wrapper that captures the hash git prints on the way in, from `Created autostash: 627da2a` ^[3], and logs it before it becomes unreachable ^[9].