e213ef310f
* Fix minor FD leak in journal code. Closes: #754608 * direct: Fix handling of case where a work tree subdirectory cannot be written to due to permissions. * migrate: Avoid re-checksumming when migrating from hashE to hash backend. * uninit: Avoid failing final removal in some direct mode repositories due to file modes. * S3: Deal with AWS ACL configurations that do not allow creating or checking the location of a bucket, but only reading and writing content to it. * resolvemerge: New plumbing command that runs the automatic merge conflict resolver. * Deal with change in git 2.0 that made indirect mode merge conflict resolution leave behind old files. * sync: Fix git sync with local git remotes even when they don't have an annex.uuid set. (The assistant already did so.) * Set gcrypt-publish-participants when setting up a gcrypt repository, to avoid unncessary passphrase prompts. This is a security/usability tradeoff. To avoid exposing the gpg key ids who can decrypt the repository, users can unset gcrypt-publish-participants. * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet exist, since it is not automatically created for Gnome 3 users. * Windows: Move .vbs files out of git\bin, to avoid that being in the PATH, which caused some weird breakage. (Thanks, divB) * Windows: Fix locking issue that prevented the webapp starting (since 5.20140707). # 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 "metadata=tag=important or not metadata=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.
|