lunny/git-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: more details on lock commands and the api

Browse Source
This commit is contained in:
risk danger olson 2017-02-15 10:14:54 -07:00
parent 94e30aa29e
commit 5b40436a9b
3 changed files with 20 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
docs/api/locking.md
View File

@ -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.

3
docs/man/git-lfs-lock.1.ronn
View File

@ -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

4
docs/man/git-lfs-unlock.1.ronn
View File

@ -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