docs: more details on lock commands and the api
This commit is contained in:
parent
94e30aa29e
commit
5b40436a9b
@ -29,7 +29,9 @@ as we experiment with more advanced locking scenarios, as defined in the
|
||||
## Create Lock
|
||||
|
||||
The client sends the following to create a lock by sending a `POST` to `/locks`
|
||||
(appended to the LFS server url, as described above).
|
||||
(appended to the LFS server url, as described above). Servers should ensure that
|
||||
users have push access to the repository, and that files are locked exclusively
|
||||
to one user.
|
||||
|
||||
* `path` - String path name of the file that is locked. This should be
|
||||
relative to the root of the repository working directory.
|
||||
@ -138,8 +140,10 @@ errors.
|
||||
## List Locks
|
||||
|
||||
The client can request the current active locks for a repository by sending a
|
||||
`GET` to `/locks` (appended to the LFS server url, as described above). The
|
||||
properties are sent as URI query values, instead of through a JSON body:
|
||||
`GET` to `/locks` (appended to the LFS server url, as described above). LFS
|
||||
Servers should ensure that users have at least pull access to the repository.
|
||||
|
||||
The properties are sent as URI query values, instead of through a JSON body:
|
||||
|
||||
* `path` - Optional string path to match against locks on the server.
|
||||
* `id` - Optional string ID to match against a lock on the server.
|
||||
@ -234,6 +238,8 @@ that can affect a Git push. For a caller, this endpoint is very similar to the
|
||||
body.
|
||||
* The response includes locks partitioned into `ours` and `theirs` properties.
|
||||
|
||||
LFS Servers should ensure that users have push access to the repository.
|
||||
|
||||
Clients send the following to list locks for verification by sending a `POST`
|
||||
to `/locks/verify` (appended to the LFS server url, as described above):
|
||||
|
||||
@ -359,7 +365,12 @@ errors.
|
||||
## Delete Lock
|
||||
|
||||
The client can delete a lock, given its ID, by sending a `POST` to
|
||||
`/locks/:id/unlock` (appended to the LFS server url, as described above):
|
||||
`/locks/:id/unlock` (appended to the LFS server url, as described above). LFS
|
||||
servers should ensure that callers have push access to the repository. They
|
||||
should also prevent a user from deleting another user's lock, unless the `force`
|
||||
property is given.
|
||||
|
||||
Properties:
|
||||
|
||||
* `force` - Optional boolean specifying that the user is deleting another user's
|
||||
lock.
|
||||
|
@ -8,7 +8,8 @@ git-lfs-lock(1) -- Set a file as "locked" on the Git LFS server
|
||||
## DESCRIPTION
|
||||
|
||||
Sets the given file path as "locked" against the Git LFS server, with the
|
||||
intention of blocking attempts by other users to update the given path.
|
||||
intention of blocking attempts by other users to update the given path. Locking
|
||||
a file requires the file to exist in the working copy.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
|
@ -7,7 +7,9 @@ git-lfs-unlock(1) -- Remove "locked" setting for a file on the Git LFS server
|
||||
|
||||
## DESCRIPTION
|
||||
|
||||
Removes the given file path as "locked" on the Git LFS server.
|
||||
Removes the given file path as "locked" on the Git LFS server. Files must exist
|
||||
and have a clean git status before they can be unlocked. The `--force` flag will
|
||||
skip these checks.
|
||||
|
||||
## OPTIONS
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user