#Git annex remote names how to#
I have one particular use case that I am trying to figure out how to implement: I'm using git-annex for backing up a variety of data, with several different remotes (including a USB drive for backup, rsync for encrypted cloud backup, etc). I have to "chmod" the xxx/yyy within an '.git/hooks/pre-commit' action (shared used NFS location).įollowing way using 'find' needs too much time in case of a big remote: $ git annex info -fast inputbinaries | grep 'directory:' | awk '' How can I get the xxx/yyy or the complete storage path of an annexed file in a fast way? And then I could also keep track of data on my write-protected DVDs.įormat appears to be /BASE_DIR/xxx/yyy/FILEKEY/FILEKEY It would be awesome if I could use git-annex for this, to keep track of my copies and copies of copies. I tried adding virtual files to git annexīut still any kind of get/copy command does not get any new files The copy command fails without complaints
On one of my servers, I set up a git annex repos, hoping to only manage the structure, the locations, and the number of copies. However, I would like to use git-annex to keep track of the paths and get/drop files from my different computers. Both reasons prevent me from setting up a git-annex repos there. I have large files/directories (approx 5 TB) on an nfs mount to which is a) write-protected (think "read-only medium") and b) used by non-git users. I've developed a serious annex-addiction and now I want to use it everywhere! In particular I was hoping to apply it to this use case: # git annex describe usbdrive "usb drive on /media/usbdrive/" Setup example: # git annex initremote usbdrive type=directory directory=/media/usbdrive/ encryption=none This should not be used when the filesystem has stable inode numbers,Īs it does risk confusing two files that have the same size and mtime. Ignore the inode numbers and so avoid that extra work. Since someįilesystems generate new inode numbers each time they are mounted, Of files are used to detect when files have changed. Ignoreinodes - Usually when importing, the inode numbers It will not be usable as a general-purpose Importtree - Set to "yes" to make this special remote usableīy git-annex-import.
It is not safe to change the chunksizeĮxporttree - Set to "yes" to make this special remote usableīy git-annex-export. Keyid - Specifies the gpg key to use for encryption.Ĭhunk - Enables chunking when storing large files.Ĭhunksize - Deprecated version of chunk parameter above.ĭo not use for new remotes. Typically this willīe an empty directory, or a directory already used as a directory remote.Įncryption - One of "none", "hybrid", "shared", or "pubkey". These parameters can be passed to git annex initremote to configure theĭirectory - The path to the directory where the files should be storedįor the remote. Instead, you should use a regular git clone of your git-annex repository.
In the tree in both, the directory special remote is not what you want. If you just want two copies of your repository with the files "visible" (by design, the same as the rsync remote). Note that directory remotes have a special directory structure The drive's mountpoint as a directory remote.
You want to use to sneakernet files between systems (possibly withĮncrypted contents). One use case for this would be if you have a removable drive that This special remote type stores file contents in directory.
0 kommentar(er)
