Recent comments posted to this site:
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?
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.
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.
@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.
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.
joey wrote:
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 upgradeVERSION 6.20171124
(where6.20171124
is an example of git-annex version) so if git-annex parent process is older than that it could provide a meaningful message thatgit annex >= 6.20171124
is neededVERSION 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.