Recent comments posted to this site:
Is it possible to encrypt with subkeys. I have a few subkeys distributed to different computers and I'd like to be able to sync to a special remote with all of them. Right now, if the master key is stripped, I get an error from gpg.
I do this exact thing with password-store. Appending "!" to the subkey id should force gpg to use that specific key: https://lists.zx2c4.com/pipermail/password-store/2014-September/001131.html.
This is a simple way to split a repository, but the resulting split git repository will be larger than is really necessary.
When you dropunused
all the hard links that are not present in the
repository, git-annex will commit a log to the git-annex branch saying "I
don't have this content" for each of them. That seems unnecessary since
it probably does not have an earlier log saying it contained the content
that was hard linked into it, and perhaps could be improved in git-annex
to not record that unncessarily, but that's what it does currently.
So I suggest running git annex forget
after the dropunused or at some
later point. That will delete all traces of those log files from
the git-annex branch.
@mario, great question! (Not the best place for such a question, start a thread on the forum next time..)
git-annex does use rsync when transferring files between ssh remotes.
Rsync normally goes over ssh, and it might be better to enable compression
at the ssh level. For example, I have "Compression yes" in ~/.ssh/config
I think that the reason your annex-rsync-upload-options setting broke it is that rsync needs --compress to be passed on to the other rsync process (in the remote repository), and that is run via git-annex-shell, which has a whitelist of options it will pass to rsync. Passing arbitrary options to rsync could allow unwanted behavior when git-annex-shell is being used as a security barrier. And --compress is one of the options that both the rsync sender and receiver have to agree on for the rsync protocol to work.
I have added a note to the man page about this limitation of what the rsync-options settings can be used to do.
Hi,
how does "git-annex sync --content" transfers its file to a (regular) ssh-remote? I think it uses rsync.. Is that correct?
I want to use compression for the file transfers. Therefore, I tried in .git/config to set:
[remote "origin"]
annex-rsync-upload-options = "--compress"
However, it seems that this crashes the upload. The sync just seems to hang.. Is it possible to use compression for the transfer? How?
@joern.mankiewicz, I see you found a bug and filed it, so will answer in the but report.
Barring bugs, adding another gpg key to a hybrid encryption special remote
is as simple as git annex enableremote $theremote keyid+=$newkey
Setting remote.<name>.annex-readonly=true
prevents git-annex sync
from pushing changes to the remote. It also prevents any git-annex command
from copying annexed file contents to the remote, or deleting annexed file
contents. So I think it's ideal for this kind of situation.
There does seem to be room for configs to prevent sync from pulling/pushing without making the remote fully readonly. For example, the remote might be a source of content, that only knows about the files it added and not other files in the local repository, so dropping files from it should be allowed but not pushing to it.
So, I've added remote.<name>.annex-push
and
remote.<name>.annex-pull
.
@anarcat, I'm not sure I follow how git-annex would use that. It does not currently use the tor control port at all when setting up its tor hidden service. But please file a todo item if I'm wrong and there's something to be improved.
(What would be useful is if tor came with the control port enabled by default, and perhaps protected by something like onion-grater. Then git-annex could use it when it installs its hidden service, instead of its current approach of prompting for the root password and modifying the torrc file.)
@Yurt, git-annex will let you specify the gpg key id using anything that gpg accepts, including a keyid with a appended '!'. However, when I tried that, gpg seemed to still pick the master key instead of the subkey. That happens because git-annex runs the input through
gpg --list-public-keys
(in order to convert eg, email addresses to key ids) which always lists the master key even when given a subkey.I made a small change to git-annex to special case this '!' suffix behavior. Seems to work in my very limited testing.
Please file bug reports about this kind of thing!