How to find which Git commit last changed a line

A retry limit in a configuration file looks wrong. Before editing it, you want to know when it changed and what the commit was trying to fix. Start with git blame for the line, then inspect the commit patch. Both commands let you investigate without switching branches or rewriting history.

Find the commit for one line

Run this from the repository root, replacing the example path with your tracked file. The quotes keep a path containing spaces together:

git blame --date=short -L 2,2 -- "app config.txt"

-L 2,2 selects line 2 only. For lines 10 through 20, use -L 10,20. The separator -- marks the following argument as a file path.

In a small test repository, line 2 was changed from retries=2 to retries=5. The command produced:

da07bf05 (Tutorial Author 2026-11-09 2) retries=5

The first field identifies the commit. The parentheses contain the recorded author, date and line number, followed by the line itself. Your hash and author will differ. Blame identifies the last attributed change to that surviving line; it does not establish who introduced a bug or explain the decision. The Git blame reference describes line ranges and attribution options.

Read the patch before drawing a conclusion

Copy the commit hash from your own result. In the example repository, the next command is:

git show da07bf05 -- "app config.txt"

Replace da07bf05 with your commit hash. The relevant patch in this example contains:

-retries=2
+retries=5

The minus line shows the previous value and the plus line shows the replacement. Read the commit message and surrounding patch too. A timeout change elsewhere in the same commit may explain the retry adjustment. The Git show reference covers viewing commit messages and changes.

Look past a whitespace-only edit

A later formatting commit changed the example to retries = 5. Ordinary blame then pointed to the formatting commit. To compare while ignoring whitespace changes, try:

git blame -w -L 2,2 -- "app config.txt"

In the tested example, this reached the earlier retry-limit commit. Check both patches if spacing can affect your file's meaning. Ignoring whitespace is an investigative option, not a reason to dismiss a change automatically.

Handle a line you edited locally

When the working-copy line was changed to retries = 9 without a commit, blame displayed an all-zero hash and Not Committed Yet. There is no saved commit for that local version. To inspect the committed version instead, specify HEAD:

git blame HEAD -L 2,2 -- "app config.txt"

Line numbers here belong to the committed file. If local edits inserted or removed lines, check that you selected the intended line. These inspections leave the file and staging state alone. If staged edits are confusing the comparison, see why git diff can be empty after git add.

Trace the file's earlier changes

For the history of one file, including earlier names when Git can follow its renames, use:

git log --oneline --follow -- "app config.txt"

This lists commits for the file, not only the selected line. Use its results to inspect older patches. The Git log reference documents the single-file scope of --follow. Blame also follows whole-file renames automatically, while copied or moved blocks can need additional investigation.

Blame cannot annotate a line that has already been deleted from the version you are examining. Inspect an older revision or the file's patches in that case. If the behavior differs between branches, continue with comparing branches without switching. Keep the line attribution, commit explanation and actual behavior as separate pieces of evidence.