mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

this is not all run as root

Browse source
This commit is contained in:
Joey Hess 2019-03-27 11:15:03 -04:00
parent 77a1e33093
commit f4c49b8f81
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
22 changed files with 89 additions and 89 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
doc/walkthrough/adding_a_remote.mdwn
View file

@ -1,14 +1,14 @@
Like any other git repository, git-annex repositories have remotes.
Let's start by adding a USB drive as a remote.
# sudo mount /media/usb
# cd /media/usb
# git clone ~/annex
# cd annex
# git annex init "portable USB drive"
# git remote add laptop ~/annex
# cd ~/annex
# git remote add usbdrive /media/usb/annex
$ sudo mount /media/usb
$ cd /media/usb
$ git clone ~/annex
$ cd annex
$ git annex init "portable USB drive"
$ git remote add laptop ~/annex
$ cd ~/annex
$ git remote add usbdrive /media/usb/annex
This is all standard ad-hoc distributed git repository setup.

10
doc/walkthrough/adding_files.mdwn
View file

@ -1,10 +1,10 @@
# cd ~/annex
# cp /tmp/big_file .
# cp /tmp/debian.iso .
# git annex add .
$ cd ~/annex
$ cp /tmp/big_file .
$ cp /tmp/debian.iso .
$ git annex add .
add big_file (checksum...) ok
add debian.iso (checksum...) ok
# git commit -a -m added
$ git commit -a -m added
When you add a file to the annex and commit it, only a symlink to
the content is committed to git. The content itself is stored in

10
doc/walkthrough/automatically_managing_content.mdwn
View file

@ -7,8 +7,8 @@ but then you have to decide what to get or drop. In this example, there
are perhaps not enough copies of the first file, and too many of the second
file.
# cd /media/usbdrive
# git annex whereis
$ cd /media/usbdrive
$ git annex whereis
whereis my_cool_big_file (1 copy)
0c443de8-e644-11df-acbf-f7cd7ca6210d -- laptop
whereis other_file (3 copies)
@ -20,15 +20,15 @@ What would be handy is some automated versions of get and drop, that only
gets a file if there are not yet enough copies of it, or only drops a file
if there are too many copies. Well, these exist, just use the --auto option.
# git annex get --auto --numcopies=2
$ git annex get --auto --numcopies=2
get my_cool_big_file (from laptop...) ok
# git annex drop --auto --numcopies=2
$ git annex drop --auto --numcopies=2
drop other_file ok
With two quick commands, git-annex was able to decide for you how to
work toward having two copies of your files.
# git annex whereis
$ git annex whereis
whereis my_cool_big_file (2 copies)
0c443de8-e644-11df-acbf-f7cd7ca6210d -- laptop
62b39bbe-4149-11e0-af01-bb89245a1e61 -- usb drive [here]

12
doc/walkthrough/backups.mdwn
View file

@ -4,8 +4,8 @@ numcopies setting, which defaults to 1 copy. Let's
change that to require 2 copies, and send a copy of every file
to a USB drive.
# git annex numcopies 2
# git annex copy . --to usbdrive
$ git annex numcopies 2
$ git annex copy . --to usbdrive
Now when we try to `git annex drop` a file, it will verify that it
knows of 2 other repositories that have a copy before removing its
@ -15,13 +15,13 @@ The numcopies setting used above is the global default.
You can also vary the number of copies needed, depending on the file name.
So, if you want 3 copies of all your flac files, but only 1 copy of oggs:
# echo "*.ogg annex.numcopies=1" >> .gitattributes
# echo "*.flac annex.numcopies=3" >> .gitattributes
$ echo "*.ogg annex.numcopies=1" >> .gitattributes
$ echo "*.flac annex.numcopies=3" >> .gitattributes
Or, you might want to make a directory for important stuff, and configure
it so anything put in there is backed up more thoroughly:
# mkdir important_stuff
# echo "* annex.numcopies=3" > important_stuff/.gitattributes
$ mkdir important_stuff
$ echo "* annex.numcopies=3" > important_stuff/.gitattributes
For more details about the numcopies setting, see [[copies]].

8
doc/walkthrough/creating_a_repository.mdwn
View file

@ -1,6 +1,6 @@
This is very straightforward.
# mkdir ~/annex
# cd ~/annex
# git init
# git annex init
$ mkdir ~/annex
$ cd ~/annex
$ git init
$ git annex init

8
doc/walkthrough/fsck__58___verifying_your_data.mdwn
View file

