Introduction

There are two different questions hidden inside “get the diff between all commits between two dates.” One is “show me each commit and its patch during that date range,” and the other is “show me the net code difference between the repository state at the start and end of that date range.” Git supports both, but with different commands.

Core Sections

Show the commits that happened in the date range

To list commits between two dates, use git log with --since and --until.

git log --since="2025-01-01" --until="2025-01-31" --oneline

If you want the actual patch for each commit, add -p.

git log --since="2025-01-01" --until="2025-01-31" -p

This answers the “show me what each commit changed” version of the question.

Get the net diff across the date range

If you want the overall difference between the repository state before the first relevant commit and after the last relevant commit, first identify the boundary commits, then diff them.

A practical workflow is:

git rev-list -1 --before="2025-01-01 00:00" HEAD
git rev-list -1 --before="2025-01-31 23:59:59" HEAD

Those commands give you commit ids for the repository state before each date cutoff. Then diff them:

git diff <start-commit> <end-commit>

That answers the “what is the cumulative effect across this period” version of the question.

Use --stat when full patches are too noisy

For large date ranges, a full patch can be overwhelming. A summary is often more useful first.

git log --since="2025-01-01" --until="2025-01-31" --stat

Or for the net diff:

git diff --stat <start-commit> <end-commit>

This gives you a compact summary of which files changed and how much.

Restrict by branch or path if needed

Date-based history can include many unrelated commits if your repository is active. You can narrow the result to a branch tip or a subdirectory.

Another useful variation is to compare only merge commits in the period if you are preparing release notes or auditing integrations. That changes the question from “every commit” to “every integrated change set,” which is often closer to what release reporting actually needs.

git log main --since="2025-01-01" --until="2025-01-31" -p -- src/

That is useful for release notes, audits, or component-specific reviews. It also keeps patch output small enough to review without losing the thread of what changed during the period.

Be clear about timezone and inclusivity

Dates in Git are interpreted in the local environment unless you specify more detail. If the exact cutoff matters, use timestamps with times and timezones, especially in CI or shared reporting scripts.

For example:

git log --since="2025-01-01T00:00:00+00:00" --until="2025-01-31T23:59:59+00:00"

That avoids subtle off-by-one-day misunderstandings when team members run the same command in different locales.

Common Pitfalls

• Asking for a “diff between dates” without deciding whether you need per-commit patches or one cumulative net diff.
• Using git log -p when what you actually wanted was the total repository delta from the beginning of the period to the end.
• Forgetting that date filters apply to commit timestamps, not to some abstract release boundary unless the history matches that boundary.
• Ignoring timezone details when the cutoff dates matter precisely.
• Reviewing a huge date range without narrowing by branch or path, which makes the output much harder to interpret.

Summary

• Use git log --since ... --until ... -p to show each commit’s patch in the date range.
• Use boundary commits plus git diff start end to show the cumulative effect across the period.
• Add --stat when you want a concise summary first.
• Narrow by branch or path when the repository history is broad.
• Be explicit about timestamps if the date boundaries matter exactly.