Reach for git whatchanged when you have inherited a script that already calls it and need to know what it will show you. This guide covers inspecting the changes introduced by commits, either as patches or as compact raw records, while limiting the report to the paths you care about. The examples match the installed Git 2.43.0 and git-man 2.43.0-1ubuntu7.3 on this machine.
Allow about ten minutes. You need Git and a repository with at least one commit. All commands here are ordinary, read-only inspection commands. They do not need sudo, and they do not change commits, the index or the working tree.
Checkpoint: this is a historical command. The current upstream documentation deprecates git whatchanged and says it is scheduled for removal. For new scripts, prefer the equivalent git log --raw --no-merges. Use git-whatchanged when maintaining an established workflow or reproducing its traditional defaults.
Check the binary before relying on output details. This matters when a guide, script or incident record was written for a different Git release:
$ git --version
git version 2.43.0The command is invoked as git whatchanged, with a space. There is no separate executable that you normally run as git-whatchanged. If the version differs, check that release's documentation before making a parser depend on exact wording or formatting.
Run the command from the repository whose history you want to inspect:
$ git whatchanged
commit 0123456789abcdef0123456789abcdef01234567
Author: Example User <[email protected]>
Date: Thu Sep 24 06:18:18 2026 +0100
append second line
:100644 100644 5626abf 814f4a4 M notes.txtYour commit ID, author, date and paths will differ. The useful default is that each commit is followed by raw change records. A record includes the old and new modes, abbreviated object IDs, a status letter and the affected path. For example, M means modified and A means added.
Unlike ordinary git log, whatchanged defaults to raw diff output and skips merge commits. It shows commit history as well as the files changed by each selected commit. That default is the main reason old scripts may still use it.
Use -p when you need the actual line-by-line changes. This example examines commits after a starting revision and limits the result to two directories:
$ git whatchanged -p v2.6.12.. -- include/scsi drivers/scsiReplace v2.6.12 with a tag, branch, commit ID or other revision that exists in your repository. The two dots select commits reachable from the current end of the range but not from its starting point. Replace the paths with real paths in your repository.
For one known commit, a smaller range is easier to review:
$ git whatchanged -p HEAD^..HEAD -- notes.txt
commit 0123456789abcdef0123456789abcdef01234567
...
diff --git a/notes.txt b/notes.txt
index 5626abf..814f4a4 100644
--- a/notes.txt
+++ b/notes.txt
@@ -1 +1,2 @@
one
+twoThe exact header and commit ID vary. The added line begins with a plus sign in the patch. Keep the -- separator before paths so a name that resembles a revision cannot be mistaken for one.
Use a history option when the question is time-based. This command reports changes to gitk during the last two weeks:
$ git whatchanged --since="2 weeks ago" -- gitkThe separator is required when the path could be confused with a branch name. If your repository contains a branch called gitk, the separator makes the intention unambiguous: search for the file or directory named gitk, not the branch.
Other revision and path filters can be combined, but add one constraint at a time while investigating. First confirm that a broad command finds the commit, then add the date, revision range or path filter. An empty report can mean no commit matches, the path is wrong, or the requested range excludes the change.
Use the raw default for a quick history scan or for a human-readable record of which paths changed. Use -p when you must review content, explain a regression or copy a small change into an incident note.
For new automation, use the documented modern equivalent explicitly:
$ git log --raw --no-merges --since="2 weeks ago" -- notes.txtThat expresses the two special whatchanged defaults directly: raw diff records and no merge commits. It is easier for a reader to recognise as ordinary git log, and it avoids building a new dependency on a deprecated command.
Do not parse the normal display as if it were a stable machine interface. If a tool needs dependable data, investigate Git's machine-oriented formats and test against the Git versions you support. This guide stays with the documented human-facing forms because their purpose is inspection.
git status to confirm where you are, then try git whatchanged -1. If that works, add the revision, date or path restriction again.-- before paths. This matters especially for commands such as git whatchanged --since="2 weeks ago" -- gitk.whatchanged skips merges by default. If a merge is the subject of the investigation, use git log with options chosen for that question rather than assuming the historical default is suitable.-p and rerun the same selection. Do not mistake a raw record for proof of what the changed lines were.For a focused review, run both representations over the same selection and compare the commit and path:
$ git whatchanged -p HEAD^..HEAD -- notes.txt
$ git log --raw --no-merges HEAD^..HEAD -- notes.txtThe first command should show the patch. The second should show the same selected commit and path in raw form. If they select different commits, check the revision range, current branch and path spelling. If the first shows no patch, confirm the range actually contains a change to that path.
There is no undo step because these commands only read history. They do not create files or alter Git data. If you redirect output to a file for an incident record, choose a new filename or use a temporary file first so shell redirection cannot truncate an existing report.