@ -4,7 +4,7 @@ for the data. For example, when you use the SHA1 backend, fsck will verify
that the checksums of your files are good. Fsck also checks that the
[[numcopies|copies]] setting is satisfied for all files.
# git annex fsck
$ git annex fsck
fsck some_file (checksum...) ok
fsck my_cool_big_file (checksum...) ok
...
@ -12,19 +12,19 @@ that the checksums of your files are good. Fsck also checks that the
You can also specify the files to check. This is particularly useful if
you're using sha1 and don't want to spend a long time checksumming everything.
# git annex fsck my_cool_big_file
$ git annex fsck my_cool_big_file
fsck my_cool_big_file (checksum...) ok
If you have a large repo, you may want to check it in smaller steps. You may
start and continue an aborted or time-limited check.
# git annex fsck -S <optional-directory> --time-limit=1m
$ git annex fsck -S <optional-directory> --time-limit=1m
fsck some_file (checksum...) ok
fsck my_cool_big_file (checksum...) ok
Time limit (1m) reached!
# git annex fsck -m <optional-directory>
$ git annex fsck -m <optional-directory>
fsck my_other_big_file (checksum...) ok
...

2
doc/walkthrough/fsck__58___when_things_go_wrong.mdwn
View file

@ -2,7 +2,7 @@ Fsck never deletes possibly bad data; instead it will be moved to
`.git/annex/bad/` for you to recover. Here is a sample of what fsck
might say about a badly messed up annex:
# git annex fsck
$ git annex fsck
fsck my_cool_big_file (checksum...)
git-annex: Bad file content; moved to .git/annex/bad/SHA1:7da006579dd64330eb2456001fd01948430572f2
git-annex: ** No known copies exist of my_cool_big_file

6
doc/walkthrough/getting_file_content.mdwn
View file

@ -5,8 +5,8 @@ make it available.
We can use this to copy everything in the laptop's annex to the
USB drive.
# cd /media/usb/annex
# git annex sync laptop
# git annex get .
$ cd /media/usb/annex
$ git annex sync laptop
$ git annex get .
get my_cool_big_file (from laptop...) ok
get iso/debian.iso (from laptop...) ok

8
doc/walkthrough/modifying_annexed_files.mdwn
View file

@ -4,12 +4,12 @@ Normally, the content of files in the annex is prevented from being modified.
That's a good thing, because it might be the only copy, you wouldn't
want to lose it in a fumblefingered mistake.
# echo oops > my_cool_big_file
$ echo oops > my_cool_big_file
bash: my_cool_big_file: Permission denied
In order to modify a file, it should first be unlocked.
# git annex unlock my_cool_big_file
$ git annex unlock my_cool_big_file
unlock my_cool_big_file (copying...) ok
That replaces the symlink that normally points at its content with a copy
@ -23,8 +23,8 @@ When you `git commit` it will notice that you are committing an unlocked
file, add its new content to the annex, and a pointer to that content is
what gets committed to git.
# echo "now smaller, but even cooler" > my_cool_big_file
# git commit my_cool_big_file -m "changed an annexed file"
$ echo "now smaller, but even cooler" > my_cool_big_file
$ git commit my_cool_big_file -m "changed an annexed file"
add my_cool_big_file ok
[master 64cda67] changed an annexed file
1 files changed, 1 insertions(+), 1 deletions(-)

4
doc/walkthrough/moving_file_content_between_repositories.mdwn
View file

@ -5,9 +5,9 @@ server to your laptop. Doing that by hand (by using `git annex get` and
`git annex drop`) is possible, but a bit of a pain. `git annex move`
makes it very easy.
# git annex move my_cool_big_file --to usbdrive
$ git annex move my_cool_big_file --to usbdrive
move my_cool_big_file (to usbdrive...) ok
# git annex move video/hackity_hack_and_kaxxt.mov --from fileserver
$ git annex move video/hackity_hack_and_kaxxt.mov --from fileserver
move video/hackity_hack_and_kaxxt.mov (from fileserver...)
SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e 100% 82MB 199.1KB/s 07:02
ok

8
doc/walkthrough/quiet_please__58___When_git-annex_seems_to_skip_files.mdwn
View file

@ -1,8 +1,8 @@
One behavior of git-annex is sometimes confusing at first, but it turns out
to be useful once you get to know it.
# git annex drop *
#
$ git annex drop *
$
Why didn't git-annex seem to do anything despite being asked to drop all the
files? Because it checked them all, and none of them are present.
@ -14,8 +14,8 @@ Running a git-annex command without specifying any file name will
make git-annex look for files in the current directory and its
subdirectories. So, we can add all new files to the annex easily:
# echo hi > subdir/subsubdir/newfile
# git annex add
$ echo hi > subdir/subsubdir/newfile
$ git annex add
add subdir/subsubdir/newfile ok
When doing this kind of thing, having nothing shown for files

2
doc/walkthrough/removing_files.mdwn
View file

