How do I get the total number of unique lines changed in a commit?

[khalkie]

Select Topic Area

Question

Body

Hi there, I had a question about how to interpret Git commit stats.

I'm trying to calculate the total number of lines changed in a commit, however IIUC Git is treating each edit as an addition and a deletion (despite changing the same line), making it indistinguishable from a new line being created and a separate one being deleted (which I would consider two lines changed.

i.e. I updated one line, and added another line

Additions = 2
Deletions = 1
Total Changes = 3

Two lines were changed (the new line and the updated line).

In another commit, I deleted one line and added two new lines

Additions: 2
Deletions: 1
Total changes: 3

Three lines were changed

Is there any way from Git stats or otherwise to determine the actual number of lines which were changed?

[KALYANI100]

Ah, this comes down to Git’s philosophy and design trade-offs. It’s not that Git couldn’t provide “unique lines changed,” but it chooses not to for several practical reasons:

---

1. Git treats changes as a series of diff operations

Git fundamentally stores content as snapshots of files, not “line edits.” When you make a commit:

• Git stores the new version of the file.
• When you run git diff, Git calculates what lines are added and removed to get from one snapshot to another.
• A line modification is inherently a deletion + addition in Git’s diff algorithm.

Reasoning: this is simple, unambiguous, and efficient for storage, merging, and patch application. Trying to infer “unique lines changed” would require Git to do extra computation and maintain more metadata about “modified vs new/deleted lines,” which Git doesn’t track natively.

---

2. Ambiguity in “line changed”

Consider this diff:

-line a
-line b
+line x
+line y

• Are two lines changed, or one line replaced and one deleted?
• If Git tried to report “logical lines touched,” there’s no single correct answer. Different heuristics could give different numbers.

Git avoids this ambiguity and leaves it to tools or scripts if you want a more human-friendly “lines touched” metric.

---

3. Performance and simplicity

Git is designed for speed at massive scale. Counting “unique lines changed” precisely for every commit could:

• Slow down commands like git log --stat or git diff
• Complicate the storage format and diff engine
• Add complexity without being strictly necessary for version control

---

4. Workarounds exist

While Git itself doesn’t give “unique lines changed,” you can:

• Use git diff --numstat + take max(additions, deletions) → approximate logical lines changed
• Use external scripts in Python, shell, or tools like diffstat or git-quick-stats
• Use advanced diff algorithms like patience or histogram to get better “logical” diffs

---

💡 Bottom line: Git prefers to be simple, fast, and unambiguous. “Unique lines changed” is a heuristic interpretation, not something Git can know exactly without extra processing.

---

Hope that helps !!

[anshG2003]

You’ve hit on the fundamental way Git views the world: Git does not "edit" lines. It only knows how to remove an old version of a line and insert a new one. To Git, an "update" is just a deletion and an addition happening at the same coordinate.

If you want to distinguish between a replacement (edit) and a pure addition/deletion, you have to look at the "hunk" structure of the diff rather than the raw integers.

---

The Logic: Why the Math is Tricky

Git provides stat data (like git show --stat), which gives you:

• $A$: Total Additions

• $D$: Total Deletions

• $M$: Total Changes ($A + D$)

As you noted, this math treats an edit ($1A, 1D$) the same as a line move or a random deletion elsewhere. To get the "Actual Lines Impacted," you need to find the overlap.

How to Calculate "Actual Lines Changed"

To find the number of unique lines in the file that were touched, you can use this logic:

1. Identify Edits: An edit is the minimum of additions and deletions occurring in the same block.

2. Identify Pure Changes: The remaining additions or deletions are "new" or "removed" lines.

The Formula:

$$\text{Actual Lines Impacted} = \max(Additions, Deletions)$$

Applying your examples:

Scenario | Add (A) | Del (D) | Git Total (A+D) | Actual Impact (max(A,D)) -- | -- | -- | -- | -- Update 1 line + Add 1 line | 2 | 1 | 3 | 2 Delete 1 line + Add 2 lines | 2 | 1 | 3 | 2

[pankajrawat24]

Yeah this confuses a lot of people at first, you’re not wrong 🙂

What Git shows in commit stats is not “how many lines you changed logically”, it’s just how many lines were added and how many were removed based on a diff.

So when you edit one line, Git literally sees it as:

• the old line is gone → 1 deletion
• a new line appeared → 1 addition

It doesn’t know those two belong to the “same line edit”.

-----------------------------------------------------------------------------------------------------------------------------------------------

So in your examples

Case 1:

edited 1 line + added 1 new line
Git shows: +2 / -1 = 3

Case 2:

deleted 1 line + added 2 new lines
Git shows: +2 / -1 = 3

From Git’s point of view, both are just 3 diff operations, so they look identical.

-----------------------------------------------------------------------------------------------------------------------------------------------

Can Git tell the “real number of lines changed”?
Short answer: no, not exactly.

Git doesn’t track “this line was modified”, only added vs deleted lines. So there’s no built-in stat that says “2 unique lines were changed”.

-----------------------------------------------------------------------------------------------------------------------------------------------

If you really want an approximation

Some people use a rough idea like:

actual_changed_lines ≈ max(additions, deletions)

because a modified line usually shows up as one add + one delete. But this is just a guess and can be wrong if multiple edits happen together.

-----------------------------------------------------------------------------------------------------------------------------------------------

The main takeaway

Think of Git stats as:

“how big was the diff needed to turn old code into new code” not “how many lines did the developer conceptually change”

-----------------------------------------------------------------------------------------------------------------------------------------------

So yeah, what you’re seeing is expected behavior, not a bug.

[Navyansh999]

Git counts additions and deletions, not “logical edits.” So when you modify one line, Git records it as 1 deletion + 1 addition, because internally it sees the old line removed and a new line added. That’s why both of your examples show the same stats (2 additions, 1 deletion) even though the real intent is different.

Unfortunately, from standard Git stats alone, you cannot reliably determine the true number of logically changed lines. Git’s diff model works at the text level, not at the semantic “this line was edited” level.

If you want a closer estimate:

• Use git diff --word-diff to see inline changes.
• Use git diff --stat or --numstat for raw counts.
• Use external tools (like diff analyzers) that try to detect modified lines instead of simple add/delete pairs.

But strictly speaking, Git itself does not distinguish between “line edited” and “line deleted + new line added.”