git-annex/doc/git-annex-unlock.mdwn
Joey Hess a325524454
--json-exceptions
Added a --json-exceptions option, which makes some exceptions be output in json.

The distinction is that --json-error-messages is for messages relating
to a particular ActionItem, while --json-exceptions is for messages that
are not, eg ones for a file that does not exist.

It's unfortunate that we need two switches with such a fine distinction
between them, but I'm worried about maintaining backwards compatability
in the json output, to avoid breaking anything that parses it, and this was
the way to make sure I didn't.

toplevelWarning is generally used for the latter kind of message. And
the other calls to toplevelWarning could be converted to showException. The
only possible gotcha is that if toplevelWarning is ever called after
starting acting on a file, it will add to the --json-error-messages of the
json displayed for that file and converting to showException would be a
behavior change. That seems unlikely, but I didn't convery everything to
avoid needing to satisfy myself it was not a concern.

Sponsored-by: Dartmouth College's Datalad project
2023-04-25 17:05:33 -04:00

86 lines
2.5 KiB
Markdown

# NAME
git-annex unlock - unlock files for modification
# SYNOPSIS
git annex unlock `[path ...]`
# DESCRIPTION
Normally, the content of annexed files is protected from being changed.
Unlocking an annexed file allows it to be modified. When no files are
specified, all annexed files in the current directory are unlocked.
Unlocking a file changes how it is stored in the git repository (from a
symlink to a pointer file), so this command will make a change that you
can commit.
The content of an unlocked file is still stored in git-annex, not git,
and when you commit modifications to the file, the modifications will also
be stored in git-annex, with only the pointer file stored in git.
If you use `git add` to add a file to the annex, it will be added in unlocked form from
the beginning. This allows workflows where a file starts out unlocked, is
modified as necessary, and is locked once it reaches its final version.
Normally, unlocking a file requires a copy to be made of its content, so
that its original content is preserved, while the copy can be modified. To
use less space, annex.thin can be set to true; this makes a hard link to
the content be made instead of a copy. (Only when supported by the file
system.) While this can save considerable disk space, any modification made
to a file will cause the old version of the file to be lost from the local
repository. So, enable annex.thin with care.
# EXAMPLES
# git annex unlock disk-image
# git commit -m "unlocked to allow VM to make changes as it runs"
# git annex unlock photo.jpg
# gimp photo.jpg
# git annex add photo.jpg
# git annex lock photo.jpg
# git commit -m "redeye removal"
# OPTIONS
* file matching options
The [[git-annex-matching-options]](1)
can be used to specify files to unlock.
* `--json`
Enable JSON output. This is intended to be parsed by programs that use
git-annex. Each line of output is a JSON object corresponding to a file
being processed.
* `--json-error-messages`
Adds an "error-messages" field to the JSON that contains messages that
would normally be output to the standard error when processing a file.
* `--json-exceptions`
Output additional JSON objects for some exceptions that are not
associated with a particular file.
* Also the [[git-annex-common-options]](1) can be used.
# SEE ALSO
[[git-annex]](1)
[[git-annex-edit]](1)
[[git-annex-add]](1)
[[git-annex-lock]](1)
# AUTHOR
Joey Hess <id@joeyh.name>
Warning: Automatically converted into a man page by mdwn2man. Edit with care.