Home / Alt manpages / git-log(1)

  • git-log(1)
  • User command
  • linux

Search git log Without Losing the Plot

Someone asks what changed since Tuesday, and git log is how you look useful in ten seconds instead of scrolling forever. This guide takes you from a plain recent log to filtering by branch, file, author, date and message, plus the traps that catch people out along the way. The examples use Git 2.43.0, the version installed with the local git-man package. Allow about 10 minutes for the first pass. You need a Git working tree and ordinary read access to it. None of the commands below needs elevated privileges.

1. Get a readable recent log

Move into the repository you want to inspect, then ask for the latest commits in compact form:

cd /path/to/repository
git log --oneline --decorate -n 12
  • --oneline squashes each commit down to an ID and a subject line.
  • --decorate tags commits with useful names such as HEAD, branch names and tags.
  • -n 12 caps the result at twelve commits, so a large repository does not immediately fill your terminal.

The default order is reverse chronological: the newest reachable commit appears first. Expected output has one commit per line, although the exact IDs and subjects depend on the repository:

7f3a1c2 (HEAD -> main) Document the backup check
2b91e44 (tag: v1.4.0) Release 1.4.0
...

Checkpoint

If this prints commits, the repository is ready for the narrower searches below. If Git says it is not a repository, repeat cd with the directory containing its .git data.

2. See the branch relationship

To see branches and merges as a map, add --graph and include all local refs:

git log --oneline --decorate --graph --all -n 30

--all includes commits reachable from every local and remote-tracking reference this checkout knows about. The graph characters show parent links, not a chronological table, and the output can get busy fast in an active repository. Start with a small -n value and raise it only when you need more context.

To ask what is on your current branch but not on a remote-tracking branch, use the two-dot range:

git log --oneline origin/main..HEAD

This means commits reachable from HEAD after excluding commits reachable from origin/main. An empty result means this checkout has no commits in that direction. It does not prove the remote is up to date: the name is only as current as your last fetch.

3. Narrow history by file or directory

Put -- before a path when you want commits that touched it:

git log --oneline --follow -- src/config.toml

The separator stops a path being read as a revision or option. --follow continues one file's history across renames, so it only works with a single file. Drop it for a directory or several paths:

git log --oneline -- src/ tests/

A path limits which commits are listed, not whether you see the patch. Add -p for the actual diff:

git log -p -n 3 -- src/config.toml

With a path, the patch itself is normally limited to that path too. --full-diff keeps the same commit selection but shows the full diff for each one, which matters when a commit touched several files and you need the complete change, not just the slice that matches your path.

4. Find commits by person, date or message

Stack independent filters to cut a long history down to something useful:

git log --oneline --author='Alex Example' --since='2026-01-01' --grep='backup' --regexp-ignore-case
  • --author matches an author pattern; --committer filters the committer instead, and they are not always the same person.
  • --since (alias --after) keeps commits after a date; --until (alias --before) sets the other boundary.
  • --grep searches commit messages, case-sensitively unless you add --regexp-ignore-case, as above.

For a quick count or first result, combine the filters with a limit:

git log --format='%h %ad %an %s' --date=short --since='30 days ago' -n 20

The --format string controls each line: abbreviated hash, short author date, author name and subject. If you need machine-readable output, pick a format on purpose rather than parsing the default multi-line display.

5. Inspect one commit safely

Once a log gives you a commit ID, inspect it without touching the worktree:

git show --stat --summary 7f3a1c2
git show --format=fuller --find-renames 7f3a1c2

The first gives a compact file summary. The second shows commit metadata and patch, and asks Git to detect renames while it displays them. Swap in an ID from your own log. git log -p can also show patches, but git show is usually the clearer tool once you have picked one object.

To trace a line range in one file, use -L:

git log -L 20,45:src/config.toml

This follows lines 20 to 45 from a single starting revision and implies patch output. It cannot be combined with a path limiter, and those lines must actually exist in the starting revision. Treat it as a focused investigation tool, not a general replacement for a file log.

6. Avoid the common interpretation traps

  • Reachability is not just a date search. A normal log walks parent links from the revisions you name. A commit on another branch is absent unless that branch is reachable from your starting point, or you pull it in with --all or an explicit ref.
  • Ranges are set operations. A..B means B excluding commits reachable from A. A...B shows the symmetric difference, which is handy for comparing two lines of development around their merge base.
  • Paths come after revisions. Without --, a name can be read as a revision. With it, everything after the separator is a path specification.
  • Names can be stale. If origin/main matters, fetch first and repeat the log. Fetching updates remote-tracking refs; it does not rewrite your commits or merge anything into your branch.
  • Formatting changes the display, not history. Options such as --oneline, --pretty, --date and --decorate affect what you see. They do not alter a single commit.

7. Verify the question you actually answered

Before you drop a result into a ticket or release note, rerun the command with an explicit revision and path where you can:

git log --format='%H %ad %an %s' --date=iso-strict origin/main..HEAD -- src/
git rev-parse --show-toplevel

The first makes the full commit IDs and date format visible. The second confirms which working tree you inspected. If the range is empty, say so rather than treating a blank display as a command failure. Run git fetch origin first if you need current remote state and a network operation is acceptable, then rerun the comparison. Nothing in this guide writes files, resets refs or discards work, so there is no undo needed.

Done means

  • Recent log: you can produce a short, decorated log of recent commits on demand.
  • Ranges understood: you can explain what each side of a two-dot range includes.
  • Filters applied: you can filter by file, author, date and message without confusing a path for a revision.
  • Safe inspection: you can inspect a commit or line range without changing the working tree.
  • Checked before quoting: you verify the repository and range before relying on the result.