2014-02-19 21:50:30 +00:00
|
|
|
git-annex now has support for storing
|
2014-02-23 04:08:29 +00:00
|
|
|
[[arbitrary metadata|metadata]] about annexed files. For example, this can be
|
2014-02-19 21:50:30 +00:00
|
|
|
used to tag files, to record the author of a file, etc. The metadata is
|
|
|
|
synced around between repositories with the other information git-annex
|
|
|
|
keeps track of.
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
|
|
|
|
One nice way to use the metadata is through **views**. You can ask
|
|
|
|
git-annex to create a view of files in the currently checked out branch
|
2014-07-31 05:09:33 +00:00
|
|
|
that have certain metadata. Once you're in a view, you can move and copy
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
files to adjust their metadata further. Rather than the traditional
|
|
|
|
hierarchical directory structure, views are dynamic; you can easily
|
|
|
|
refine or reorder a view.
|
|
|
|
|
|
|
|
Let's get started by setting some tags on files. No views yet, just some
|
|
|
|
metadata:
|
|
|
|
|
2014-02-23 04:13:19 +00:00
|
|
|
[[!template id=note text="""
|
|
|
|
To avoid needing to manually tag files with the year (and month),
|
|
|
|
run `annex.genmetadata true`, and git-annex will do it for you
|
|
|
|
when adding files.
|
|
|
|
"""]]
|
|
|
|
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
# git annex metadata --tag todo work/2014/*
|
|
|
|
# git annex metadata --untag todo work/2014/done/*
|
|
|
|
# git annex metadata --tag urgent work/2014/presentation_for_tomorrow.odt
|
|
|
|
# git annex metadata --tag done work/2013/* work/2014/done/*
|
|
|
|
# git annex metadata --tag work work
|
|
|
|
# git annex metadata --tag video videos
|
|
|
|
# git annex metadata --tag work videos/operating_heavy_machinery.mov
|
|
|
|
# git annex metadata --tag done videos/old
|
|
|
|
# git annex metadata --tag new videos/lotsofcats.ogv
|
|
|
|
# git annex metadata --tag sound podcasts
|
2014-02-22 20:09:00 +00:00
|
|
|
# git annex metadata --tag done podcasts/*/old
|
|
|
|
# git annex metadata --tag new podcasts/*/recent
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
|
|
|
|
So, you had a bunch of different kinds of files sorted into a directory
|
|
|
|
structure. But that didn't really reflect how you approach the files.
|
|
|
|
Adding some tags lets you categorize the files in different ways.
|
|
|
|
|
|
|
|
Ok, metadata is in place, but how to use it? Time to change views!
|
|
|
|
|
|
|
|
# git annex view tag=*
|
|
|
|
view (searching...)
|
|
|
|
|
|
|
|
Switched to branch 'views/_'
|
|
|
|
ok
|
|
|
|
|
2014-02-23 04:27:18 +00:00
|
|
|
[[!template id=note text="""
|
|
|
|
Notice that a single file may appear in multiple directories
|
|
|
|
depending on its tags. For example, `lotsofcats.ogv` is in
|
|
|
|
both `new/` and `video/`.
|
|
|
|
"""]]
|
|
|
|
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
This searched for all files with any tag, and created a new git branch
|
|
|
|
that sorts the files according to their tags.
|
|
|
|
|
|
|
|
# tree -d
|
|
|
|
work
|
|
|
|
todo
|
|
|
|
urgent
|
|
|
|
done
|
|
|
|
new
|
|
|
|
video
|
|
|
|
sound
|
|
|
|
|
|
|
|
Ah, but you're at work now, and don't want to be distracted by cat videos.
|
|
|
|
Time to filter the view:
|
|
|
|
|
|
|
|
# git annex vfilter tag=work
|
|
|
|
vfilter
|
|
|
|
Switched to branch 'views/(work)/_'
|
|
|
|
ok
|
|
|
|
|
|
|
|
Now only the work files are in the view, and they're otherwise categorized
|
|
|
|
according to their other tags. So you can check the `urgent/` directory
|
|
|
|
to see what's next, and look in `todo/` for other work related files.
|
|
|
|
|
|
|
|
Now that you're in a tag based view, you can move files around between the
|
|
|
|
directories, and when you commit your changes to git, their tags will be
|
|
|
|
updated.
|
|
|
|
|
|
|
|
# git mv urgent/presentation_for_tomorrow_{work;2014}.odt ../done
|
|
|
|
# git commit -m "a good day's work"
|
|
|
|
metadata tag-=urgent
|
|
|
|
metadata tag+=done
|
|
|
|
|
|
|
|
You can return to a previous view by running `git annex vpop`. If you pop
|
|
|
|
all the way out of all views, you'll be back on the regular git branch you
|
|
|
|
originally started from. You can also use `git checkout` to switch between
|
|
|
|
views and other branches.
|
|
|
|
|
2014-02-22 20:09:00 +00:00
|
|
|
## fields
|
|
|
|
|
|
|
|
Beyond simple tags and directories, you can add whatever kinds of metadata
|
|
|
|
you like, and use that metadata in more elaborate views. For example, let's
|
|
|
|
add a year field.
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
|
|
|
|
# git checkout master
|
|
|
|
# git annex metadata --set year=2014 work/2014
|
|
|
|
# git annex metadata --set year=2013 work/2013
|
|
|
|
# git annex view year=* tag=*
|
|
|
|
|
|
|
|
Now you're in a view with two levels of directories, first by year and then
|
|
|
|
by tag.
|
|
|
|
|
|
|
|
# tree -d
|
|
|
|
2014
|
|
|
|
|-- work
|
2014-05-04 06:45:51 +00:00
|
|
|
|-- todo
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
|-- urgent
|
2014-05-04 06:45:51 +00:00
|
|
|
`-- done
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
2013
|
|
|
|
|-- work
|
|
|
|
`-- done
|
|
|
|
|
|
|
|
Oh, did you want it the other way around? Easy!
|
|
|
|
|
|
|
|
# git annex vcycle
|
|
|
|
# tree -d
|
|
|
|
work
|
|
|
|
|-- 2014
|
|
|
|
`-- 2013
|
|
|
|
todo
|
|
|
|
`-- 2014
|
|
|
|
urgent
|
|
|
|
`-- 2014
|
|
|
|
done
|
|
|
|
|-- 2014
|
|
|
|
`-- 2013
|
|
|
|
|
2014-02-22 20:09:00 +00:00
|
|
|
## location fields
|
|
|
|
|
|
|
|
Let's switch to a view containing only new podcasts. And since the
|
|
|
|
podcasts are organized into one subdirectory per show, let's
|
|
|
|
include those subdirectories in the view.
|
|
|
|
|
|
|
|
# git checkout master
|
|
|
|
# git annex view tag=new podcasts/=*
|
|
|
|
# tree -d
|
|
|
|
This_Developers_Life
|
|
|
|
Escape_Pod
|
|
|
|
GitMinutes
|
|
|
|
The_Haskell_Cast
|
|
|
|
StarShipSofa
|
|
|
|
|
|
|
|
That's an example of using part of the directory layout of the original
|
|
|
|
branch to inform the view. Every file gets fields automatically set up
|
|
|
|
corresponding to the directory it's in. So a file"foo/bar/baz/file" has
|
|
|
|
fields "/=foo", "foo/=bar", and "foo/bar/=baz". These location fields
|
|
|
|
can be used the same as other metadata to construct the view.
|
|
|
|
|
add tip about metadata driven views (and more flexible view filtering)
While writing this documentation, I realized that there needed to be a way
to stay in a view like tag=* while adding a filter like tag=work that
applies to the same field.
So, there are really two ways a view can be refined. It can have a new
"field=explicitvalue" filter added to it, which does not change the
"shape" of the view, but narrows the files it shows.
Or, it can have a new view added, which adds another level of
subdirectories.
So, added a vfilter command, which takes explicit values to add to the
filter, and rejects changes that would change the shape of the view.
And, made vadd only accept changes that change the shape of the view.
And, changed the View data type slightly; now components that can match
multiple metadata values can be visible, or not visible.
This commit was sponsored by Stelian Iancu.
2014-02-19 19:10:18 +00:00
|
|
|
This has probably only scratched the surface of what you can do with views.
|