Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2019-10-21 11:41:31 -04:00
commit 93f53cda08
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
7 changed files with 100 additions and 0 deletions

View file

@ -0,0 +1,32 @@
For most files, whether they get annexed is controlled by `annex.largefiles`. But dotfiles are configured to *never* be annexed regardless of `annex.largefiles`. This is unexpected and confusing. More oddly, `git-annex-add` doesn't seem to add them to regular git, either.
I'm guessing this flows from the new default of `git add` adding files to the annex, which [[I hope gets reversed|forum/lets_discuss_git_add_behavior]]. But separately, I'm not sure why `git-annex-add` does not add the dotfiles to regular git:
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
(master_env_v163_py36) 22:32 [newtree02] $ git status
On branch newtree02
Untracked files:
(use "git add <file>..." to include in what will be committed)
mydir/
nothing added to commit but untracked files present (use "git add" to track)
(master_env_v163_py36) 22:32 [newtree02] $ ls -al mydir
total 12
drwxrwxr-x 2 ilya ilya 4096 Oct 20 22:31 .
drwxrwxr-x 3 ilya ilya 4096 Oct 20 22:31 ..
-rw-rw-r-- 1 ilya ilya 9 Oct 20 22:31 .mynewdot
(master_env_v163_py36) 22:32 [newtree02] $ git annex add mydir
(master_env_v163_py36) 22:32 [newtree02] $ git status
On branch newtree02
Untracked files:
(use "git add <file>..." to include in what will be committed)
mydir/
# End of transcript or log.
"""]]

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="jason.dixon.email@aa0e536a2ec2877d6f666108dbbc6e39bbe87ac0"
nickname="jason.dixon.email"
avatar="http://cdn.libravatar.org/avatar/fbe9050fc83bbd536d307d87ea14d4bc"
subject="a case for request routing"
date="2019-10-20T19:42:03Z"
content="""
This could also be what you're after (just a design)? https://git-annex.branchable.com/design/requests_routing/
This is something I would love to see implemented too. Especially as an addition to get / drop / fsck commands.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 5"
date="2019-10-21T02:02:31Z"
content="""
Possibly related: [speculate-can-get: extension of speculate-present](https://git-annex.branchable.com/todo/speculate-can-get___58___extension_of_speculate-present/)
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 6"
date="2019-10-21T02:02:47Z"
content="""
Possibly related: [speculate-can-get: extension of speculate-present](https://git-annex.branchable.com/todo/speculate-can-get___58___extension_of_speculate-present/)
"""]]

View file

@ -0,0 +1,15 @@
So i wanted to try local pairing for a while, but since i wanted to sync between local host and a remote server (which is heavily secured, firewall, block port except one available for ssh etc).
Although, i could have used the ssh remote, but i couldn't found a flag to specify a private key file (might need to search more), since i'm using a separate private key + password to ssh into the remote server.
Anyway, tor installed fine on both host and server, but even though tor was working fine by itself (tried it using sock5 and curl to test), git-annex couldn't initialize it, and was stuck on `Unable to connect to hidden service. It may not yet have propigated to the Tor network. (SocksErrorHostUnreachable) Will retry..` when using `git annex enable-tor`
I tried it on the assistant too with the same error in the logs.
I'm using default setting on the torrc, I'm on ubuntu 19.04 x86_64 using 7.20190129 version of git-annex.
P.S:I used this one liner to test if tor was working ` curl --socks5 localhost:9050 --socks5-hostname localhost:9050 -s https://check.torproject.org/ | cat | grep -m 1 Congratulations | xargs`, not sure if there better way/other to test it.
EDIT: I updated the git-annex version on both the host and server, as i only now noticed they were old (and also since i tried a lot of other things and that was the last thing that could work).
Using 7.20190819+git2-g908476a9b-1~ndall+1 from neuron's repo.
Still not working and now stuck at `git-annex: tor failed to create hidden service, perhaps the tor service is not running` when doing `sudo git-annex enable-tor $(id -u)`
(and yes, the tor service is indeed running, which make that weird)
Obvious, but i also made sure to restart both tor and git-annex before and after upgrading in my consecutive attempts.

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="different handling of dotfiles"
date="2019-10-21T02:51:16Z"
content="""
Related: [[bugs/dotfiles_handled_differently]]
For most files, whether they get annexed is controlled by `annex.largefiles`. But dotfiles are configured to never be annexed regardless of `annex.largefiles`. This special-casing (in `.git/info/attributes`) is unexpected and confusing. It is probably a consequence of making `git add` annex files by default, but it's better to change that default than to have the special case. Also, `git-annex-add` seems to ignore the dotfiles, as in the bug report above.
I thought of reverting to an earlier version of git-annex until these and other issues can get worked out, but realized I can't, since the repos got irreversibly auto-upgraded to v7...
"""]]

View file

@ -0,0 +1,14 @@
I have a music file which makes my music player unhappy. unfortunately, it (the music player) only shows me the target of the symlink, the "key" of the file, e.g. `SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3`. There's a way to find which remotes have that key:
$ git annex whereis --key=SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3
whereis SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3 (7 copies)
059b8bdb-2716-4ac9-b06e-9b1176af361d -- anarcat@curie:~/mp3 [here]
ok
But that doesn't show me which file(s) actually point to it. [[git-annex-list]] and [[git-annex-find]] don't have the `--key` parameter and [[git-annex-matching-options]] doesn't have it either, so it makes it difficult to find which file points to that key.
The only way I found to do this was to use the `find` command, like this:
find -lname '*SHA256E-s16279847--ce02487cd9f78f5944cbc1acb6622d270f7c16172d0fa12ae1330a4d9c3144a0.mp3'
I would love to have a way to use `git-annex`'s knowledge of its own repo here instead... Could this be improved? --[[anarcat]]