You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 18, 2022. It is now read-only.
When one clones a repository with a limited depth (such as the most extreme git clone [...] --depth=1), every file will be associated with the oldest fetched commit in the shallow clone or newer.
In other words, files that pre-dates the earliest shallow clone's commit will be considered as created at that commit, which is wrong. In the above extreme example, all files are considered created at the shallow clone sole commit.
The only safe way seems to reject shallow clones entirely.
Luckily, the shallowness information is accessible since Git 2.15, as explained here.
The text was updated successfully, but these errors were encountered:
I agree that rejecting shallow clones seems like the best approach. Not sure what's best if git has version less than 2.15 - should that fail as well to be on the safe side?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When one clones a repository with a limited depth (such as the most extreme
git clone [...] --depth=1
), every file will be associated with the oldest fetched commit in the shallow clone or newer.In other words, files that pre-dates the earliest shallow clone's commit will be considered as created at that commit, which is wrong. In the above extreme example, all files are considered created at the shallow clone sole commit.
The only safe way seems to reject shallow clones entirely.
Luckily, the shallowness information is accessible since Git 2.15, as explained here.
The text was updated successfully, but these errors were encountered: