Do not recommend shallow_since for git_repository

[fmeum]

Git's --shallow-since feature can lead to broken checkouts and a fix isn't likely to happen:
https://public-inbox.org/git/CAPSG9dZV2EPpVKkOMcjv5z+NF7rUu=V-ZkZNx47rCv122HsiKg@mail.gmail.com/T/#u

This commit removes shallow_since from the canonical reproducible form of git_repository unless the attribute is provided explicitly. In cases where Bazel's attempt at fetching with --depth=1 fail, e.g. if there is no server support for shallow fetches of arbitrary commits, the progress message is now used to inform the user about this potential for fetch time optimizations.

Fixes #10292
Fixes #12857

[fmeum]

@meteorcloudy Not sure who owns the git rules. Would you be available to review it?

@nelhage @asuffield Given that you contributed extensively to the linked issues, it would be highly appreciated if you could take a look at this proposed solution.

[asuffield]

It's certainly an improvement over the status quo. To fully unbreak it we should also retry without shallow when reset fails - that's when we discover that shallow has "succeeded" and fetched junk.

[fmeum]

It's certainly an improvement over the status quo. To fully unbreak it we should also retry without shallow when reset fails - that's when we discover that shallow has "succeeded" and fetched junk.

I was thinking of proposing something more radical as a follow-up (but not cherry-pickable into Bazel 6): Deprecating shallow_since and always removing it from the canonical representation. Assuming the user has control over the Git server, they can always enable lookups by SHA if a full fetch is too costly. If they don't control it, it's very likely that the server is GitHub/GitLab/... which all seem to have this feature enabled.

@asuffield Do you think shallow_since is worth keeping around and "fixing"? If so, are there use cases in which it is clearly better than the other options?

[asuffield]

Yes, for some future bazel version we should drop it entirely and always pull commits by hash at depth 1, when an exact commit hash is given. This does require a relatively recent version of git, since depth 1 by hash was only added a couple of years ago, but that doesn't seem unreasonable. Of course that needs the usual deprecation dance, since it'll break any current users; the best cherry pick I can think of is to retry when reset fails and just pull a full clone, since that prevents any existing builds from being surprisingly broken in the future.

[meteorcloudy]

I was thinking of proposing something more radical as a follow-up

Thanks for the improvement! +1 if we can do the follow up change in a backwards compatible way.

[fmeum]

@meteorcloudy Do you think the current PR should be cherry-picked?

[meteorcloudy]

Sure, I'm fine with cherry-picking it.

[fmeum]

@bazel-io flag

[meteorcloudy]

@bazel-io fork 6.1.0