Recent comments posted to this site:

joey wrote:

The protocol VERSION is picked by the special remote, it's not negotiated.

VERSION is provided to git-annex by the special remote to git-annex process. There is no need to 'negotiate' anything - you could make git-annex understand either of:

  • higher VERSION, e.g.

    • VERSION 2 which would support some new features which that special remote would need. If parent git-annex is old/doesn't support that version - would fail and demand git annex upgrade
    • VERSION 6.20171124 (where 6.20171124 is an example of git-annex version) so if git-annex parent process is older than that it could provide a meaningful message that git annex >= 6.20171124 is needed
  • VERSION 1 feature1 feature2 ... where those features could be the ones needed (e.g. INFO_MSG for recent addition). And if parent git-annex doesn't know/support any particular feature, it could fail and inform user that a new annex with that feature support is needed.

In either of those cases the custom special remotes page could outline added features/versions of git-annex supporting them, so may be even those above error messages could point to it.

Overall, it is just a minor change to be done on git-annex side while allowing for clear(er) specification, and I do not see any need for actual "negotiation" -- features are either supported or not by the parent process.

Comment by yarikoptic Tue Feb 6 20:03:27 2018

I see that you manually add the first repo as a remote of the external drive, and the external drive as a remote of the original.

What about when you add a second external drive? Should you then be adding the first two repos as remotes of the new one, and then go to the first two ones and add the new drive as a remote of them too? Doesn't this permutation scale out of control when you add a new drive to, say, a git annex made of 10 disks, 20 disks, etc?

Comment by elmimmo Thu Jan 18 07:02:18 2018

Why is .git/annex/misctmp so large ? Currently I use git annex to manage pytorch models, basically I have a large amount (1500 folder) of 4 Kilobytes files, some files are are bigger, misctmp occupies 6.2 GB, is it ok ?

PS. Sorry, if I write this here but failed to post to the forum.

Comment by arseny-n Wed Jan 17 13:05:04 2018

Why is .git/annex/misctmp so large ? Currently I use git annex to manage pytorch models, basically I have a large amount (1500 folder) of 4 Kilobytes files, some files are are bigger, misctmp occupies 6.2 GB, is it ok ?

PS. Sorry, if I write this here but failed to post to the forum.

Comment by arseny-n Wed Jan 17 13:04:52 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