@ -9,7 +9,7 @@ repository to save space. This is called "dropping" the file.
You can always drop files safely. Git-annex checks that some other
repository still has the file before removing it.
# git annex drop iso/debian.iso
$ git annex drop iso/debian.iso
drop iso/Debian_5.0.iso ok
Once dropped, the file will still appear in your work tree as a broken symlink.

2
doc/walkthrough/removing_files__58___When_things_go_wrong.mdwn
View file

@ -3,7 +3,7 @@ remotes, and verify that they still have a file. After all, it could
have been dropped from them too. If the remotes are not mounted/available,
you'll see something like this.
# git annex drop important_file other.iso
$ git annex drop important_file other.iso
drop important_file (unsafe)
Could only verify the existence of 0 out of 1 necessary copies
Unable to access these remotes: usbdrive

10
doc/walkthrough/renaming_files.mdwn
View file

@ -1,8 +1,8 @@
# cd ~/annex
# git mv big_file my_cool_big_file
# mkdir iso
# git mv debian.iso iso/
# git commit -m moved
$ cd ~/annex
$ git mv big_file my_cool_big_file
$ mkdir iso
$ git mv debian.iso iso/
$ git commit -m moved
You can use any normal git operations to move files around, or even
make copies or delete them.

4
doc/walkthrough/syncing.mdwn
View file

@ -5,8 +5,8 @@ get them.
Let's look at what the sync command does in more detail:
# cd /media/usb/annex
# git annex sync
$ cd /media/usb/annex
$ git annex sync
commit
nothing to commit (working directory clean)
ok

6
doc/walkthrough/transferring_files__58___When_things_go_wrong.mdwn
View file

@ -4,7 +4,7 @@ You don't have to try to keep all that straight; git-annex does
or file server is not accessible, it will let you know what it needs to get
it:
# git annex get video/hackity_hack_and_kaxxt.mov
$ git annex get video/hackity_hack_and_kaxxt.mov
get video/hackity_hack_and_kaxxt.mov (not available)
Unable to access these remotes: usbdrive, server
Try making some of these repositories available:
@ -12,6 +12,6 @@ it:
58d84e8a-d9ae-11df-a1aa-ab9aa8c00826 -- portable USB drive
ca20064c-dbb5-11df-b2fe-002170d25c55 -- backup SATA drive
failed
# sudo mount /media/usb
# git annex get video/hackity_hack_and_kaxxt.mov
$ sudo mount /media/usb
$ git annex get video/hackity_hack_and_kaxxt.mov
get video/hackity_hack_and_kaxxt.mov (from usbdrive...) ok

10
doc/walkthrough/unused_data.mdwn
View file

@ -7,7 +7,7 @@ migrating between key-value [[backends]].
This might be historical data you want to preserve, so git-annex defaults to
preserving it. So from time to time, you may want to check for such data:
# git annex unused
$ git annex unused
unused . (checking for unused data...)
Some annexed data is no longer used by any files in the repository.
NUMBER KEY
@ -21,15 +21,15 @@ After running `git annex unused`, you can follow the instructions to examine
the history of files that used the data, and if you decide you don't need that
data anymore, you can easily remove it from your local repository.
# git annex dropunused 1
$ git annex dropunused 1
dropunused 1 ok
Hint: To drop a lot of unused data, use a command like this:
# git annex dropunused 1-1000
$ git annex dropunused 1-1000
Rather than removing the data, you can instead send it to other
repositories:
# git annex copy --unused --to backup
# git annex move --unused --to archive
$ git annex copy --unused --to backup
$ git annex move --unused --to archive

8
doc/walkthrough/using_bup.mdwn
View file

@ -11,16 +11,16 @@ remote that is only accessible on the current system, by passing
"buprepo=/big/mybup".
"""]]
# git annex initremote mybup type=bup encryption=none buprepo=example.com:/big/mybup
$ git annex initremote mybup type=bup encryption=none buprepo=example.com:/big/mybup
initremote bup (bup init)
Initialized empty Git repository in /big/mybup/
ok
# git annex describe mybup "my bup repository at example.com"
$ git annex describe mybup "my bup repository at example.com"
describe mybup ok
Now the remote can be used like any other remote.
# git annex move my_cool_big_file --to mybup
$ git annex move my_cool_big_file --to mybup
move my_cool_big_file (to mybup...)
Receiving index from server: 1100/1100, done.
ok
@ -28,7 +28,7 @@ Now the remote can be used like any other remote.
Note that, unlike other remotes, bup does not really support removing
content from its git repositories. This is a feature. :)
# git annex move my_cool_big_file --from mybup
$ git annex move my_cool_big_file --from mybup
move my_cool_big_file (from mybup...)
content cannot be removed from bup remote
failed

6
doc/walkthrough/using_ddar.mdwn
View file

@ -16,16 +16,16 @@ remote that is only accessible on the current system, by passing
"ddarrepo=/big/myddar".
"""]]
# git annex initremote myddar type=ddar encryption=none ddarrepo=example.com:/big/myddar
$ git annex initremote myddar type=ddar encryption=none ddarrepo=example.com:/big/myddar
initremote ddar (ddar init)
Initialized empty Git repository in /big/myddar/
ok
# git annex describe myddar "my ddar repository at example.com"
$ git annex describe myddar "my ddar repository at example.com"
describe myddar ok
Now the remote can be used like any other remote.
# git annex move my_cool_big_file --to myddar
$ git annex move my_cool_big_file --to myddar
move my_cool_big_file (to myddar...)
ok

