git_repository should --depth=1 fetch of sha1

[moroten]

Description of the feature request:

Since some years back, it is possible to do git fetch origin --depth=1 <sha1> if the server has enabled the configuration uploadpack.allowReachableSHA1InWant. When specifying a sha1 in the git_repository rule, first try a shallow fetch (--depth=1, not --shallow-since) of the specific sha1 before doing git fetch --all.

Feature requests: what underlying problem are you trying to solve with this feature?

By fetching just the specific commit that is wanted, nothing more, the network traffic can be reduced. It is also a clean interface in specifying exactly what is wanted.

Implemented this way, the shallow_since argument will not be needed. It could be implemented to recommend that either shallow_since=<timestamp> or shallow_sha1=True is set, depending on what the server is capable of. This would make it possible to write a full git_repository call with only the sha1 and without finding out the commit date.

Have you found anything relevant by searching the web?

I could not find any GitHub issue relating to this.

[laurentlb]

What do you think, Klaus?

[aehlig]

What do you think, Klaus?

Well, as the introduction to this issue states ...

Since some years back, it is possible to do git fetch origin --depth=1 <sha1> if the server has enabled the configuration uploadpack.allowReachableSHA1InWant.

... this is a policy decision by the administrator of the git server, i.e., the question is not whether the server is able to do so, but if it is willing to (with the default being to not allow it). This is why shallow_since was added in the first place: as the majority of git server do not allow --depths=1 clones for a specific sha1, some other measure was needed to trim down the amount of traffic for cloning the repository.

As far as I know, the policy in this respect hasn't changed for the majority of git servers, so my suggestion would be to make this opt-in (to not add additional round trips by failing attempts to clone with --depth=1) by adding an extra attribute to the git_repository rule indicating that the user believes that this particular git server allows fetches for unadvertised commits.

[HackAttack]

I’ve made a PR that attempts to take advantage of the uploadpack setting, and transparently falls back if it doesn’t work.

[wesleyw72]

I'd quite like this feature. When cloning a high velocity repo from Github, not setting --depth=1 and just using --shalow_since can mean that the clone time takes an increasingly long time if you're not chasing HEAD of the repo you depend on (as the commits since the shallow_since grow). As an experiment, I have seen the clone time go from 3+ minutes to around 20 seconds by setting the depth when cloning a specific commit on a repo, even though the shallow_since is less than a month ago.