Git file history stops at a rename: read patches with one-path follow

By ON Lab · Sources checked November 8, 2026

To inspect changes to one current file across a detectable rename, start with git log --follow -p -- "path/to/file". -p asks for patches; --follow asks Git to continue beyond renames for one file. A plain path-filtered log can stop at the change of name even though earlier commits still exist.

Two historical reader questions distinguish these needs: one wanted the actual content changes rather than a commit list, and another asked about history across renames. We checked the current git-log documentation and created a disposable repository with an unchanged rename between edits. The example does not prove complete tracing through arbitrary copies, rewrites or merges.

Choose the current path and separate it from options

git log --oneline -- "new notes.txt"
git log --follow --oneline -- "new notes.txt"
git log --follow -p -- "new notes.txt"

These examples use a POSIX-style shell and a filename containing a space. Quote the whole path so it remains one argument. The double hyphen marks the boundary before the path. Put log options such as --follow before that boundary; after it, a name that looks like an option is treated as a path instead.

Use one file with --follow. The official documentation limits that option to a single file. A directory request or a collection of paths is a different history query. First make the narrow query understandable before adding author filters, date limits or revision ranges.

What our four-commit fixture showed

We created a new local repository and made four commits: create an original file, edit it, rename it without changing its contents, and edit the new path. No real repository or remote was modified. The same installed Git read the resulting history.

The rename did not erase the original commits. The difference came from how the history request selected and followed paths. Reading only commit subjects could not show the exact line change; adding patch output addressed that separate need.

This fixture intentionally used a simple linear history and an unchanged rename. Real repositories may combine a move with extensive editing, contain merges or reuse old names. Those cases require reading the actual commits and rename detection results rather than treating the fixture as a guarantee.

Read the patch and its path labels

For each relevant entry, compare the commit identity, old and new path labels, and lines marked as removed or added. A rename may include metadata describing the two paths and a similarity assessment. Do not infer that two unrelated files are the same merely because their names resemble each other.

If you only need one known commit after locating it, inspect that commit with its relevant path. Keep the revision before the double hyphen and use the path that exists in that revision's change. Asking an old commit about a new pathname that did not yet exist can produce an empty path-filtered result.

git show COMMIT -- "path/used/in/that/change"

COMMIT and the path are placeholders to replace with reviewed values. This is an inspection command. There is no need to reset, restore, amend or rename files in your working tree to view an earlier patch.

If earlier history still looks missing

1. Confirm the exact path and the revision or branch you are inspecting.
2. Remove unrelated date, author or message filters for the first diagnostic query.
3. Read the rename commit itself and check both path names.
4. Inspect the earlier pathname explicitly at a suitable known revision.
5. Record whether the repository contains the earlier commits and whether the history involves merges or major rewrites.

git-log starts from the selected revisions and walks reachable commits. A query from the wrong branch or a repository that does not contain earlier objects cannot establish the missing changes just by adding a display flag. --all changes the starting references and can bring in other branches; it is not a general promise of the file's one true history.

Rename following also depends on recognizing relationships between content. Do not respond to every missing entry by permanently changing global detection settings or rewriting history. Preserve the first command and output, then construct a small case that isolates the missing transition.

Keep reading history separate from recording a new rename

If your task is to make Git record a case-only filename change, use the separate case-only rename and index guide. That changes the current staged state. The commands here inspect existing commits and their patches.

Likewise, an empty default diff concerns differences among the working tree, index and commit. A file-history query concerns prior commits. Avoid altering current work to repair what may only be a filtered history display.

Checked November 8, 2026. The simple rename and patch comparison was executed locally. Graphical clients, complex merge histories and the original readers' repositories were not tested; the historical questions are not measured current demand.

Sources

• git-scm.com: source guidance
• git-scm.com: source guidance
• stackoverflow.com: source guidance
• stackoverflow.com: source guidance