Recent comments posted to this site:
Hi,
just detected that the provided pre-commit-annex script is broken for filenames containing a '
I just discovered that cloning over ssh an gcrypt encrypted repository and enabling the remote afterwards is somehow messing up the git config:
git clone grypt::ssh://user@ip.com:/mnt/encrypted_backup cd encrypted_backup git annex enableremote encrypted_backup gitrepo=/.../encrypted_backup
leads to following in the .git/config of the just cloned repository:
... [remote "origin"] url = grypt::ssh://user@ip.com:/mnt/encrypted_backup gcrypt-id = :id:12312312 fetch = +refs/heads/:refs/remotes/origin/
[remote "encrypted_backup"] url = grypt::ssh://user@ip.com:/mnt/encrypted_backup fetch = +refs/heads/:refs/remotes/server/ gcrypt-participants = keyid gcrypt-signingkey = keyid gcrypt-publish-participants = true gcrypt-id = :id:adsasd annex-gcrypt = shell annex-uuid = 312312312 ...
Note, that for the remote "origin" some config like the signingkey is missing compared to the remote "encrypted_backup"
Then, running git annex sync --content
leads to a error saying
"gcrypt: Failed to decrypt manifest!"
during the push process. After that I am not able to sync the repository anymore, even with the original repostitory, which initiated the remote. The encrypted_backup is then somehow messed up.
Removing the "origin" remote via git remote remove origin
solves the problem for me. But that command has to be launched right before the first sync, pull or push command! Otherwise the sync process cannot be done anymore.
Well, the code that generates the zsh completions could always be improved. https://github.com/pcapriotti/optparse-applicative/issues
I don't really understand why completing options before filenames makes it unusable. It means that "git-annex tabtabtab" cycles through options first, but if you type part of the filename tab will complete the rest. It does seem that someone else agrees with you though, as they filed this issue: https://github.com/pcapriotti/optparse-applicative/issues/173
-
was typed and completes file names otherwise. The auto generated one (at least the one that is shipped with the Arch Linux package) puts the file names last, which makes it unusable.
@erics, thanks for the useful feedback about stack. I've applied your patch to avoid the Build/InstallDesktopFile problem. And, I made it automatically set GHC when BUILDER=stack.
Using the Makefile is documented, up in the "building from source on Debian" section. But there's a set of users who want to use stack, and don't want to mess around with Makefiles (including users on Windows without a "make"), and that's who the stack instructions are kind of targeted at. It's an unfortunate problem with stack that it doesn't provide any way to make the git-annex-shell symlink.
I am doubtful that --allow-different-user is a good idea. I sometimes
use stack to build git-annex for testing purposes, but I have never
built it with stack and installed that with sudo make install
.
And it may well be that there's not a reasonable way to make that work;
and the install target is mostly intended for use by distributions that
are creating a package of git-annex, who probably set PREFIX and don't run
it as root.
git annex fix
fixes up the symlinks before they're committed.
It's run by the pre-commit hook, so even when annexed files are
manually moved around, the symlinks that get committed are always
right.
So then, if the symlinks committed are always right,
how would git annex adjust --fix
be useful? Well,
there are ways to check out git repositories that make
the .git directory not be in the usual place. For example,
when using submodules, git puts that directory in a different place.
And then the committed symlinks won't point to .git. So,
git annex adjust --fix
is useful as a way to adjust the symlinks
locally, without committing any changes to them, in that kind of
situation.
When I follow the tutorial and run
git push origin master git-annex
it replies
error: src refspec master does not match any.
error: failed to push some refs to 'vds:~/test.git'
However one can use git-annex sync
instead and that works fine.
Now on your laptop, clone the git repository from the server:
Is it possible to init git-annex repo on your local machine, add git-remote there and push local data to the server? Won't there be any problems with this 'non-official' approach?
@woffs hmm, the hook script seems to quote every use of the filename, which should avoid such problems. I tested it, using both extract and exiftool, and a file named "foo'bar.jpg", and it worked fine.
If you have a case where it does not work, suggest you file a bug report with enough information to reproduce the problem.