Introduction

Yes, git clone will give working-tree files fresh modification times, and that is expected. Git tracks file content, path, mode, and history metadata, but it does not preserve original filesystem modification timestamps as part of version control.

What Git Actually Stores

Git commits record information such as:

• file contents,
• paths,
• file mode,
• commit author and commit time.

What Git does not store is the original filesystem mtime for each file in a reusable way for checkout. So when Git writes files into your working tree during clone, checkout, or switch, the operating system assigns new modification times.

Why the Times Change

A clone is not copying a filesystem snapshot byte-for-byte. It is:

1. downloading the Git object database,
2. creating a new repository,
3. checking out the chosen commit into the working tree.

That checkout step writes files anew, which gives them new working-tree timestamps.

This is true not only for git clone, but also for many later operations such as switching branches, restoring files, or checking out another commit.

git clone https://example.com/repo.git
cd repo
ls -l

The file timestamps you see after clone are usually tied to checkout time, not to the original authoring time and not to per-file history.

Why Git Works This Way

Git is designed around content hashes and commit history, not around preserving filesystem metadata for build tools. That design keeps repositories portable across operating systems and filesystems.

If Git tried to preserve arbitrary mtimes as versioned data, it would introduce extra complexity and weaker cross-platform behavior for something that most source-control workflows do not treat as authoritative.

What to Use Instead of mtime

If you need meaningful source history, use Git history rather than filesystem timestamps.

For example:

git log -- path/to/file
git log -1 --format=%ci -- path/to/file

That tells you when the file last changed in version-control terms, which is usually the more relevant answer.

If your build or deployment tooling relies heavily on filesystem timestamps, that tooling should be designed with Git checkouts in mind. Relying on original mtimes after clone is not a safe assumption.

When This Causes Real Problems

The most common issue is timestamp-based build systems or asset pipelines that assume unchanged files keep their old mtimes. After a clone or checkout, those systems may think everything is new and rebuild more than expected.

That is not Git corrupting metadata. It is a mismatch between the build tool's assumptions and how Git reconstructs a working tree.

If you truly need historical file times for reporting, you usually have to derive them from commit history yourself rather than expecting them to survive as filesystem metadata.

Common Pitfalls

• Assuming Git stores and restores original filesystem modification times.
• Confusing commit timestamps with working-tree file mtimes.
• Building tooling that treats mtime as version history after clone.
• Expecting identical checkout timestamps across different machines or clones.
• Using filesystem timestamps when git log is the real source of truth.

Summary

• 'git clone gives files fresh working-tree modification times.'
• Git does not version original filesystem mtime as part of normal source control.
• The relevant historical time for source code is usually the commit history, not the file timestamp.
• Use git log when you need to know when a file last changed.
• If your tooling depends on timestamps, design it knowing that Git checkouts rewrite working-tree files.