18
doc/walkthrough/using_special_remotes.mdwn
View file

@ -19,14 +19,14 @@ environment variables. Don't worry -- it will prompt if you leave anything off.
So feel free to make any kind of special remote instead of the S3 remote
used in this example.
# export AWS_ACCESS_KEY_ID="somethingotherthanthis"
# export AWS_SECRET_ACCESS_KEY="s3kr1t"
# git annex initremote mys3 type=S3 chunk=1MiB encryption=shared
$ export AWS_ACCESS_KEY_ID="somethingotherthanthis"
$ export AWS_SECRET_ACCESS_KEY="s3kr1t"
$ git annex initremote mys3 type=S3 chunk=1MiB encryption=shared
initremote mys3 (shared encryption) (checking bucket) (creating bucket in US) ok
Now you can store files on the newly initialized special remote.
# git annex copy my_cool_big_file --to mys3
$ git annex copy my_cool_big_file --to mys3
copy my_cool_big_file (to mys3...) ok
Once you've initialized a special remote in one repository, you can enable
@ -38,15 +38,15 @@ To do so, first get git-annex in sync (so it knows about
the special remote that was added in the other repository), and then
use `git annex enableremote`.
desktop# git annex sync
desktop# export AWS_ACCESS_KEY_ID="somethingotherthanthis"
desktop# export AWS_SECRET_ACCESS_KEY="s3kr1t"
desktop# git annex enableremote mys3
desktop$ git annex sync
desktop$ export AWS_ACCESS_KEY_ID="somethingotherthanthis"
desktop$ export AWS_SECRET_ACCESS_KEY="s3kr1t"
desktop$ git annex enableremote mys3
enableremote mys3 (checking bucket) ok
And now you can download files from the special remote:
desktop# git annex get my_cool_big_file --from mys3
desktop$ git annex get my_cool_big_file --from mys3
get my_cool_big_file (from mys3...) ok
This has only scratched the surface of what can be done with

10
doc/walkthrough/using_ssh_remotes.mdwn
View file

@ -5,13 +5,13 @@ that is truly remote, a host accessed by ssh.
Say you have a desktop on the same network as your laptop and want
to clone the laptop's annex to it:
desktop# git clone ssh://mylaptop/home/me/annex ~/annex
desktop# cd ~/annex
desktop# git annex init "my desktop"
desktop$ git clone ssh://mylaptop/home/me/annex ~/annex
desktop$ cd ~/annex
desktop$ git annex init "my desktop"
Now you can get files and they will be transferred (using `rsync` via `ssh`):
desktop# git annex get my_cool_big_file
desktop$ git annex get my_cool_big_file
get my_cool_big_file (getting UUID for origin...) (from origin...)
SHA256-s86050597--6ae2688bc533437766a48aa19f2c06be14d1bab9c70b468af445d4f07b65f41e 100% 2159 2.1KB/s 00:00
ok
@ -19,7 +19,7 @@ Now you can get files and they will be transferred (using `rsync` via `ssh`):
When you drop files, git-annex will ssh over to the remote and make
sure the file's content is still there before removing it locally:
desktop# git annex drop my_cool_big_file
desktop$ git annex drop my_cool_big_file
drop my_cool_big_file (checking origin..) ok
Note that normally git-annex prefers to use non-ssh remotes, like

10
doc/walkthrough/using_tags_and_branches.mdwn
View file

@ -2,11 +2,11 @@ Like git, git-annex hangs on to every old version of a file (by default),
so you can make tags and branches, and can check them out later to look at
the old files.
# git tag 1.0
# rm -f my_cool_big_file
# git commit -m deleted
# git checkout 1.0
# cat my_cool_big_file
$ git tag 1.0
$ rm -f my_cool_big_file
$ git commit -m deleted
$ git checkout 1.0
$ cat my_cool_big_file
yay! old version still here
Of course, when you `git checkout` an old branch, some old versions of