b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
47 lines
2.2 KiB
Markdown
47 lines
2.2 KiB
Markdown
git-annex allows you to store arbitrary metadata about the content of files
|
|
stored in the git-annex repository. The metadata is stored in the
|
|
`git-annex` branch, and so is automatically kept in sync with the rest of
|
|
git-annex's state, such as [[location_tracking]] information.
|
|
|
|
Some of the things you can do with metadata include:
|
|
|
|
* Using `git annex metadata file` to show all
|
|
the metadata associated with a file.
|
|
* [[tips/metadata_driven_views]]
|
|
* Limiting the files git-annex commands act on to those with
|
|
or without particular metadata.
|
|
For example `git annex find --metadata tag=foo --or --metadata tag=bar`
|
|
* Using it in [[preferred_content]] expressions.
|
|
For example "tag=important or not author=me"
|
|
|
|
Each file (actually the underlying key) can have any number of metadata
|
|
fields, which each can have any number of values. For example, to tag
|
|
files, the `tag` field is typically used, with values set to each tag that
|
|
applies to the file.
|
|
|
|
The field names are limited to alphanumerics (and `[_-.]`), and are case
|
|
insensitive. The metadata values can contain absolutely anything you
|
|
like -- but you're recommended to keep it simple and reasonably short.
|
|
|
|
Here are some metadata fields that git-annex has special support for:
|
|
|
|
* `tag` - With each tag being a different value.
|
|
* `year`, `month` - When this particular version of the file came into
|
|
being.
|
|
* `$field-lastchanged` - This is automatically maintained for each
|
|
field that's set, and gives the date and time of the most recent
|
|
change to the field. It cannot be modified directly.
|
|
* `lastchanged` - This is automatically maintained, giving the data and time
|
|
of the last change to any of the metadata of a file.
|
|
|
|
To make git-annex automatically set the year and month when adding files,
|
|
run `git config annex.genmetadata true`. Also, see
|
|
[[tips/automatically_adding_metadata]].
|
|
|
|
git-annex's metadata can be updated in a distributed fashion. For example,
|
|
two users, each with their own clone of a repository, can set and unset
|
|
metadata at the same time, even for the same field of the same file.
|
|
When they push their changes, `git annex merge` will combine their
|
|
metadata changes in a consistent and (probably) intuitive way.
|
|
|
|
See [[the metadata design page|design/metadata]] for more details.
|