#1815 added a lock check to the pre-push hook. However, this causes problems for users that use LFS servers that don't implement the locking API (which is all of them since it's not officially shipped yet). This process should definitely be optional.

First, I think LFS should track whether to check locks during pre-push. This could be done through an lfs.<url>.locks key, similar to the lfs.<url>.access key.

• If lfs.<url>.skiplocksverify is NULL: Run the locking check.
  • If it's successful, set lfs.<url>.skiplocksverify=true.
  • If it's an HTTP 501 Not Implemented response, set lfs.<url>.skiplocksverify=false
  • If there's an error, print an error to STDERR, with instructions on disabling this check in case the user's LFS service doesn't implement locking.
• If lfs.<url>.skiplocksverify=true: run the locking check.
  • If it's successful, carry on.
  • If it's an HTTP 501 Not Implemented response, set lfs.<url>.skiplocksverify=false
  • If it errors, halt the push with a detailed error message.
• If lfs.<url>.skiplocksverify=false: skip the locking check completely.

The 501 response from an LFS Locking endpoint could be used to tell the client not to bother with a client-side locking check, because the LFS service is handling it itself on the server side.