diff --git a/doc/bugs/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_3_d83330ad40f4f2c2c55f29acf6680620._comment b/doc/bugs/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_3_d83330ad40f4f2c2c55f29acf6680620._comment new file mode 100644 index 0000000000..7526fc8e6e --- /dev/null +++ b/doc/bugs/get_over_ssh_fails_with___fd__58__19__58___hClose__58___resource_vanished/comment_3_d83330ad40f4f2c2c55f29acf6680620._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="gueux" + avatar="http://cdn.libravatar.org/avatar/47e44a21505727b2d6bb5d88f0468f34" + subject="comment 3" + date="2018-09-24T09:03:13Z" + content=""" +I'm seeing this bug, too. It happens between my laptop, which is also running 6.20180913-1, and two servers which both run 6.20170101-1+deb9u2. One of the servers is remote, while the other one is on my local network. +"""]] diff --git a/doc/bugs/post-receive.mdwn b/doc/bugs/post-receive.mdwn new file mode 100644 index 0000000000..96519313fe --- /dev/null +++ b/doc/bugs/post-receive.mdwn @@ -0,0 +1,67 @@ +### Please describe the problem. + +This is actually two (related) bugs. +I discovered the second by means of troubleshooting the first. + +One issue I've had with a portable repo is when I init it from my arch machine it sets up everything as expected. +When I try to use that drive with my raspberry pi, however, there are some new git hooks (or at least one) that the older version of git annex (still the latest available in the Pi's repos, 2016, which is really old :/). + +What is necessary to get a newer version of git-annex available in the Raspbian repos for default users? I know I can just install the tarball (and I'm considering it) but for everyone else coming upon this issue... + +### What steps will reproduce the problem? +See above. git-annex init on a newer system, then mount it as a drive on a Raspberry pi (with the older git-annex installed) and set up the pi as a remote. Then git-annex sync. + +Note: this is fixable by deleting the post-receive hook in the .git/hooks folder. I'm just not sure that's a great idea. + +### What version of git-annex are you using? On what operating system? +Arch linux: + +git-annex version: 6.20180913-g547d01fd0 +build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite +dependency versions: aws-0.20 bloomfilter-2.0.1.0 cryptonite-0.25 DAV-1.3.2 feed-1.0.0.0 ghc-8.4.3 http-client-0.5.13.1 persistent-sqlite-2.8.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.0 +key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL +remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external +operating system: linux x86_64 +supported repository versions: 3 5 6 +upgrade supported from repository versions: 0 1 2 3 4 5 +local repository version: 5 + + +Raspberry Pi: + +git-annex version: 6.20160923 +build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi +key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL +remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external +local repository version: 5 +supported repository versions: 5 6 +upgrade supported from repository versions: 0 1 2 3 4 5 +operating system: linux arm + + + + +### Please provide any additional information below. + +I've also noticed a bug with tab complete on the latest git-annex when in a folder that is not git-annexed. I was looking into git-annex post-receive, and typed git-annex pos to get a listing of possible outputs. This was the result: + + + +[[!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 + +tai@trasa:~$ git-annex post-receive git-annex: Not in a git repository. +git-annex: Not in a git repository. + +Display all 105 possibilities? (y or n)^C +tai@trasa:~$ + + + +# End of transcript or log. +"""]] + +I did not hit enter, the script just failed on me during tab-complete and exited. + +Thanks, I look forward to any response from the community this might get. diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another.mdwn b/doc/forum/Efficiently_move_files_from_one_repo_to_another.mdwn new file mode 100644 index 0000000000..3b9a9a74ab --- /dev/null +++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another.mdwn @@ -0,0 +1,26 @@ +Hi, + +## Context + +I use git-annex to work with my files on multiple computers, and also to collaborate with other people on my files. Since I don't want to share all my files to all the devices (especially not these of other people), I have several different annex-repos. Of course there is location tracking and file content is not required on all devices. Still, for some devices I want a clear separation in the sense that there should not be any trace that the files from the other repos even exist. However, sometimes I want to change the "permissions" for a file or directory (meaning I have to move it to another repo). + +## Problem + +Having multiple annex-repos is a reasonable workaround for the use case discussed above. One remaining issue is that moving files or folders from one repo to another is quite inefficient. This is especially true for the remotes. + +### Example: + +Having two annex-repos (Repo-A and Repo-B) on my laptop. Both repos also exist on my server. All content is synced among the devices. On the laptop I move a large subdir from Repo-A to Repo-B. If I sync both repos with the server afterwards, I have to re-upload all files even though they are already there, but in a different repo. + +## Question + +Is there an efficient way to move files from one repo to another that works in the example given above? + +## Possible approach + +I could imagine something like a device-wide location tracking. In this case Repo-B could check "Is this file available in another repo on the same device?" and get it locally. However, for my use case it is really important, that this device-wide location tracking is not synchronized among all the remotes. + +### Example: + +Again there are Repo-A and Repo-B on laptop and server. Another repo Repo-C is on my laptop and my phone. The phone knows nothing about Repo-A and Repo-B and also is not aware that the server even exists. And this should stay this way. This means that the laptop must not tell the phone that there are other remotes and other repos, as well. + diff --git a/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_1_0cc04ef5e511241a5152a0702f943538._comment b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_1_0cc04ef5e511241a5152a0702f943538._comment new file mode 100644 index 0000000000..62ec2124c1 --- /dev/null +++ b/doc/forum/Efficiently_move_files_from_one_repo_to_another/comment_1_0cc04ef5e511241a5152a0702f943538._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="Ilya_Shlyakhter" + avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0" + subject="comment 1" + date="2018-09-24T15:58:03Z" + content=""" +Location tracking tracks locations of keys, not of filenames or directory names (unless you use the WORM backend). Are you sure you care if other people know what keys (checksums) exist on your non-shared system? If you don't, you could keep the contents of different repos as unconnected/unrelated branches in the same git repo. See also [[https://git-annex.branchable.com/tips/local_caching_of_annexed_files/]] +"""]] diff --git a/doc/forum/Find_unlocked__47__locked_files/comment_1_a34ce29b644c80789bf8cbfd575ffe1a._comment b/doc/forum/Find_unlocked__47__locked_files/comment_1_a34ce29b644c80789bf8cbfd575ffe1a._comment new file mode 100644 index 0000000000..27bd6c89e5 --- /dev/null +++ b/doc/forum/Find_unlocked__47__locked_files/comment_1_a34ce29b644c80789bf8cbfd575ffe1a._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="mario" + avatar="http://cdn.libravatar.org/avatar/4c63b0935789d29210d0bd8cad8d7ac7" + subject="comment 1" + date="2018-09-23T16:46:47Z" + content=""" +Usually I use \"git status\" to check if I have unlocked files. But, I'd say that's a workaround for the feature that you suggest. +"""]]