Introduction

If two different blob contents produced the same SHA-1 object ID, Git would have a serious identity problem because Git historically uses that hash as the object's name. In theory that means one object could be mistaken for another, but in practice Git adds some protection through object formatting, collision-detecting SHA-1 implementations, repository validation, and an ongoing transition toward SHA-256.

What Git actually hashes

Git does not hash raw file bytes alone. For a blob, it hashes:

"blob " + size + NUL + content

That means an attacker would need a collision on the full Git object representation, not just on two arbitrary files. This does not make collisions impossible, but it does make real Git-targeted collisions harder than a generic SHA-1 demo.

Why a collision would be dangerous

Git identifies objects by their hash. If two different blobs had the same object ID, Git could not distinguish them by hash alone.

Potential consequences would include:

• one blob being stored where another was expected
• repository integrity checks becoming unreliable
• content substitution attacks in malicious scenarios

This is why SHA-1 weakness matters for a content-addressed storage system like Git.

Git did not just ignore the problem

After practical SHA-1 collision work became real, Git did not simply shrug and keep the original implementation unchanged. Modern Git has incorporated collision-detecting SHA-1 support based on hardened implementations such as sha1dc.

The idea is not "SHA-1 is magically safe again". The idea is that Git tries to detect suspicious SHA-1 collision patterns rather than blindly trusting any matching digest.

What would happen operationally

If Git encountered a suspicious object collision in a modern protected setup, the safest outcome is rejection or corruption detection rather than silently accepting the object as normal. Tools such as git fsck also exist to verify repository integrity and can help surface object-level problems.

A truly successful undetected collision would be much worse because Git's object model assumes the hash names the content uniquely.

Blob collisions are only one part of the picture

Blobs are file contents, but Git also hashes trees, commits, and tags. A blob collision alone does not automatically give an attacker control over history, because the surrounding Git objects also have to line up in a meaningful way.

Still, blobs matter a lot because they are the raw content building blocks for repository state.

Git is moving toward SHA-256

One long-term answer is to move away from SHA-1. Git supports repository formats based on SHA-256 so that object identity is no longer tied to the weaker hash function.

That transition is not just cosmetic. It is the architectural answer to the fact that collision resistance matters deeply for Git's storage model.

Practical perspective

For ordinary users, the realistic guidance is:

• keep Git up to date
• avoid ancient Git versions with weaker defenses
• use repository integrity checks when needed
• understand that modern Git treats hash security as a real engineering concern

The most important point is that Git handling is not simply "two blobs collide and Git happily accepts whichever arrived first". Modern Git has added defenses exactly because that outcome would be unacceptable.

Common Pitfalls

• Thinking Git hashes only raw file contents with no object header.
• Assuming a generic SHA-1 collision demo directly translates into a practical Git exploit.
• Believing Git still relies on naive SHA-1 handling with no collision-aware hardening.
• Treating SHA-256 migration as optional trivia rather than a long-term integrity improvement.
• Assuming a blob collision automatically rewrites history without considering the other Git object layers.

Summary

• A SHA-1 collision on a Git blob would be a real integrity problem because Git names objects by hash.
• Git hashes the full blob object representation, not just the raw file bytes.
• Modern Git includes collision-detection hardening rather than blindly trusting SHA-1.
• Repository integrity tooling and the move toward SHA-256 both address this risk.
• The right mental model is "serious problem with mitigations", not "impossible" and not "Git ignores it".