Recent comments posted to this site:

comment 23 70dcb7e7ffdd14351adaf4c40ee7fdd0
[[!comment Error: unsupported page format hs]]
Fri Jan 12 19:47:32 2018
comment 3 e6ce9bb92c973350852c9498b7ffb50f
[[!comment Error: unsupported page format sh]]
Fri Jan 12 19:47:32 2018

@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.

Comment by joey Mon Dec 11 18:23:58 2017

Hi,

just detected that the provided pre-commit-annex script is broken for filenames containing a '

Comment by woffs Sat Dec 9 11:18:10 2017

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.

Comment by spam Sat Nov 11 19:51:56 2017
Well I guess that depends on habit/workflow. I often let tab completion show me the directory content before beginning to type. Thanks for the links, I'll look into it (though I have no experience with Haskell yet).
Comment by Lykos153 Thu Nov 9 17:35:14 2017

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

Comment by joey Thu Nov 9 16:11:10 2017
Doesn't work so well for me. The hand-build one performs way better in terms of clearness and efficiency. It groups the suggestions instead of sorting them by name and it prints a description for each command. But most importently, it does only suggest switches when - 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.
Comment by Lykos153 Thu Nov 9 02:15:37 2017

@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.

Comment by joey Tue Nov 7 20:42:14 2017

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.

Comment by joey Tue Nov 7 20:18:19 2017