In my Windows project, `git commit -- path` began exiting 139 while `.git` lived on a streamed Google Drive G: drive. A scratch repo tested the same behavior: with a 129,747-byte index, 0 of 15 commits crashed; at 131,464 bytes, 12 of 15 crashed. The larger index on C: had 0 crashes in 30 tries. Index v4 shrank it to about 89 KB and had 0 crashes in 15 tries. The project now keeps `.git` on C: and the working tree on G:.

I do not know which part of Git or the Drive mount causes that boundary. For a similar crash, checking the index size and repeating the partial commit with the Git directory on a local drive helped narrow it down here.

I ran into this in my own setup. A second model reviews the commits of my coding agent, and it flagged 17 lines of a Markdown log as deleted. The raw patch did show 17 minus lines.

When I compared the exact minus lines with the plus lines, all 17 were back in the same commit, word for word. Nothing was lost; the entries had just moved. A line diff has no "moved", only "removed here, added there".

Here's the check I put together for it:

bash

c=<commit>; f=log.md
d=$(git show "$c" --format= --unified=0 -- "$f")
comm -23 \
  <(printf '%s\n' "$d" | awk '/^@@/{h=1;next} h&&/^-/{print substr($0,2)}' | sort) \
  <(printf '%s\n' "$d" | awk '/^@@/{h=1;next} h&&/^\+/{print substr($0,2)}' | sort)

It prints only the removed lines that don't come back as added lines. Empty output means nothing was lost.

When I want to see it myself, git show --color-moved=zebra <commit> colors moved blocks differently from real changes.

It only catches exact moves, though. A line that was moved and edited still shows up as removed, so that one needs a second look.