From 2d169589cf9dd1c1451e996a9588beacc7ea05ab Mon Sep 17 00:00:00 2001 From: "http://christian.amsuess.com/chrysn" Date: Sun, 4 Nov 2012 12:23:57 +0000 Subject: [PATCH 01/11] Added a comment: worked well --- ...mment_2_10ecf3220ffcbbe94ba09da225458f18._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment diff --git a/doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment b/doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment new file mode 100644 index 0000000000..21befd41a0 --- /dev/null +++ b/doc/forum/safely_dropping_git-annex_history/comment_2_10ecf3220ffcbbe94ba09da225458f18._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://christian.amsuess.com/chrysn" + nickname="chrysn" + subject="worked well" + date="2012-11-04T12:23:56Z" + content=""" +the procedure i outlined originally worked well for me; the method chosen for reinjection was moving over the .git/annex/objects directory and doing a ``git annex fsck``. + +special care had to be taken of the special remote (rsync+gpg) -- i guess that's why they are called special ;-) . as described in the forum post you linked, i had to copy over remote.log and the uuid.log line from the old git-annex branch -- otherwise, a ``git annex initremote`` would have generated a new hmac, effectively resetting the remote repo. + +the formerly 5gb git-annex branch (admittedly not ``git gc``'d recently, but that just wasn't feasible any more) shrunk down to around 25mb of current location information. i'll keep an eye on how it's growing to see if the problem is inherent or if it was just old bugs causing trouble. +"""]] From 994da05473f0f35d78f521ecb3c90e627bd49ca7 Mon Sep 17 00:00:00 2001 From: "http://olg.myid.net/" Date: Sun, 4 Nov 2012 18:22:53 +0000 Subject: [PATCH 02/11] --- ...-annex-shell_to_a_specific_repository.mdwn | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn diff --git a/doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn new file mode 100644 index 0000000000..bed019e415 --- /dev/null +++ b/doc/forum/Restricting_git-annex-shell_to_a_specific_repository.mdwn @@ -0,0 +1,25 @@ +Is there a way to restrict git-annex-shell to a specific directory? +Currently, if git-annex is paired to a remote repository, it adds this to the authorized_keys: + + + $ cat ~/.ssh/authorized_keys + command="~/.ssh/git-annex-shell",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3... + + $ cat ~/.ssh/git-annex-shell + #!/bin/sh + set -e + exec git-annex-shell -c "$SSH_ORIGINAL_COMMAND" + +That gives whoever has the pubkey the right to access all repositories of one user. +It would be nice to have a manual way to limit the access to a specific repository like + + + $ cat ~/.ssh/git-annex-shell + #!/bin/sh + set -e + export GIT_ANNEX_SHELL_REPO=~/annex + exec git-annex-shell -c "$SSH_ORIGINAL_COMMAND" + + +Or maybe some chroot hackery is the way to go? + From cd5dd19296cc1edb8664a9ff640db6a999839264 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 4 Nov 2012 19:44:11 +0000 Subject: [PATCH 03/11] Added a comment --- ...nt_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment diff --git a/doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment b/doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment new file mode 100644 index 0000000000..2fa7ac055c --- /dev/null +++ b/doc/forum/Syncing_machines_on_different_networks/comment_3_65d1dae9b76fccb5f2b8fd8c69b60075._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.152.108.194" + subject="comment 3" + date="2012-11-04T19:44:11Z" + content=""" +You need two things: + +1. A special remote in the cloud. S3, or rsync.net, or whatever. +2. A git repository hosted in the cloud. You could just use github (paying them if you want to avoid it being public). + +Is it possible to have an encrypted git remote repository? It's not directly supported by git. The way git needs to be able to request arbitrary objects by SHA, kind of prevents encrypting things to any useful level. The only way I can think of to do that would be to use some cloud storage that can be mounted as a filesystem, and store an encrypted filesystem containing the git repo in a file inside that. Not easy. + +The git-annex assistant is going to get around this by not requiring a central git repository and transferring git data peer-to-peer, but that will require both the peers be on the network at the same time. +"""]] From 7a8ce98df64191ed75e3119c65504ee685e88e15 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmmPHsszTlpa3s3x_LEzmEYkZfEmqq7IjU" Date: Sun, 4 Nov 2012 19:46:05 +0000 Subject: [PATCH 04/11] --- ...n_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn diff --git a/doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn b/doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn new file mode 100644 index 0000000000..e78ed4d0ea --- /dev/null +++ b/doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn @@ -0,0 +1,18 @@ +What steps will reproduce the problem? + + try to unlock a file in a git annex checkout + +What is the expected output? What do you see instead? + +% git annex unlock FILENAME +unlock FILENAME (copying...) cp: illegal option -- - +usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file + cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ... target_directory +git-annex: copy failed! + +(should unlock the file) + +What version of git-annex are you using? On what operating system? + + latest git annex osx build as of yesterday (12-11-03) + From e82747fab23611acdb90dc4edbcafe61c535ad29 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmmPHsszTlpa3s3x_LEzmEYkZfEmqq7IjU" Date: Sun, 4 Nov 2012 19:47:21 +0000 Subject: [PATCH 05/11] --- ..._on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn b/doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn index e78ed4d0ea..9ac80ce5dc 100644 --- a/doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn +++ b/doc/bugs/unlock_not_working_on_os_x_10.6_-_cp:_illegal_option_--_-_.mdwn @@ -1,18 +1,18 @@ What steps will reproduce the problem? - try to unlock a file in a git annex checkout + try to unlock a file in a git annex checkout What is the expected output? What do you see instead? -% git annex unlock FILENAME -unlock FILENAME (copying...) cp: illegal option -- - -usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file - cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ... target_directory -git-annex: copy failed! + % git annex unlock FILENAME + unlock FILENAME (copying...) cp: illegal option -- - + usage: cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file target_file + cp [-R [-H | -L | -P]] [-fi | -n] [-apvX] source_file ... target_directory + git-annex: copy failed! -(should unlock the file) + (should unlock the file) What version of git-annex are you using? On what operating system? - latest git annex osx build as of yesterday (12-11-03) + latest git annex osx build as of yesterday (12-11-03) From 7c7ca34c5d7294953142c5723bbea4ca07a5f3a1 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 4 Nov 2012 19:57:38 +0000 Subject: [PATCH 06/11] Added a comment --- ...comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment diff --git a/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment new file mode 100644 index 0000000000..0e96b11336 --- /dev/null +++ b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.152.108.194" + subject="comment 1" + date="2012-11-04T19:57:38Z" + content=""" +I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.) + +However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`. +"""]] From 6be068f918af8ca3ba246ec641b56e25a6b49fce Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 4 Nov 2012 19:57:48 +0000 Subject: [PATCH 07/11] Added a comment --- ...comment_2_422d0870917bb6cab89a75031344a409._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment diff --git a/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment new file mode 100644 index 0000000000..882246e9f8 --- /dev/null +++ b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.152.108.194" + subject="comment 2" + date="2012-11-04T19:57:48Z" + content=""" +I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.) + +However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`. +"""]] From cae5dfaff93b6591fccc970da7b43365dff60196 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 4 Nov 2012 19:58:28 +0000 Subject: [PATCH 08/11] Added a comment --- ...comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment diff --git a/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment new file mode 100644 index 0000000000..8e955fd48f --- /dev/null +++ b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_3_1304a721da6f5133fdfa1dac507f1ecb._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.152.108.194" + subject="comment 3" + date="2012-11-04T19:58:28Z" + content=""" +I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Or the user accidentially doing something with a partially transferred file. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.) + +However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`. +"""]] From 07e37172eb37a5eb8ff63a7547ed6b52d07d1e9f Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 4 Nov 2012 19:58:44 +0000 Subject: [PATCH 09/11] removed --- ...comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment | 10 ---------- 1 file changed, 10 deletions(-) delete mode 100644 doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment diff --git a/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment deleted file mode 100644 index 0e96b11336..0000000000 --- a/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_1_7d7deb81e24bca306ea585a25abaf4e7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.194" - subject="comment 1" - date="2012-11-04T19:57:38Z" - content=""" -I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.) - -However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`. -"""]] From dfa8d83709142cbb8dcdb4e402fed7f9fbaf5cb2 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 4 Nov 2012 19:59:01 +0000 Subject: [PATCH 10/11] removed --- ...comment_2_422d0870917bb6cab89a75031344a409._comment | 10 ---------- 1 file changed, 10 deletions(-) delete mode 100644 doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment diff --git a/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment b/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment deleted file mode 100644 index 882246e9f8..0000000000 --- a/doc/todo/whishlist:_make_partial_files_available_during_transfer/comment_2_422d0870917bb6cab89a75031344a409._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.194" - subject="comment 2" - date="2012-11-04T19:57:48Z" - content=""" -I'm not at all comfortable with either idea. Temporarily repointing the symlink could lead to accidentially git committing a bad symlink. Running rsync in place would break lots of things that assume that, once the file is present, it can be assumed to be the full and correct file. (Obviously fsck doesn't assume that, but checks made by `git annex drop` do, for example.) - -However, you can access partially transferred files by key in `.git/annex/tmp`. It would be easy to write some hack that looks at the symlink to get the key, and then spits out the name of the partial file in `.git/annex/tmp.`. -"""]] From 7c9382ada3a8c531df649cf5f1a130778b3a6a3f Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 4 Nov 2012 20:01:35 +0000 Subject: [PATCH 11/11] Added a comment --- ...comment_1_108b3984891f82429430b503cddfb3c1._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment diff --git a/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment new file mode 100644 index 0000000000..f8a85cb166 --- /dev/null +++ b/doc/bugs/Tries_to_upload_to_remote_although_remote_is_dead/comment_1_108b3984891f82429430b503cddfb3c1._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="4.152.108.194" + subject="comment 1" + date="2012-11-04T20:01:35Z" + content=""" +Are you using the git-annex assistant? It's supposed to have code in it to prevent it from using dead remotes. Perhaps that is not working. + +When not using the git-annex assistant, nothing prevents git-annex from trying to continue to use dead remotes. I think this is ok; maybe the dead remote is not 100% dead yet; if it is, the remote can be removed from git's configuration to prevent it being used of course. +"""]]