We need to update all LFS API requests to send the remote ref. This gives the servers opportunities to tweak how locks are stored or authorization is checked for repositories based on the ref being updated.

As of LFS v2.4.0, the client will always send a ref with API calls. Servers that want to support these fields in a future proof manner can look for the following requests:

// LFS 2.3 and below
// absent 'ref' property
// servers should retain existing behavior
// POST locks/verify
{ "limit": 100 }

// LFS 2.4.0
// valid 'ref'
// servers should use ref in authz check
// POST locks/verify
{ "ref": { "name": "master" }, "limit": 100 }

// LFS 2.4.0
// empty 'ref', client had problems finding it
// servers should retain existing behavior
// POST locks/verify
{ "ref": null, "limit": 100 }

Open question: This is currently sending a relative ref name, like "master" or "feature-branch." Should it instead try to send an absolute ref name, like "refs/heads/feature-branch"?

EDIT: Yes, the client should send a full refspec to the LFS server 👍

TODO:

• Default remote ref:
  • Check push.default verify locks against each ref being pushed #2706
• Improved remote tracking config: add PushRemote() for checking branch.*.pushRemote and remote.pushDefault first #2715 Improved default remotes #2711
• API calls:
  • locks verify verify locks against each ref being pushed #2706
    • add retries
  • lock send remote refspec for the other lock commands #2773
  • unlock send remote refspec for the other lock commands #2773
  • list locks send remote refspec for the other lock commands #2773
  • objects/batch tq: send refspec with batch requests #2774 Run 1 TransferQueue per uploaded ref #2806 Batch send refspec take 2 #2809
• Docs refspec docs #2820