git-sync v4 no longer supports abbreviated commit SHA

[nan-yu]

In git-sync v3, --rev can point to an abbreviated commit SHA. git rev-parse <SHORT SHA> works because it clones the repo first. Then git rev-parse is able to parse the full commit hash from the short version.

However, in git-sync v4, git rev-parse is not able to resolve the short commit SHA.

[thockin]

This is true. I should document that. That said, how important is this? To use short SHAs, I have to first get all SHAs and use that to search locally (I could not find a way to do remote listing of short SHA), which makes everything slower and more costly.

For example, if I added a fallback to fetch all SHAs if the --rev flag isn't found, is that really worth the effort vs. telling people to use full SHAs?

[nan-yu]

That said, how important is this?

It's more about avoiding breaking changes to customers. Config Sync uses git-sync. With this change, the upgrade process won't be seamless. They have to update to full SHAs.

I think this seems to be okay if we document it as a breaking change. If they use short SHAs, they only get a git-sync error, but their resources won't be accidentally deleted.

There is another breaking change seems to be more serious. I just filed https://github.com/kubernetes/git-sync/issues/841 to track it separately.

[thockin]

I found a similar issue: https://github.com/actions/checkout/issues/265

I have not yet found a way to support short SHAs in remotes.

We could MAYBE do something like --ref=<branch-with-commit> --short-sha=<short> or --ref=<short>@<branch> which triggers git fetch --unshallow <repo> <branch> --filter=blob:none and then git rev-list <short>, but that's MUCH slower than just asking for the full SHA.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale