summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn25
-rw-r--r--doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_1_6f477af942aeb98683a56bcf0e819a38._comment11
-rw-r--r--doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_2_45c22f596a18d5dc2331cfeef8c767fa._comment12
-rw-r--r--doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_3_cbca264d86fe733b8106a4bf50c0c6ff._comment8
-rw-r--r--doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync.mdwn11
-rw-r--r--doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_1_d828bc374e50a49101c0b863f9b33080._comment8
-rw-r--r--doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_2_a4badfc248be428e6426a936212cc896._comment8
-rw-r--r--doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_3_0b04089d3d33fdb48eeb46bf168e9a3c._comment8
-rw-r--r--doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_4_2bcab1b7998b4df08fca41b8d810f115._comment10
-rw-r--r--doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_5_677e958c3f2effec7528b484aeb6478d._comment13
-rw-r--r--doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_6_56e53803fdede895cba717e6b6e9a1bb._comment23
-rw-r--r--doc/todo/Add___39__dir__39___option_to_addurl.mdwn4
-rw-r--r--doc/todo/Add___39__dir__39___option_to_addurl/comment_1_0156942b1629ee994bf3699a56b3ceb7._comment11
-rw-r--r--doc/todo/Add___39__dir__39___option_to_addurl/comment_2_15a6571d57794c3f1268c7a064e05bef._comment13
-rw-r--r--doc/todo/Add___39__dir__39___option_to_addurl/comment_3_62601714648631a31dee366a5a2e8f44._comment7
-rw-r--r--doc/todo/Add_gitlab.com_as_cloud_provider.mdwn10
-rw-r--r--doc/todo/Add_gitlab.com_as_cloud_provider/comment_1_0dad4b86cda93dd5ca0c4fb049ff6d97._comment18
-rw-r--r--doc/todo/Add_gitlab.com_as_cloud_provider/comment_2_441c879e7aa60eb74e3a881de9c4e8ea._comment9
-rw-r--r--doc/todo/Add_gitlab.com_as_cloud_provider/comment_3_9d60cfa947c5ce82c69fb77961db2d25._comment31
-rw-r--r--doc/todo/Add_gitlab.com_as_cloud_provider/comment_4_94c0a53da4f3bc89afd97a036d832f78._comment8
-rw-r--r--doc/todo/Add_gitlab.com_as_cloud_provider/comment_5_edb7d9de2ec51ab3f51a35848b63c842._comment7
-rw-r--r--doc/todo/Chunks_support_in_all_special_remotes.mdwn10
-rw-r--r--doc/todo/Chunks_support_in_all_special_remotes/comment_1_d12604dbeb42bbb6850425d237cb01e7._comment8
-rw-r--r--doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn9
-rw-r--r--doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment10
-rw-r--r--doc/todo/Deleting_Unused_Files_by_Age.mdwn17
-rw-r--r--doc/todo/Expose_auto-merge_for_manual__44___local_merges.mdwn9
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory.mdwn23
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_10_4829c2a2302b4b9611deddfedfbaa944._comment10
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_1_4d81941fe53881eebff97109a07ba2f4._comment8
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_2_660a5b764ad42468154b2bb94f8ec004._comment8
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_3_eed178ce4bc4d2b3f08a1e3d3d62c086._comment12
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_4_1dae745cff1c0a38232d033dcc542ac4._comment16
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_5_8d6c791e5e2daec7b25828f6884a67c6._comment16
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_6_92ef2d4a7ed47000fda02732b4794dc0._comment10
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_7_78fb5cdd61220ffcf0ae1eaf266985ec._comment28
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_8_21712dfee4f37232c34eddbce2427691._comment11
-rw-r--r--doc/todo/New_special_remote_suggeston_-_clean_directory/comment_9_0ba57952532d5ef1f2bbfb163faa3b2f._comment35
-rw-r--r--doc/todo/Output_key_with_import__47__deduplicate.mdwn22
-rw-r--r--doc/todo/Output_key_with_import__47__deduplicate/comment_1_9eefceaa052a4587b8448c2f8fd24d97._comment12
-rw-r--r--doc/todo/Recovering_from_a_bad_sync.mdwn31
-rw-r--r--doc/todo/Recovering_from_a_bad_sync/comment_1_6f5f518a3190534b737203787149ef3c._comment10
-rw-r--r--doc/todo/Recovering_from_a_bad_sync/comment_2_e494df56dcede4d14bcaa4cdbf3da4f5._comment10
-rw-r--r--doc/todo/Recovering_from_a_bad_sync/comment_3_4d4904bcbf97401c7c11338f32577f96._comment14
-rw-r--r--doc/todo/Recursive_addurl_simlar_to_wget_--recursive.mdwn9
-rw-r--r--doc/todo/Recursive_addurl_simlar_to_wget_--recursive/comment_1_4ecd9ddba1b63b571555ec9bef18e2d8._comment8
-rw-r--r--doc/todo/Shorten_long_file_names_preventing_git_checkout.mdwn14
-rw-r--r--doc/todo/Specify_a_version_for_the___39__feed__39___build_dependency..mdwn9
-rw-r--r--doc/todo/Support_--jobs_option_for___39__sync_--content__39__.mdwn14
-rw-r--r--doc/todo/Support_dbus_monitor_for_networkd.mdwn5
-rw-r--r--doc/todo/Support_dbus_monitor_for_networkd/comment_1_c34efaec014646bd52b5a4cc36913982._comment7
-rw-r--r--doc/todo/Time_Stamping_of_Events_in_Webapp.mdwn3
-rw-r--r--doc/todo/Views_Demo.mdwn15
-rw-r--r--doc/todo/Views_Demo/comment_1_d7c83a0e9a83e4a05aa74a34a7e1cf19._comment8
-rw-r--r--doc/todo/What_if_the_active_annex__39__ed_files_were_not_symlinks__63__.mdwn26
-rw-r--r--doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode.mdwn10
-rw-r--r--doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_1_6c6e192bc0f70a386cd4275f98e1bd6f._comment8
-rw-r--r--doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_2_8e22cfdbeb2c841870a623cf4c7baf60._comment10
-rw-r--r--doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_3_0039faa19e35eada1ff17eac6fbcab29._comment15
-rw-r--r--doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks.mdwn20
-rw-r--r--doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_1_b795d0bfa64654bf82684da961815cea._comment22
-rw-r--r--doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_2_0ab89dad1289b5d349ecd452c3f5e4f5._comment7
-rw-r--r--doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_3_dcb651fa8a1ec52d6016e11bf06fab5d._comment8
-rw-r--r--doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment8
-rw-r--r--doc/todo/add_--quiet_option_to_fsck.mdwn7
-rw-r--r--doc/todo/add_--quiet_option_to_fsck/comment_1_9c70dcdf11d23a33d1007005bbd58e60._comment8
-rw-r--r--doc/todo/allow_removing_jabber_configuration.mdwn5
-rw-r--r--doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__.mdwn18
-rw-r--r--doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__/comment_1_60e5067c2be9e8df7bd1b6d954c60cad._comment11
-rw-r--r--doc/todo/better_git-annex-shell_init_workflow.mdwn12
-rw-r--r--doc/todo/cheaper_global_fsck.mdwn38
-rw-r--r--doc/todo/clear_file_names_in_special_remotes.mdwn13
-rw-r--r--doc/todo/clear_file_names_in_special_remotes/comment_1_630f17c9a7ce9a77d5d5867a6e0c799b._comment8
-rw-r--r--doc/todo/clear_file_names_in_special_remotes/comment_2_823c279683ac3f39c921be3fcbf6bfe2._comment10
-rw-r--r--doc/todo/clear_file_names_in_special_remotes/comment_3_4704e465025b543e47c18d565abd2747._comment8
-rw-r--r--doc/todo/command_line_interface_for_required_content_setthings.mdwn13
-rw-r--r--doc/todo/commit_in_direct_mode.mdwn12
-rw-r--r--doc/todo/commit_in_direct_mode/comment_1_7d9e62010905e0d70cb586534cc09a75._comment67
-rw-r--r--doc/todo/credentials-less_access_to_s3.mdwn13
-rw-r--r--doc/todo/credentials-less_access_to_s3/comment_1_eda703c0902d346e063c6d7ae00f6400._comment38
-rw-r--r--doc/todo/credentials-less_access_to_s3/comment_2_cefe0fbf1c3c6037c677ec6cff0aa6d6._comment9
-rw-r--r--doc/todo/credentials-less_access_to_s3/comment_3_26de94e8e3fefc9b47d1510bfb2dac9b._comment10
-rw-r--r--doc/todo/direct_mode_undo.mdwn88
-rw-r--r--doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment14
-rw-r--r--doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment17
-rw-r--r--doc/todo/do_not_commit_with_empty_messages.mdwn15
-rw-r--r--doc/todo/do_not_commit_with_empty_messages/comment_1_3cff336e58c26eafade4a37b0c9e0634._comment11
-rw-r--r--doc/todo/do_not_commit_with_empty_messages/comment_2_46a80050beba50360b1c212a9ab5a6b2._comment17
-rw-r--r--doc/todo/enable_fsck_--fast_for_S3_remotes.mdwn30
-rw-r--r--doc/todo/enable_fsck_--fast_for_S3_remotes/comment_1_b9c1da34a1d55333f864f2b7f9f4e4c7._comment9
-rw-r--r--doc/todo/enable_fsck_--fast_for_S3_remotes/comment_2_cf86f921db2a9f1f5ffad14616e3279b._comment84
-rw-r--r--doc/todo/enable_fsck_--fast_for_S3_remotes/comment_3_b7402508dfc7bbbd09382692aa740c39._comment88
-rw-r--r--doc/todo/extensible_addurl.mdwn88
-rw-r--r--doc/todo/extensible_addurl/comment_1_5dca2eb8ee9e8676d372cd4bc6934975._comment14
-rw-r--r--doc/todo/extensible_addurl/comment_2_0e27f12c998a3ac4f0d4c3d4c9898d26._comment13
-rw-r--r--doc/todo/fast_migrate.mdwn16
-rw-r--r--doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn29
-rw-r--r--doc/todo/get_--incomplete.mdwn8
-rw-r--r--doc/todo/git-annex-standalone_Debian_package.mdwn3
-rw-r--r--doc/todo/git-annex-standalone_Debian_package/comment_1_ef36b0265127611ffeea3a5ed8c29515._comment20
-rw-r--r--doc/todo/git-annex-standalone_Debian_package/comment_2_456413718e9faf3561a11000ee611611._comment10
-rw-r--r--doc/todo/git-annex-standalone_Debian_package/comment_3_22539df11d1a514987b9c257fd8b1998._comment8
-rw-r--r--doc/todo/git-annex-standalone_Debian_package/comment_4_0aecbfdc9048df2131d99ad316f5d6f7._comment8
-rw-r--r--doc/todo/git-annex-standalone_Debian_package/comment_5_b0730c577937f57547fabdd1ec57c01c._comment7
-rw-r--r--doc/todo/git-annex-standalone_Debian_package/comment_6_18bc628db6b9ec8942552fdf587e7d4f._comment9
-rw-r--r--doc/todo/git-annex-standalone_Debian_package/comment_7_f8cce1be3153f2b2e069800cb60c4fd3._comment8
-rw-r--r--doc/todo/git-annex_in_debian_sid.mdwn6
-rw-r--r--doc/todo/git-annex_in_debian_sid/comment_1_6225fd6237f77ab753429c72d60a9a9b._comment7
-rw-r--r--doc/todo/git-annex_info___34__du__34___remote_support.mdwn41
-rw-r--r--doc/todo/git-annex_info___34__du__34___remote_support/comment_1_9d3ac51bdf3bb749bc40a1bb05edbc76._comment30
-rw-r--r--doc/todo/git-annex_info___34__du__34___remote_support/comment_2_1547eb348bf30e5a06686aee082062f4._comment45
-rw-r--r--doc/todo/git-annex_metadata_extractor_progress_bar.mdwn7
-rw-r--r--doc/todo/git_annex_get___60__file__62___should_verify_file_hash.mdwn34
-rw-r--r--doc/todo/git_annex_get___60__file__62___should_verify_file_hash/comment_1_650e01a04104120ef1db4ff16fedc4f1._comment16
-rw-r--r--doc/todo/git_annex_grep.mdwn19
-rw-r--r--doc/todo/git_annex_grep/comment_1_890b3ecb679b941f9c0075ed360b203e._comment9
-rw-r--r--doc/todo/inject_on_import.mdwn63
-rw-r--r--doc/todo/inject_on_import/comment_1_314de82da94f47539e754e9bec950d7b._comment67
-rw-r--r--doc/todo/inject_on_import/comment_2_205ecbc7401f99fc83719acbf5da174e._comment26
-rw-r--r--doc/todo/merge_in_ram___40__disk__41____63__.mdwn8
-rw-r--r--doc/todo/notifications.mdwn6
-rw-r--r--doc/todo/podcatching_handling_updated_files.mdwn19
-rw-r--r--doc/todo/remote_groups_support_for_sync.mdwn5
-rw-r--r--doc/todo/replace_dataenc_with_sandi.mdwn6
-rw-r--r--doc/todo/resuming_encrypted_uploads.mdwn29
-rw-r--r--doc/todo/resuming_encrypted_uploads/comment_1_1832a6fb78e8ad7c838582f46731ac3b._comment8
-rw-r--r--doc/todo/resuming_encrypted_uploads/comment_2_2ecc8e782f49e90ed1549e9179eb1a1e._comment8
-rw-r--r--doc/todo/server-level_daemon__63__.mdwn203
-rw-r--r--doc/todo/server-level_daemon__63__/comment_1_1abea0cbfcc603da779a811731c38b5f._comment10
-rw-r--r--doc/todo/server-level_daemon__63__/comment_2_4a5ccb0e772352adbf20940c010895a5._comment9
-rw-r--r--doc/todo/server-level_daemon__63__/comment_3_60c5030a21c28b79f634f0655bc6c05d._comment7
-rw-r--r--doc/todo/subsecond_timestamping_of_the_--debug_output.mdwn4
-rw-r--r--doc/todo/unused_by_refspec.mdwn41
-rw-r--r--doc/todo/unused_by_refspec/comment_1_4612b5f485b313d59eb51bb519eb9471._comment7
-rw-r--r--doc/todo/vicfg_comment_gotcha.mdwn20
-rw-r--r--doc/todo/view_git_annex_log_in_webapp.mdwn7
-rw-r--r--doc/todo/view_git_annex_log_in_webapp/comment_1_945054441d93423b2c7b81712b364a3c._comment8
-rw-r--r--doc/todo/view_git_annex_log_in_webapp/comment_2_0f434dfe80e90951870218bc1b76c374._comment12
-rw-r--r--doc/todo/windows_git-annex_service.mdwn30
-rw-r--r--doc/todo/windows_git-annex_service/comment_11_c3af14453e99dae5425deaa26ca7310e._comment14
-rw-r--r--doc/todo/windows_git-annex_service/comment_11_e2dda1037cc85f03613f2774c139ad56._comment10
-rw-r--r--doc/todo/windows_git-annex_service/comment_12_249a48a241f14f32dab49f381d2de3b3._comment8
-rw-r--r--doc/todo/windows_git-annex_service/comment_12_d3d91ddc00bc275455022d86b779b148._comment10
-rw-r--r--doc/todo/windows_git-annex_service/comment_13_59fbe4d07cdbeb786bae792f9c709ddd._comment10
-rw-r--r--doc/todo/windows_git-annex_service/comment_13_f1d254fe85b0e5cbc7edf9096af4f942._comment27
-rw-r--r--doc/todo/windows_git-annex_service/comment_14_79fc0ff98c5bba2ed616e52e5a58e28f._comment8
-rw-r--r--doc/todo/windows_git-annex_service/comment_14_7d5fdac0084c4742967879f5f0f9fccf._comment8
-rw-r--r--doc/todo/windows_git-annex_service/comment_15_8f10491f8c0a151284e6d81a83eab212._comment12
-rw-r--r--doc/todo/windows_git-annex_service/comment_15_fcd34607116183cc1a764fb307eabe0a._comment10
-rw-r--r--doc/todo/windows_git-annex_service/comment_16_51800fd83cd979b021eabdd4c44cfd61._comment13
-rw-r--r--doc/todo/windows_git-annex_service/comment_16_6a6424f23772e57f1adb1807ca8b93fa._comment14
-rw-r--r--doc/todo/windows_git-annex_service/comment_17_62a1a33c2aaf4b0b8a0149ec526907d7._comment16
-rw-r--r--doc/todo/windows_git-annex_service/comment_18_3a408492107ca6f120b631ce8c41faef._comment23
-rw-r--r--doc/todo/windows_git-annex_service/comment_19_c6cbc8fe9218f90c661cd1026658c939._comment8
-rw-r--r--doc/todo/windows_git-annex_service/comment_20_ca245781a37db5546da3f7204adbeebb._comment17
155 files changed, 0 insertions, 2759 deletions
diff --git a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn
deleted file mode 100644
index c8c2dd83e..000000000
--- a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-One problem I keep having when using a direct repo is that in order to get to the previous versions of a file you have to convert that repo to indirect and then checkout previous commits this becomes problematic when the repo in question is large conversion takes a long time and applications gets confused if there are open files from the repo as they go from actual files to symlinks. Is it possible to have a separate annex command that will checkout a previous version of a file to a different directory so we can replace/inspect it.
-
-> I recently added a `git annex proxy` command, which can be used
-> to amoung other things, rewind a direct mode repo to have some old
-> version checked out.
->
-> For example, you can do: `git annex proxy git checkout old-version`
-> And then the old version of all annexed files will be checked out.
->
-> If the old version of a file is not available, it'll be a broken
-> symlink and you can then use `git annex get` etc to get the content from
-> some remote.
->
-> Once you have the old version of the file, you can
-> make a copy, and then switch back to the present with `git annex proxy
-> git checkout annex/direct/master`. Then you can add the copy of the old
-> version of the file to the repo, or whatever.
->
-> Or, sometimes more simply, you can `git annex proxy git revert $commit`
-> to revert a commit that made an unwanted change to a file.
->
-> Or, simpler still, `git annex undo $file` will undo the last change
-> that git-annex committed to that file, bringing back the old version.
->
-> So, this seems [[done]]! --[[Joey]]
diff --git a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_1_6f477af942aeb98683a56bcf0e819a38._comment b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_1_6f477af942aeb98683a56bcf0e819a38._comment
deleted file mode 100644
index e97e40f62..000000000
--- a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_1_6f477af942aeb98683a56bcf0e819a38._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="zardoz"
- ip="92.227.51.179"
- subject="comment 1"
- date="2014-05-13T20:25:22Z"
- content="""
-I’ve added a bug on basically the same issue.
-http://git-annex.branchable.com/bugs/Revert_to_old_file_version_in_direct_mode___40__VFAT__41__/
-
-One problem is that if your direct-mode repo is on VFAT, you can’t even switch to indirect mode temporarily.
-"""]]
diff --git a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_2_45c22f596a18d5dc2331cfeef8c767fa._comment b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_2_45c22f596a18d5dc2331cfeef8c767fa._comment
deleted file mode 100644
index 200210a02..000000000
--- a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_2_45c22f596a18d5dc2331cfeef8c767fa._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="zardoz"
- ip="92.227.51.179"
- subject="comment 2"
- date="2014-05-17T14:18:31Z"
- content="""
-It occured to me that one could do something like that by «git show
-earlier-commit:file > filename». A problem with this is that a
-subsequent «get» will get the old content, but won’t put it in place
-until invoking «fsck».
-
-"""]]
diff --git a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_3_cbca264d86fe733b8106a4bf50c0c6ff._comment b/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_3_cbca264d86fe733b8106a4bf50c0c6ff._comment
deleted file mode 100644
index 265e0995a..000000000
--- a/doc/todo/A_Way_To_Extract_Previous_Versions_of_a_File_From_a_Direct_Repo/comment_3_cbca264d86fe733b8106a4bf50c0c6ff._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="zardoz"
- ip="92.227.51.179"
- subject="comment 3"
- date="2014-05-17T14:24:20Z"
- content="""
-Plus it seems that the file can’t be dropped normally afterwards.
-"""]]
diff --git a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync.mdwn b/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync.mdwn
deleted file mode 100644
index d055a3556..000000000
--- a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-I like the way btsync search for the peer. So if I need to sync my laptop and other family laptop both with a total different and changing network setup the two device found each other do NAT traversal if needed use relays but the end the two folders are synced. But its closed-source :( I like git and git-annex looks really great. I'm learning it now.
-
-First I thought with xmpp I can sync files without ssh/rsync or other remote access to my devices just with two jabber account. Now I know I can't. :(
-
-It would be just great to have some means to sync files without cloud just the two device. Without the ssh / rsync jut share some secret and the devices do the rest. :-o
-
-Anyway thanks for hearing. I'm looking forward to know more about git-annex. Thank you for that sw. =-<>-=
-
-> [[design/assistant/telehash]] --[[Joey]]
-
-> > telehash has been mostly put aside for now, but there are interesting alternatives, including an [[special_remotes/ipfs]] special remote available. see [[todo/Bittorrent-like_features]] for followup on the discussion. so i'm marking this as a [[duplicate|done]]. --[[anarcat]]
diff --git a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_1_d828bc374e50a49101c0b863f9b33080._comment b/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_1_d828bc374e50a49101c0b863f9b33080._comment
deleted file mode 100644
index 13571e681..000000000
--- a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_1_d828bc374e50a49101c0b863f9b33080._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawkEHjHAWnJ0BJzdv_hePwU1my8X4wCseh8"
- nickname="Sz"
- subject="comment 1"
- date="2013-07-23T11:00:21Z"
- content="""
-Why not use xmpp for file transfer too not only for git sync?
-"""]]
diff --git a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_2_a4badfc248be428e6426a936212cc896._comment b/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_2_a4badfc248be428e6426a936212cc896._comment
deleted file mode 100644
index 2bff793f0..000000000
--- a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_2_a4badfc248be428e6426a936212cc896._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://johan.kiviniemi.name/"
- ip="83.145.237.224"
- subject="comment 2"
- date="2013-07-23T11:37:53Z"
- content="""
-Transferring the data over XMPP would almost certainly take too much XMPP server bandwidth, but using something like [libjingle](https://developers.google.com/talk/libjingle/) to set up P2P connections should work nicely. That would require libjingle (or equivalent) bindings for Haskell, though. Libjingle negotiates over XMPP to set up the P2P connection and provides a TCP-like layer for reliable, ordered communication. One could use that for both git metadata and the file transfers.
-"""]]
diff --git a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_3_0b04089d3d33fdb48eeb46bf168e9a3c._comment b/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_3_0b04089d3d33fdb48eeb46bf168e9a3c._comment
deleted file mode 100644
index d0c000d2b..000000000
--- a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_3_0b04089d3d33fdb48eeb46bf168e9a3c._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawkEHjHAWnJ0BJzdv_hePwU1my8X4wCseh8"
- nickname="Sz"
- subject="comment 3"
- date="2013-07-24T09:08:45Z"
- content="""
-I'm for it! +1
-"""]]
diff --git a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_4_2bcab1b7998b4df08fca41b8d810f115._comment b/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_4_2bcab1b7998b4df08fca41b8d810f115._comment
deleted file mode 100644
index f3bafca89..000000000
--- a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_4_2bcab1b7998b4df08fca41b8d810f115._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
- nickname="Richard"
- subject="comment 4"
- date="2013-08-03T07:12:40Z"
- content="""
-NAT traversal requires central infrastructure and is unreliable at best. Obviously, a for-profit entity like bittorrent can shoulder that.
-
-For LAN situations, [zeroconf](http://www.zeroconf.org/) along with passphrase-based pairing may be the long-term answer. Arguably, that would enhance vanilla Git almost as much as it would enhance git-annex, but that does not seem likely to happen.
-"""]]
diff --git a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_5_677e958c3f2effec7528b484aeb6478d._comment b/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_5_677e958c3f2effec7528b484aeb6478d._comment
deleted file mode 100644
index 07b001c2e..000000000
--- a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_5_677e958c3f2effec7528b484aeb6478d._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
- nickname="Laszlo"
- subject="comment 5"
- date="2013-08-25T07:48:18Z"
- content="""
-What is the problem with bittorrent protocol in general?
-It is some technicality or purely philosophical?
-
-Best,
- Laszlo
-
-"""]]
diff --git a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_6_56e53803fdede895cba717e6b6e9a1bb._comment b/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_6_56e53803fdede895cba717e6b6e9a1bb._comment
deleted file mode 100644
index 41e1bda78..000000000
--- a/doc/todo/A_really_simple_way_to_pair_devices_like_bittorent_sync/comment_6_56e53803fdede895cba717e6b6e9a1bb._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
- nickname="develop"
- subject="comment 6"
- date="2013-08-25T08:39:15Z"
- content="""
-I just did a cursory search on haskell torrent support. And the required pieces do seem to be be there.
-https://github.com/jlouis/combinatorrent or https://github.com/astro/haskell-torrent for downloading. i'm not sure if either supports DHT, but that exists here https://github.com/aninhumer/haskell-dht
-
-That said, i think implementing this would require some quite major overhauls in the system. It probably won't be trivial to implement.
-
-Note: This is for straight \"bittorrent\", not for \"bittorrent sync\". Bittorrent sync is closed source, and while an API might come at some point, it doesn't currently exist.
-
-I do seem to recall joeyh talking about supporting further transport protocols(perhaps through hooks). So I'm adding the above links for future reference if this does get implemented.
-
-But IMHO, this doesn't seem like a trivial feature to add. It might have to take some refactoring of some core git-annex parts. Certain things have to be changed quite a bit.
-
-Currently a git-annex client doesn't really require anything(except rsync) to sync from a remote. With bittorrent with DHT support to share between clients, suddenly git-annex will have to maintain a constant bittorrent thread(maybe multiple) that constantly seeds all the files in the git-annex repository, while waiting for a potential remote to request data.
-
-So even if this happens, it is probably gonna take some time.
-
-Just my 2cents.
-"""]]
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl.mdwn b/doc/todo/Add___39__dir__39___option_to_addurl.mdwn
deleted file mode 100644
index 834b6309f..000000000
--- a/doc/todo/Add___39__dir__39___option_to_addurl.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-Is it possible to add a '--dir' option to addurl (or some other mechanic) to make git annex create the symlinks in the specified directory?
-
-> --prefix makes sense, and might as well also add --suffix. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl/comment_1_0156942b1629ee994bf3699a56b3ceb7._comment b/doc/todo/Add___39__dir__39___option_to_addurl/comment_1_0156942b1629ee994bf3699a56b3ceb7._comment
deleted file mode 100644
index 112c4bb6b..000000000
--- a/doc/todo/Add___39__dir__39___option_to_addurl/comment_1_0156942b1629ee994bf3699a56b3ceb7._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-07-20T16:19:15Z"
- content="""
---file=subdir/foo will work, assuming subdir already exists.
-
-If the goal is just to add whatever filename addurl comes up with by
-default to a subdirectory, why not just `cd` to that subdir before
-running addurl?
-"""]]
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl/comment_2_15a6571d57794c3f1268c7a064e05bef._comment b/doc/todo/Add___39__dir__39___option_to_addurl/comment_2_15a6571d57794c3f1268c7a064e05bef._comment
deleted file mode 100644
index 95504b1b2..000000000
--- a/doc/todo/Add___39__dir__39___option_to_addurl/comment_2_15a6571d57794c3f1268c7a064e05bef._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- subject="comment 2"
- date="2015-07-21T12:11:45Z"
- content="""
-I was hoping something like tar's *-C*, or unzip's *-d* options would be easy to implement, given that git-annex will already create required directories when using --pathdepth. As far as I can tell, you can't mix --file and --pathdepth.. I'd have to reimplemnt --pathdepth and the directory creation in my script, which while not a major problem in Perl (aside from reinventing a potentially inferior wheel), may be if someone is using shell scripting.
-
-Maybe this request can be more generalised to *--prefix*?
-
-Then people could use --prefix to either just prefix the filename or set a directory for it to be put into. I had a look at Command/AddUrl.hs to see how feasible that would be but I'm struggling to follow it (not knowing Haskell yet).
-
-In the meantime(?), I have made my script remember the original directory it was started in and it cd's about as needed.
-"""]]
diff --git a/doc/todo/Add___39__dir__39___option_to_addurl/comment_3_62601714648631a31dee366a5a2e8f44._comment b/doc/todo/Add___39__dir__39___option_to_addurl/comment_3_62601714648631a31dee366a5a2e8f44._comment
deleted file mode 100644
index d521008bc..000000000
--- a/doc/todo/Add___39__dir__39___option_to_addurl/comment_3_62601714648631a31dee366a5a2e8f44._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- subject="comment 3"
- date="2015-07-22T07:41:53Z"
- content="""
-Yay! Awesome, thank you :)
-"""]]
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider.mdwn b/doc/todo/Add_gitlab.com_as_cloud_provider.mdwn
deleted file mode 100644
index 65c14b736..000000000
--- a/doc/todo/Add_gitlab.com_as_cloud_provider.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-Hi,
-
-[I don't know if this should go to todo or bugs or should be plainly ignored. Hope it's OK].
-
-Gitlab.com and Gitlab enterprise edition, but unfortunately not Gitlab community edition, now [provides git annex support](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem-of-versioning-large-binaries-with-git/). It works fairly based for the repos I have enabled it on. At the moment it's free, but one may have to pay for repos larger than 5Gb [in the future](https://about.gitlab.com/2015/02/22/gitlab-7-8-released/#comment-1870271594).
-
-Perhaps gitlab.com should be added to preconfigured cloud providers?
-
-> [[done]] although there are a few known bugs in the webapp's
-> implementation. --[[Joey]]
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_1_0dad4b86cda93dd5ca0c4fb049ff6d97._comment b/doc/todo/Add_gitlab.com_as_cloud_provider/comment_1_0dad4b86cda93dd5ca0c4fb049ff6d97._comment
deleted file mode 100644
index ab80ad5ee..000000000
--- a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_1_0dad4b86cda93dd5ca0c4fb049ff6d97._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-03-04T14:23:05Z"
- content="""
-This uses ssh, so the repository address can be pasted into the webapp
-as a ssh server, and it should work already.
-
-It probably does make sense to add gitlab.com as a canned solution alongside
-box.com and rsync.net in the webapp.
-
-Since the remote will be a full git repository, it should prompt the user
-if they want to enable gcrypt to encrypt all the content client-side.
-
-If gitlab has a reasonable API for creating a new repository, the webapp
-could optionally use that, instead of needing the user to create one
-themselves.
-"""]]
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_2_441c879e7aa60eb74e3a881de9c4e8ea._comment b/doc/todo/Add_gitlab.com_as_cloud_provider/comment_2_441c879e7aa60eb74e3a881de9c4e8ea._comment
deleted file mode 100644
index ce3541f5f..000000000
--- a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_2_441c879e7aa60eb74e3a881de9c4e8ea._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="Rasmus"
- subject="comment 2"
- date="2015-03-04T14:35:19Z"
- content="""
-It easy to setup. And it seems like as good a \"canned\" solution as box.net or whatever. I don't know if I would use it for sensitive stuff, but for a couple of repos, it makes sense to use it.
-
-There seems to be some support for creating new projects (which I assume is repos) [here](http://doc.gitlab.com/ee/api/projects.html).
-"""]]
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_3_9d60cfa947c5ce82c69fb77961db2d25._comment b/doc/todo/Add_gitlab.com_as_cloud_provider/comment_3_9d60cfa947c5ce82c69fb77961db2d25._comment
deleted file mode 100644
index 40b49f875..000000000
--- a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_3_9d60cfa947c5ce82c69fb77961db2d25._comment
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!comment format=mdwn
- username="http://rfhbuk.pip.verisignlabs.com/"
- nickname="rfhb"
- subject="git-annex: bad url ssh://git@gitlab.com:~/gitlabname/reponame.git"
- date="2015-04-26T12:19:37Z"
- content="""
-Adding an encrypted remote works (mind \":~/\"):
-
- > git remote add encrypted gcrypt::ssh://git@gitlab.com:~/gitlabname/reponame.git
- > git push encrypted master
- gcrypt: Repository not found: ssh://git@gitlab.com:~/gitlabname/reponame.git
- gcrypt: Setting up new repository
- gcrypt: Remote ID is :id:abcdefghijklmnopqrst
- Counting objects: 53, done.
- Compressing objects: 100% (52/52), done.
- Total 53 (delta 12), reused 0 (delta 0)
- gcrypt: Encrypting to: --throw-keyids --default-recipient-self
- gcrypt: Requesting manifest signature
- ...
- To gcrypt::ssh://git@gitlab.com:~/gitlabname/reponame.git
- * [new branch] master -> master
- >
-
-However, git-annex then fails:
-
- > git annex sync
- git-annex: bad url ssh://git@gitlab.com:~/gitlabname/reponame.git
-
-Should the encrypted repository be configured or added in a different way? Sorry, did not find it so easy to set up.
-
-"""]]
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_4_94c0a53da4f3bc89afd97a036d832f78._comment b/doc/todo/Add_gitlab.com_as_cloud_provider/comment_4_94c0a53da4f3bc89afd97a036d832f78._comment
deleted file mode 100644
index ec8d18cd1..000000000
--- a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_4_94c0a53da4f3bc89afd97a036d832f78._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-04-29T18:05:56Z"
- content="""
-Current status is that I'm waiting to see git-annex-shell on gitlab actally
-work. I get an API error. I've emailed the gitlab people about this.
-"""]]
diff --git a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_5_edb7d9de2ec51ab3f51a35848b63c842._comment b/doc/todo/Add_gitlab.com_as_cloud_provider/comment_5_edb7d9de2ec51ab3f51a35848b63c842._comment
deleted file mode 100644
index bfa5d36f7..000000000
--- a/doc/todo/Add_gitlab.com_as_cloud_provider/comment_5_edb7d9de2ec51ab3f51a35848b63c842._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 5"""
- date="2015-07-20T19:07:18Z"
- content="""
-Update: Gitlab is working with git-annex for me now.
-"""]]
diff --git a/doc/todo/Chunks_support_in_all_special_remotes.mdwn b/doc/todo/Chunks_support_in_all_special_remotes.mdwn
deleted file mode 100644
index 6d25ba684..000000000
--- a/doc/todo/Chunks_support_in_all_special_remotes.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-The special remote `directory` support files split in chunks, other special remotes do not.
-
-Support for chunks is useful, for example, to be able to upload large files over slow, unreliable connections or to minimize the amount of data to be sent when only part of a big file has been changed.
-
-Couldn't the code used to split, checksum and reconstruct the files in the `directory` remote be used also in all the other special remotes?
-
-> [[done]]; nearly all special remotes support chunking now, and the ones
-> that don't omit it for their own reasons, for example bup is not sped up
-> by using chunks, and glacier needs some additional work to support them.
-> --[[Joey]]
diff --git a/doc/todo/Chunks_support_in_all_special_remotes/comment_1_d12604dbeb42bbb6850425d237cb01e7._comment b/doc/todo/Chunks_support_in_all_special_remotes/comment_1_d12604dbeb42bbb6850425d237cb01e7._comment
deleted file mode 100644
index 93ff8e53f..000000000
--- a/doc/todo/Chunks_support_in_all_special_remotes/comment_1_d12604dbeb42bbb6850425d237cb01e7._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 1"
- date="2014-07-11T20:17:05Z"
- content="""
-See [[design/assistant/chunks]]
-"""]]
diff --git a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn
deleted file mode 100644
index c551b08d7..000000000
--- a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-I've just come across this issue and I'm not sure if git-annex is the right place to put it, but in case it is easy enough to do.. may as well ask!
-
-In this scenario, an online service (Bandcamp), automatically creates the archive file when downloading an album each and every time you download it. This results in identical files inside a zip, but different hashes due to the slightly different timestamps on the archive itself.
-
-Would it be possible for git-annex to be able to detect this scenario (in a manner similar to zipcmp) and redirect an add/import to the already existing copy?
-
-I've found this due to trying to decommission an old annex by `git annex import --clean-duplicates ~/annex_old/.git/annex/objects` and finding these files being left.
-
-[[done]] --[[Joey]]
diff --git a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment b/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment
deleted file mode 100644
index 19548edb3..000000000
--- a/doc/todo/Deduplicate_archive___40__i.e._zip__41___files/comment_1_619840f2337b018ff165565325cf1a61._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.7"
- subject="comment 1"
- date="2014-08-12T19:51:38Z"
- content="""
-All you need to do is unzip your zip file, and then `git annex add` or `git annex import` its contents. It will then automatically deduplicate.
-
-Due to the way compression works, two zip (or gz) files with identical contents but different checksums are unlikely to share many bytes in common. So git-annex cannot help with de-duplicating unless you unzip them.
-"""]]
diff --git a/doc/todo/Deleting_Unused_Files_by_Age.mdwn b/doc/todo/Deleting_Unused_Files_by_Age.mdwn
deleted file mode 100644
index babcb5633..000000000
--- a/doc/todo/Deleting_Unused_Files_by_Age.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-I periodically move unused files to one of my servers. What I would like to
-do is drop any unused file that has been unused for say more than 6 months?
-I would like to not drop all unused files.
-
-> It strikes me that this is quite similar to how git handles deleting
-> stale refs with the reflog. So, if `git annex unused` were changed to
-> also look at the reflog, it would keep all files referred to by all refs
-> in the reflog, until the reflog expires. You could then set reflog expiry
-> to 6 months, and be done.
->
-> However, I think that many users expect git annex unused to be able to
-> immediately find and remove a file after it's been deleted. So this
-> probably needs to be a configurable behavior. --[[Joey]]
-
->> Implemented this, `git annex unused --used-refspec=+refs/heads/*:reflog`
->> will consider all head refs as used (the default), plus consider all
->> refs in the reflog as used. [[done]] --[[Joey]]
diff --git a/doc/todo/Expose_auto-merge_for_manual__44___local_merges.mdwn b/doc/todo/Expose_auto-merge_for_manual__44___local_merges.mdwn
deleted file mode 100644
index c2cf26f83..000000000
--- a/doc/todo/Expose_auto-merge_for_manual__44___local_merges.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-The automatic conflict resolution currently seems to only work within
-the context of sync, when merging «synced/foo» into «foo». It would be
-convenient if this functionality were exposed for manual merges
-between local branches.
-
-E.g., one might invoke «git annex merge» or «git annex autoresolve»
-after «git merge» when conflicts are found.
-
-> [[done]] as resolvemerge. --[[Joey]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory.mdwn b/doc/todo/New_special_remote_suggeston_-_clean_directory.mdwn
deleted file mode 100644
index 98dd58d5e..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-The [[special remotes]] available all do great things and enable a ton of different services to be integrated.
-
-Strikingly, the one service I can't satisfactorily integrate with git-annex is a remote folder on a eg NAS (think: computer without git-annex installed) that I want to look like the original annex. As in, when I do a 'tree annexdir' it'd look the same on both locations (except, on the remote there would not be any symlinks, it'd be like it was in directmode, and there would not be a .git subdir).
-
-## Why? Use Case?
-
-I have a Synology NAS that I share access with with my wife. I want her to be able to access the files (photos/videos/music) in a sane manner (ie: not traversing sub-sub-sub 'randomly' named directories) but I also want to be able to manage them with git-annex on my machine (to gain the standard git-annex benefits, specifically the bob the archivist use case). The NAS has the ability to use ssh+rsync, so I'll assume those two tools can be used.
-
-This special remote could be thought of as the 'least common denominator of special remotes'; almost any server with ssh+rsync could be a remote, no matter if you have install privs or if the architecture (eg: ARM) is supported by git-annex.
-
-## Issues?
-
-First and foremost, this can't be (really really shouldn't be) a trusted remote; my wife could accidentally delete all files on the NAS while I am away. So my local git-annex shouldn't assume the NAS counts towards numcopies (unless I'm a real masochist).
-
-Secondly, what to do when files change/are added/removed on the special remote? Probably the same thing that the assistant does with everything. The only thing special is that new/modified files will need to be copied locally from this special remote before being added to the annex (to get hash and such).
-
-> This is not feaisble given git-annex's design. If I wanted to
-> make something completely unlike git-annex, I suppose it could be done,
-> but it's off topic here. [[wontfix|done]].
->
-> If you want to use git-annex on a Synology NAS, the arm standalone build
-> will work, and then you can use the command-line, or the assistant
-> to maintain a git repository that contains your files as desired. --[[Joey]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_10_4829c2a2302b4b9611deddfedfbaa944._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_10_4829c2a2302b4b9611deddfedfbaa944._comment
deleted file mode 100644
index 575748b56..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_10_4829c2a2302b4b9611deddfedfbaa944._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.87"
- subject="comment 10"
- date="2013-12-16T20:41:47Z"
- content="""
-How is that better than `rsync -a gitrepo cleandirectory`?
-
-Perhaps better related to the original problem of getting git-annex running on a Synology NAS, [[forum/new linux arm tarball build]].
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_1_4d81941fe53881eebff97109a07ba2f4._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_1_4d81941fe53881eebff97109a07ba2f4._comment
deleted file mode 100644
index 1ec5bbc54..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_1_4d81941fe53881eebff97109a07ba2f4._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="TroisSinges"
- ip="82.227.207.5"
- subject="comment 1"
- date="2013-11-27T14:59:11Z"
- content="""
-You could mount this NAS as a network drive on your computer (via samba for example or, even better, nfs), couldn't you? In this case you could use a real annex repository, and not a remote one.
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_2_660a5b764ad42468154b2bb94f8ec004._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_2_660a5b764ad42468154b2bb94f8ec004._comment
deleted file mode 100644
index 89663893e..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_2_660a5b764ad42468154b2bb94f8ec004._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://grossmeier.net/"
- nickname="greg"
- subject="mounting over NFS/etc ..."
- date="2013-11-27T16:01:50Z"
- content="""
-TroisSinges: Yeah, I could, but that'd limit me to being on the local network when I want to interact with the repo; not ideal.
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_3_eed178ce4bc4d2b3f08a1e3d3d62c086._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_3_eed178ce4bc4d2b3f08a1e3d3d62c086._comment
deleted file mode 100644
index 60d422838..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_3_eed178ce4bc4d2b3f08a1e3d3d62c086._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://a-or-b.myopenid.com/"
- ip="203.45.2.230"
- subject="comment 3"
- date="2013-11-28T02:36:15Z"
- content="""
-+1 on this suggestion.
-
-Not all NASs are created equal so SAMBA/NFS isn't always the most recent version, upgrades aren't always possible (yes, I'm looking at you Drobo!) so sometimes you just can't do what g-a needs to do (locks are my big problem).
-
-This would be a great option to have, even with the downsides of losing a lot of the awesome-sauce of git-annex.
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_4_1dae745cff1c0a38232d033dcc542ac4._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_4_1dae745cff1c0a38232d033dcc542ac4._comment
deleted file mode 100644
index f79fb4940..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_4_1dae745cff1c0a38232d033dcc542ac4._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmVICFY2CDP08xdsPr3cgmScomy9HA-1sk"
- nickname="Andrew"
- subject="comment 4"
- date="2013-11-29T04:11:24Z"
- content="""
-+1 for this style of repository (again).
-
-Presenting the content of a git-annex repository in a way that
-
-1. is transparent (nobody but me need know or care it's a git-annex repository)
-2. doesn't require installation (NAS or other device I can't install to)
-3. works without thinking (doesn't required commits or checkouts or manual deferencing symlinks - see also point 1)
-
-would fulfil the \"like dropbox but awesome\" idea from the Kickstarter.
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_5_8d6c791e5e2daec7b25828f6884a67c6._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_5_8d6c791e5e2daec7b25828f6884a67c6._comment
deleted file mode 100644
index f87bf1aec..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_5_8d6c791e5e2daec7b25828f6884a67c6._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.64"
- subject="comment 5"
- date="2013-12-05T19:52:52Z"
- content="""
-Comment #1 was my initial reaction. A regular direct mode git-annex repository on the mounted NAS share.
-
-I don't quite understand the response to it \"that'd limit me to being on the local network when I want to interact with the repo\". How could git-annex update this NAS if it's not on the local network?
-
-So far, the only reason that has been brought up that makes sense to me is locking. git-annex does use locking in its repository to prevent 2 git-annex commands run at the same time doing conflicting operations. (Lack of that locking could in some cases cause data loss.) I think git-annex's locking is limited entirely to files within the .git directory. So, if a SMB mount for a NAS does not support locking, one approach could be to move the .git directory to local disk, and use `GIT_DIR` to make it be used when operating in that repository. This should get you exactly what was requested. Whether it makes sense or is sufficiently easy to use is another question.
-
-I tend to think that a better use of a NAS in many cases is to put a directory or rsync (if it supports rsync) special remote on the NAS, and have git-annex on the individual client machines. The webapp could have a UI that makes setting up a NAS like that simple, and it would be easy to do.
-
-The use case for having a mirrored directory tree on the NAS seems to be limited to when the clients using it are something that cannot run git-annex itself, but that still cares about filenames, as opposed to just operating on file contents.
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_6_92ef2d4a7ed47000fda02732b4794dc0._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_6_92ef2d4a7ed47000fda02732b4794dc0._comment
deleted file mode 100644
index 75614d69f..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_6_92ef2d4a7ed47000fda02732b4794dc0._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.64"
- subject="comment 6"
- date="2013-12-05T19:57:32Z"
- content="""
-The other problem with this idea is that it seems to want the assistant to watch the file tree in the NAS, and make commits etc when files there are changed.
-
-But, any computer on the network that has the NAS mounted can change a file! AFAIK there is no interface to detect when such changes have happened; inotify does not help. It seems git-annex would have to expensively periodically scan the directory to find changes.
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_7_78fb5cdd61220ffcf0ae1eaf266985ec._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_7_78fb5cdd61220ffcf0ae1eaf266985ec._comment
deleted file mode 100644
index 7ff072d4c..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_7_78fb5cdd61220ffcf0ae1eaf266985ec._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="http://grossmeier.net/"
- nickname="greg"
- subject="comment 7"
- date="2013-12-05T21:20:54Z"
- content="""
-> How could git-annex update this NAS if it's not on the local network?
-
-ssh and port forwarding, like any home server.
-
-> I tend to think that a better use of a NAS in many cases is to put a directory or rsync (if it supports rsync) special remote on the NAS, and have git-annex on the individual client machines.
-
-I'm thinking of this like the public view of a git-annex repository. I want anyone to be able to view/download the files as they normally would.
-
-> The use case for having a mirrored directory tree on the NAS seems to be limited to when the clients using it are something that cannot run git-annex itself, but that still cares about filenames, as opposed to just operating on file contents.
-
-That's exactly my use case.
-
-> So far, the only reason that has been brought up that makes sense to me is locking.
-
-Locking is actually tangential to the issue/use case. Direct mode would solve that issue, but git-annex isn't built for the Synology NAS platform, so it isn't an option.
-
-> The other problem with this idea is that it seems to want the assistant to watch the file tree in the NAS, and make commits etc when files there are changed.
-
-I think you read too much into that part. :) I only want git-annex to do things when I 'sync' or similar. I'm actually not wanting *the assistant* to do much in this case. This might even be a non-assistant applicable use case. (I don't use the assistant in my large repositories, like photos and videos and music.) I only mentioned the assistant to point out that it has some of the logic (what to do with changed/deleted files) already.
-
-And honestly, I'd be fine with an implementation that overwrote all changes on this special remote on each sync (as needed). The response to that suggestion is \"just use rsync by itself to put the files on the NAS\" but that assumes I have all of the files on my local checkout (I don't).
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_8_21712dfee4f37232c34eddbce2427691._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_8_21712dfee4f37232c34eddbce2427691._comment
deleted file mode 100644
index 3aeb04e53..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_8_21712dfee4f37232c34eddbce2427691._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="gan"
- ip="85.224.8.104"
- subject="Hook implementation?"
- date="2013-12-07T01:15:46Z"
- content="""
-1. I would propose the name \"plain directory\" for this special remote. Clean is not a good description, IMHO.
-
-2. When I read this a week ago I took the opportunity to play with the special remote hook, because as far as I can understand this could be a relatively trivial implementation that need not necessarily be in git-annex \"core\". And I'd like to contribute back to the git-annex community and help a brother out... I used the method of calling a single script from all hook points, and inside it look at what operation was requested.
-I didn't get that far before giving up however. I got the feeling that hook would benefit from some extension and a bit more complete API to really create the opportunity for third-party extensions to git-annex this way. I would prefer that the hook script can handle several instances of remotes without creating custom hook scripts for each instance. Specifically I think a hook is needed also for \"init\" of a new remote (to get a unique identifier, and other parameters given by the user such as in this particular case, the path to the \"clean directory\") What do you think?
-"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_9_0ba57952532d5ef1f2bbfb163faa3b2f._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_9_0ba57952532d5ef1f2bbfb163faa3b2f._comment
deleted file mode 100644
index d96ac6987..000000000
--- a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_9_0ba57952532d5ef1f2bbfb163faa3b2f._comment
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE"
- nickname="Thomas"
- subject="pseudocode"
- date="2013-12-08T15:23:36Z"
- content="""
-The implementation should really be nothing more than the following to be run from a regular git annex repository with a configures special plain directory remote:
-
- foreach(path : allAnnexedFiles) {
- if(remote.exists(path) && remote.filesize(path) === expectedFilesize) goto finally;
-
- if(fileAvailableLocally(path)) {
- copyFileToRemote(path);
- goto finally;
- }
-
- if(shouldCopyFromElsewhere && canCopyFileFromSomeOtherRemote(path)) {
- copyFileFromSomeOtherRemoteToRemote(path);
- }
-
- finally:
- logThatFileExistsOnRemote(path);
- }
-
- foreach(remotePath : filesInRemoteDir) {
- if(fileIsAnnexed(remotePath) || fileIsIgnored(remotePath) continue;
-
- delete(remotePath);
- }
-
-The above pseude code assumes
-- that the no other process is working on the remote at the same time.
-- that the remote is not trusted.
-- that nobody expects changes done at the remote to propagate to other clones.
-"""]]
diff --git a/doc/todo/Output_key_with_import__47__deduplicate.mdwn b/doc/todo/Output_key_with_import__47__deduplicate.mdwn
deleted file mode 100644
index 81bb653fc..000000000
--- a/doc/todo/Output_key_with_import__47__deduplicate.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-When using
-
- git annex import --deduplicate -- ~/directory/to/import
-
-would it be possible to output the keys for duplicate files? This would allow people to find where in the annex the files already exist.
-
-e.g.
-
- import ~/directory/to/import/001.txt ok
- import ~/directory/to/import/002.txt ok
- import ~/directory/to/import/002_d.txt (duplicate SHA256E-s261--fb1230987ac123098...) ok
- import ~/directory/to/import/003.txt ok
-
-Then you could use
-
- git log -S SHA256E-s261--fb1230987ac123098...
-
-to find out where it is already.
-
-Not sure if that is the nicest layout.. (or what it might break).
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/Output_key_with_import__47__deduplicate/comment_1_9eefceaa052a4587b8448c2f8fd24d97._comment b/doc/todo/Output_key_with_import__47__deduplicate/comment_1_9eefceaa052a4587b8448c2f8fd24d97._comment
deleted file mode 100644
index 56072128b..000000000
--- a/doc/todo/Output_key_with_import__47__deduplicate/comment_1_9eefceaa052a4587b8448c2f8fd24d97._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-03-31T19:22:47Z"
- content="""
-Yeah, that seems fairly reasonable, it already says "duplicate..."
-and it's easy to add the key.
-
-I don't see a good place to add a note about git log -S$KEY though,
-so I guess the user will need to find out how to do that on their
-own, if they want to search for eg, deleted keys.
-"""]]
diff --git a/doc/todo/Recovering_from_a_bad_sync.mdwn b/doc/todo/Recovering_from_a_bad_sync.mdwn
deleted file mode 100644
index d60406568..000000000
--- a/doc/todo/Recovering_from_a_bad_sync.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-Instead of using `sync origin` for the first sync and a simple `sync` for the other syncs,
-
- # on pc1
- git annex init "pc1"
- git annex direct
- git annex add .
- git annex sync origin # remote specified on the first sync
-
- # add some files
- git annex add .
- git annex sync
-
-I used `sync` first and only later I used `sync origin`
-
- # on pc1
- git annex init "pc1"
- git annex direct
- git annex add .
- git annex sync
-
- # add some files
- git annex add .
- git annex sync origin # remote specified on a later sync
-
-These sequences of commands create two completely different git histories.
-
-More important, if one clones on pc2 the first repository, they will see both the pc1 remote and the pc2 remote. Instead, if one clones on pc2 the repository created by the second combination of commands, they will see only the pc2 remote.
-
-What commands should I use on pc1 to fix the history so that when pc2 clones from the origin repository it will see both the pc1 remote and its own local remote?
-
-> [[done]]; fixed per my comments. --[[Joey]]
diff --git a/doc/todo/Recovering_from_a_bad_sync/comment_1_6f5f518a3190534b737203787149ef3c._comment b/doc/todo/Recovering_from_a_bad_sync/comment_1_6f5f518a3190534b737203787149ef3c._comment
deleted file mode 100644
index fc354be3d..000000000
--- a/doc/todo/Recovering_from_a_bad_sync/comment_1_6f5f518a3190534b737203787149ef3c._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 1"
- date="2014-07-14T18:27:43Z"
- content="""
-If this is a todo item at all, it may make sense to make `git annex sync` sync even with git remotes that have no annex-uuid.
-
-As far as solving the problem, I think you just need to sync more in order to get the full list of remotes propigated around to all the remotes. Sync automatically merges disconnected git histories no matter how they got that way or how long they have been disconnected or diverged.
-"""]]
diff --git a/doc/todo/Recovering_from_a_bad_sync/comment_2_e494df56dcede4d14bcaa4cdbf3da4f5._comment b/doc/todo/Recovering_from_a_bad_sync/comment_2_e494df56dcede4d14bcaa4cdbf3da4f5._comment
deleted file mode 100644
index 011129336..000000000
--- a/doc/todo/Recovering_from_a_bad_sync/comment_2_e494df56dcede4d14bcaa4cdbf3da4f5._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 2"
- date="2014-07-14T18:38:58Z"
- content="""
-It seems that the person who filed this todo item also filed [[bugs/sync does not commit with alwasycommit = false]] and got pretty confused by that.
-
-So, repurposing this todo item to be about perhaps syncing with remotes that have no annex-uuid by default.
-"""]]
diff --git a/doc/todo/Recovering_from_a_bad_sync/comment_3_4d4904bcbf97401c7c11338f32577f96._comment b/doc/todo/Recovering_from_a_bad_sync/comment_3_4d4904bcbf97401c7c11338f32577f96._comment
deleted file mode 100644
index 1d173f0ef..000000000
--- a/doc/todo/Recovering_from_a_bad_sync/comment_3_4d4904bcbf97401c7c11338f32577f96._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 3"
- date="2014-07-15T18:23:50Z"
- content="""
-Making `git annex sync` automatically sync with remotes with no annex-uuid is more complicated than I first thought.
-
-In the case of a remote accessed over ssh, `git annex sync` already does sync with such a remote. Of course, it will set annex-ignore on it, since it has no annex-uuid. (Needed eg, for github, or just for preventing a repo from being used by git-annex if you don't want it to be.) Still, the git branches get synced, which is the behavior that we want.
-
-So, only local remotes are affected. Note that `git annex assistant` automatically git-annex inits the local remote when it lacks a uuid, and syncs with it. That seems ok.
-
-However `git annex sync` currently ignores the local remote when it has no uuid. Seems that this happens due to a bug, not intentionally. tryGitConfigRead tries to bootstrap up an annex state to read the repos's config, but this cannot be done in a repo that is not yet initialized. Result is the repo state is not read, and so it's treated as a local remote that is not currently available (ie, a disconnected disk).
-"""]]
diff --git a/doc/todo/Recursive_addurl_simlar_to_wget_--recursive.mdwn b/doc/todo/Recursive_addurl_simlar_to_wget_--recursive.mdwn
deleted file mode 100644
index 629a9a120..000000000
--- a/doc/todo/Recursive_addurl_simlar_to_wget_--recursive.mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-## Use Case
-
-I want to import a bunch of files that are hosted somewhere, they nicely sorted by year and such. Instead of addurl'ing each by hand (or writing a custom script each time this happens) I want to simply:
-
-git-annex addurl --recursive http://somehost.tld/somedir/
-
-For sanity, mimicking wget closely with default depth of 5, but customizable with the --level switch.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/Recursive_addurl_simlar_to_wget_--recursive/comment_1_4ecd9ddba1b63b571555ec9bef18e2d8._comment b/doc/todo/Recursive_addurl_simlar_to_wget_--recursive/comment_1_4ecd9ddba1b63b571555ec9bef18e2d8._comment
deleted file mode 100644
index 72326c478..000000000
--- a/doc/todo/Recursive_addurl_simlar_to_wget_--recursive/comment_1_4ecd9ddba1b63b571555ec9bef18e2d8._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.244"
- subject="comment 1"
- date="2014-04-07T20:10:51Z"
- content="""
-Recursively traversing websites is *hard*, so I would rather leave it out of git-annex.
-"""]]
diff --git a/doc/todo/Shorten_long_file_names_preventing_git_checkout.mdwn b/doc/todo/Shorten_long_file_names_preventing_git_checkout.mdwn
deleted file mode 100644
index 4b618e72b..000000000
--- a/doc/todo/Shorten_long_file_names_preventing_git_checkout.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-Submitting here from https://github.com/joeyh/git-annex/pull/36
-
- commit 05b7e0d2e87c1c92df773d72ee0ac7c9638be058
- Author: Eric OConnor <eric@oco.nnor.org>
-
-> I've applied this patch. Thanks Eric.
->
-> Of course, nothing is preventing filenames > 255 being added in the
-> future. Based on the number that had to be renamed, this is pretty low
-> probability, but it does happen. It would need changes to ikiwiki to add
-> an enforced limit. If someone wants to patch ikiwiki that way, I'll
-> enable it.
->
-> For now, [[done]]. --[[Joey]]
diff --git a/doc/todo/Specify_a_version_for_the___39__feed__39___build_dependency..mdwn b/doc/todo/Specify_a_version_for_the___39__feed__39___build_dependency..mdwn
deleted file mode 100644
index 45da3273a..000000000
--- a/doc/todo/Specify_a_version_for_the___39__feed__39___build_dependency..mdwn
+++ /dev/null
@@ -1,9 +0,0 @@
-(I'm not sure how you would like to do this -- should I send commits for you to pull, or do you prefer a patch pasted in here?)
-
-In any case, here's a build-deps fix, originally sent as a pull request [1].
-
-https://github.com/joeyh/git-annex/compare/master...jlebar:build-deps
-
-[1] https://github.com/joeyh/git-annex/pull/37
-
-> This is fine. Thanks, I merged your patch. [[done]] --[[Joey]]
diff --git a/doc/todo/Support_--jobs_option_for___39__sync_--content__39__.mdwn b/doc/todo/Support_--jobs_option_for___39__sync_--content__39__.mdwn
deleted file mode 100644
index 9923dcff6..000000000
--- a/doc/todo/Support_--jobs_option_for___39__sync_--content__39__.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-As the subject says. I mostly use `git annex sync --content` to transfer
-files between repositories, as its easier than running `git annex sync`, a
-bunch of `git annex copy`s and then a `git annex get` to make sure I have
-all the files I should have. It would be good if the shortcut could also
-work in parallel.
-
-> It also can be faster to push concurrent. OTOH, concurrent pulls
-> can lead to the same git objects being downloaded redundantly, so best to
-> avoid those I think.
->
-> I've implemented this. It suffers from the same
-> lack of support for displaying progress when running it parallel as
-> documented on [[parallel_get]]. Other than that wart, this is [[done]].
-> --[[Joey]]
diff --git a/doc/todo/Support_dbus_monitor_for_networkd.mdwn b/doc/todo/Support_dbus_monitor_for_networkd.mdwn
deleted file mode 100644
index c2936dc51..000000000
--- a/doc/todo/Support_dbus_monitor_for_networkd.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-As of late, systemd-networkd supports a network monitor via dbus under “org.freedesktop.network1“. It would be convenient if the assistant supported this.
-
-Cf. this [commit](http://cgit.freedesktop.org/systemd/systemd/commit/?id=e331e24649213f2e093e16e4d3d64ee823dfc375).
-
-> patches! Awesome! merged [[done]] --[[Joey]]
diff --git a/doc/todo/Support_dbus_monitor_for_networkd/comment_1_c34efaec014646bd52b5a4cc36913982._comment b/doc/todo/Support_dbus_monitor_for_networkd/comment_1_c34efaec014646bd52b5a4cc36913982._comment
deleted file mode 100644
index 554e8d01c..000000000
--- a/doc/todo/Support_dbus_monitor_for_networkd/comment_1_c34efaec014646bd52b5a4cc36913982._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="eigengrau"
- subject="comment 1"
- date="2015-06-02T14:40:47Z"
- content="""
-Submitted a patch.
-"""]]
diff --git a/doc/todo/Time_Stamping_of_Events_in_Webapp.mdwn b/doc/todo/Time_Stamping_of_Events_in_Webapp.mdwn
deleted file mode 100644
index 0762f47ba..000000000
--- a/doc/todo/Time_Stamping_of_Events_in_Webapp.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-Currently events happening in the webapp (sync upload etc. on the right) has no time stamp thus user has no way to tell when was the last sync happened. Which is problematic when not using XMPP and repos lag behind.
-
-> [[dup|done]] of <http://git-annex.branchable.com/todo/wishlist__91__minor__93__:_add_time_stamps_to_annex_log_popups_in_webapp/> --[[Joey]]
diff --git a/doc/todo/Views_Demo.mdwn b/doc/todo/Views_Demo.mdwn
deleted file mode 100644
index 54704afa6..000000000
--- a/doc/todo/Views_Demo.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-Joey,
-
-I've been thinking about leveraging git-annex for a workgroup document repository and I have just watched your views demo. The timing of the demo is great because I need to deploy a document repository with per-document metadata and your views concept seems like a great mechanism for associating metadata to documents and for displaying that metadata.
-
-While I don't expect to use your views concept for my workgroup repostory, a later iteration might do.
-
-The metadata in my use case begins with all the weird metadata seen on a book's copyright page. In addition, per-document provenance, like how one found the document and (if we're lucky) a URL where the latest version of the document may be found. Metadata values may be simple strings or may be markdown text.
-
-So, are you considering a metadata syntax that can support complex metadata? One example is multiple authors. Another issue is complex metadata values, like key=abstract and value="markdown text...".
-
-FWIW,
-
-Bob
-
-> [[closing|done]]; requested feature was already present --[[Joey]]
diff --git a/doc/todo/Views_Demo/comment_1_d7c83a0e9a83e4a05aa74a34a7e1cf19._comment b/doc/todo/Views_Demo/comment_1_d7c83a0e9a83e4a05aa74a34a7e1cf19._comment
deleted file mode 100644
index 4c9b05635..000000000
--- a/doc/todo/Views_Demo/comment_1_d7c83a0e9a83e4a05aa74a34a7e1cf19._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.172"
- subject="comment 1"
- date="2014-02-24T18:17:04Z"
- content="""
-All that should work fine. All metadata fields are multivalued, and the value can be any arbitrary data.
-"""]]
diff --git a/doc/todo/What_if_the_active_annex__39__ed_files_were_not_symlinks__63__.mdwn b/doc/todo/What_if_the_active_annex__39__ed_files_were_not_symlinks__63__.mdwn
deleted file mode 100644
index 320976925..000000000
--- a/doc/todo/What_if_the_active_annex__39__ed_files_were_not_symlinks__63__.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-So annex is super cool and all. But there is one really annoying thing about it. The symlinks disrupt workflow really horribly! For example if I have a .psd file that is annex'd and I open that file in photoshop, edit it, then try to save it again. It doesn't allow me, because the actual file is the one deep in the annex sub structure that is read only. There a bunch of other annoyances like this. But you basically can't work with annex'd files without some additional struggle.
-
-But there is a solution to this. Just don't symlink the files that are active. I think potentially the simplest way to do this is to have a 'annex' and 'unannex' command. Or rather, a 'create symlink' and 'uncreate symlink' command.
-
-So then you can be going along, doing your work, nothing in your directory symlinked.
-
-You then type you 'annex symlink' command all priorly annexed filed will be deleted and replaced with their symlinks.
-
-Then you can add your new files to annex. Adding new files will just automatically symlink them unless you put like a -ns or something to signify to not symlink them.
-
-With all priorly annexed filed symlinked and all your new files symlinked, you then git commit and push.
-
-Then you do a git annex unsymlink command. And then all your symlinks are deleted and the actual file placed there.
-
-Then you just type git annex symlink again to re-symlink them all.
-
-> I think you are looking for the `unlock` and `add` (or `lock`) commands. Basically, to edit the file in photoshop, you want:
->
-> <pre>
-> git annex unlock file.psd
-> photoshop file.psd # ...
-> git annex add file.psd # if you are happy with your changes or...
-> git annex lock file.psd # if you want to discard your changes
-> </pre>
->
-> So basically what you are asking for is already [[done]], in my mind. I still think there are significant [[usability issues|forum/usability:_what_are_those_arrow_things__63__/]] with symlinks, but that's another story. --[[anarcat]]
diff --git a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode.mdwn b/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode.mdwn
deleted file mode 100644
index 751ee1942..000000000
--- a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode.mdwn
+++ /dev/null
@@ -1,10 +0,0 @@
-Please let me know if there already is a way of achieving this; I’ve googled around a lot, but could not find any information pertaining to my particular problem.
-
-I am using direct mode in a bunch of repositories where I need quick write access to content and where I am not interested in preserving history. Some of these repositories do contain regular symlinks, however. Now, I suppose that in indirect repos, the way of adding symlinks would be to just «git add» them. However, since these are direct mode repos, I cannot do this.
-
-Is there already a good way of adding symlinks in direct mode? If not, I would find it useful if there were one.
-
-Best regards,
-T.
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_1_6c6e192bc0f70a386cd4275f98e1bd6f._comment b/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_1_6c6e192bc0f70a386cd4275f98e1bd6f._comment
deleted file mode 100644
index 83ccf32de..000000000
--- a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_1_6c6e192bc0f70a386cd4275f98e1bd6f._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="zardoz"
- ip="134.147.14.84"
- subject="comment 1"
- date="2014-07-07T12:48:07Z"
- content="""
-Can it be considered safe adding symlinks via «git -c core.bare=false add symlink; git -c core.bare=false commit -m Update»? If not, is there a better way?
-"""]]
diff --git a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_2_8e22cfdbeb2c841870a623cf4c7baf60._comment b/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_2_8e22cfdbeb2c841870a623cf4c7baf60._comment
deleted file mode 100644
index b88ec65ae..000000000
--- a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_2_8e22cfdbeb2c841870a623cf4c7baf60._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.2"
- subject="comment 2"
- date="2014-07-10T19:54:30Z"
- content="""
-That is safe, but you have to be very careful anytime you override with -c core.bare=false. For example, if you did a `git commit -a`, it would commit your large files directly into git, which you don't want.
-
-
-"""]]
diff --git a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_3_0039faa19e35eada1ff17eac6fbcab29._comment b/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_3_0039faa19e35eada1ff17eac6fbcab29._comment
deleted file mode 100644
index d9b2d2b77..000000000
--- a/doc/todo/__171__git_annex_add__187___for_symlinks_in_direct_mode/comment_3_0039faa19e35eada1ff17eac6fbcab29._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-07-07T20:02:02Z"
- content="""
-Recently, `git annex add` started adding files
-to git, if annex.largefiles didn't match them.
-
-So, it's possible to use that to add eg, source files. But it currently
-skips symlinks (unless they're git-annex symlinks).
-
-What I think makes sense to do is make it also process
-symlinks, and always check them into git as-is. So, git-annex add becomes
-like git-add except smart about adding large files to the annex.
-"""]]
diff --git a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks.mdwn b/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks.mdwn
deleted file mode 100644
index 80d5a3d25..000000000
--- a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-In my quest to get git-annex to do what I want, even if it is weird and unusual..
-
-Would it be possible for 'git annex fix' to work even on untracked symlinks (perhaps only with '--force'?), where the symlink is otherwise in a git-annexy format?
-
-This would allow me to do stuff like this:
-
- $ cd ~/old_broken_annex
- $ cp -t ~/other_annex/presentcheck *
- $ cd ~/other_annex/presentcheck
-
- ### This currently does nothing if the symlinks are untracked
- $ git annex fix --force .
-
- $ find -type l -not -xtype l -print0 | xargs -0 git add
- $ git commit -m "yay, we found some files!"
- $ find -type l -xtype l -print0 | xargs -0 mv -t ~/files_not_found
-
-Admittedly, to do this now, you just have to stage the symlinks before you fix but there may be other situations where this is useful (and I can't think of anything else you would want 'fix --force' to do)..
-
-> Per my comment, this is not a good idea, so [[done]] --[[Joey]]
diff --git a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_1_b795d0bfa64654bf82684da961815cea._comment b/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_1_b795d0bfa64654bf82684da961815cea._comment
deleted file mode 100644
index f8eb04775..000000000
--- a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_1_b795d0bfa64654bf82684da961815cea._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-03-27T20:48:07Z"
- content="""
-Currently git-annex uses git-ls-files to find the files to act on.
-This would requires running git-ls-files twice, once with --others to find
-the files not checked into git.
-
-I don't like the added complexity, the slowdown for everyone else,
-etc.
-
-Also, I think it's very reasonable that git-annex commands do not
-act on files that are not checked into git (except for git-annex add of
-course). Acting on files that are not checked into git violates least
-surprise.
-
-So, just add the file to git if you want git-annex fix to
-act on it. You don't even have to commit the file, you can just
-stage it in the index, and then un-stage it after git-annex is done with
-it, if for some reason you don't want to check it into git.
-"""]]
diff --git a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_2_0ab89dad1289b5d349ecd452c3f5e4f5._comment b/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_2_0ab89dad1289b5d349ecd452c3f5e4f5._comment
deleted file mode 100644
index 8fe0a8ccd..000000000
--- a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_2_0ab89dad1289b5d349ecd452c3f5e4f5._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- subject="comment 2"
- date="2015-03-28T01:59:51Z"
- content="""
-Okie dokie, thank you for considering it :)
-"""]]
diff --git a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_3_dcb651fa8a1ec52d6016e11bf06fab5d._comment b/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_3_dcb651fa8a1ec52d6016e11bf06fab5d._comment
deleted file mode 100644
index 421f3750a..000000000
--- a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_3_dcb651fa8a1ec52d6016e11bf06fab5d._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnm19dBCRphmtjXfopm_NpvnRwz-qIJ2Tw"
- nickname="Remi"
- subject="comment 3"
- date="2015-03-28T07:51:09Z"
- content="""
-I completely disagree with the last surprise argument. I'm regularly in this situation, and each time I'm surprised when `git annex fix` do not fix the symlinks, even when I'm explicitly listing the list I want to fix.
-"""]]
diff --git a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment b/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment
deleted file mode 100644
index 34d959578..000000000
--- a/doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
- nickname="Jean"
- subject="I'm with Remy here"
- date="2015-04-09T05:02:50Z"
- content="""
-I can't even comprehend how git-annex gets into this situation. From what angle does it make sense to ever have a symlink pointing at a `.git/annex/objects/...` and not be tracked?
-"""]]
diff --git a/doc/todo/add_--quiet_option_to_fsck.mdwn b/doc/todo/add_--quiet_option_to_fsck.mdwn
deleted file mode 100644
index 67412bf02..000000000
--- a/doc/todo/add_--quiet_option_to_fsck.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-ATM it floods the screen with ok for every file (in non-interactive session even split across 2 lines). As such it is just a pure noise if I care to check if entire repo is ok -- a single summary line, possibly preceeded with reports about broken files would be much better imho.
-
-Cheers!
-
-> I jumped in a time machine, popped out in 2010 and implemented it
-> them, to ensure the bug is already fixed on your computer. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/add_--quiet_option_to_fsck/comment_1_9c70dcdf11d23a33d1007005bbd58e60._comment b/doc/todo/add_--quiet_option_to_fsck/comment_1_9c70dcdf11d23a33d1007005bbd58e60._comment
deleted file mode 100644
index e38c72fa2..000000000
--- a/doc/todo/add_--quiet_option_to_fsck/comment_1_9c70dcdf11d23a33d1007005bbd58e60._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-05-30T15:30:13Z"
- content="""
-git-annex fsck already has this --quiet option. (Same option works with
-most other git-annex commands too.
-"""]]
diff --git a/doc/todo/allow_removing_jabber_configuration.mdwn b/doc/todo/allow_removing_jabber_configuration.mdwn
deleted file mode 100644
index 62370258d..000000000
--- a/doc/todo/allow_removing_jabber_configuration.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-right now it is unclear through the webapp how to unconfigure a jabber
-account, which is especially critical considering the password needs to be
-stored in the clear (where?). -- [[anarcat]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__.mdwn b/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__.mdwn
deleted file mode 100644
index b1adfdcc2..000000000
--- a/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-When maintaining several replica of the same git-annex repo "git annex sync" is quite handy.
-But it would be even handier if "git annex sync" would also perform automatic "git merge synced/*" actions on all remotes.
-
-Clearly, this is beneficial when the user wants to keep all working copies synchronized.
-This is likely the case in git annex assistant like scenarios. And it's always the case in my day to day scenarios :-)
-I'm not sure about other use cases that I've hard time imagining...
-
-As just discussed on IRC (#vcs-home/OFTC), this could be implemented in various ways:
-
-1) By doing ssh on each remote and running the appropriate "git merge ..." commands there.
- The drawback of this is that quite often it won't be permitted to ssh on the remote and run arbitrary commands there.
-
-2) Having a default post-receive hook, created at the time of "git annex init" that automatically does the merges when contacted by other remotes as a consequence of "git annex sync".
-
-
-Thanks for git-annex!
-
-> [[done]]; use new git feature instead. --[[Joey]]
diff --git a/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__/comment_1_60e5067c2be9e8df7bd1b6d954c60cad._comment b/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__/comment_1_60e5067c2be9e8df7bd1b6d954c60cad._comment
deleted file mode 100644
index 4b0ea8e1c..000000000
--- a/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__/comment_1_60e5067c2be9e8df7bd1b6d954c60cad._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-07-07T19:54:07Z"
- content="""
-Git recently got receive.denyCurrentBranch=updateInstead,
-which allows the remote working tree to be updated automatically
-(as long as there are no changes in the work tree or staged in the index).
-
-This seems much better than putting a hack into git-annex.
-"""]]
diff --git a/doc/todo/better_git-annex-shell_init_workflow.mdwn b/doc/todo/better_git-annex-shell_init_workflow.mdwn
deleted file mode 100644
index 58bf0216a..000000000
--- a/doc/todo/better_git-annex-shell_init_workflow.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-Currently, the workflow for initializing a remote repo has to involve
-manually pushing the git-annex branch to the repo, first. This primes
-git-annex-shell to auto-initialize the repo. Only after that first push,
-can git-annex sync be used. If git-annex sync is run earlier, it will try
-to get the remore uuid, fail, and set annex-ignore.
-
-This should be improved.. It ought to be possible to add a new remote and
-have git-annex sync do everything needed.
-
-> [[done]]; the remote needs git-annex-shell 5.20150805 installed, and so
-> does the user, and then `git-annex sync` will automatically handle
-> initialization of the remote. --[[Joey]]
diff --git a/doc/todo/cheaper_global_fsck.mdwn b/doc/todo/cheaper_global_fsck.mdwn
deleted file mode 100644
index 70d1380a2..000000000
--- a/doc/todo/cheaper_global_fsck.mdwn
+++ /dev/null
@@ -1,38 +0,0 @@
-Global fsck updates all location log entries for a repo. This wastes disk
-space.
-
-I realized now that it can be implemented w/o such waste. Probably cheaply
-enough to be the default!
-
-What we need is a new log file, call it fscktimes.log.
-This records the time of the last fsck of each repo.
-
-`git annex fsck --expire` no longer needs to look at the location log at
-all. It can just check the repo's fscktimes.log entry. If the entry is
-recent enough, we know that the repo has fscked recently, and its location
-log is good, and nothing needs to be done. Otherwise, we know that the repo
-has stopped fscking, and we simply expire *all* its location logs.
-
-Note that fscktime.log is only used by fsck; it does not impact git-annex
-generally or make it slower. And, it's very low overhead to update the one
-file. Repos could do a fsck --fast on a daily basis and not grow the
-git-annex branch much. Maybe on an hourly basis even.
-
-(BTW, there is some overlap with the fsck.log file that is currently used to
-hold the timestamp of the last local fsck. May be able to eliminate that
-file too.)
-
-----
-
-It might be worth making the fsck.log record --fast and full fscks
-separately so we know the last of each for each repo. This would let
---expire require periodic full fscks and more frequent fast fscks.
-
-----
-
-Hmm, --expire updates all the location logs when it thinks a repo has gone
-missing. Why not just mark it dead? Again, this would save a lot of space!
-It would complicate recovery if a repo had been offline and came back; it
-would need to mark itself as not dead any longer.
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/clear_file_names_in_special_remotes.mdwn b/doc/todo/clear_file_names_in_special_remotes.mdwn
deleted file mode 100644
index 1b6a9f935..000000000
--- a/doc/todo/clear_file_names_in_special_remotes.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-To properly use amazon AWS S3 for CDN, we need to publish videos to S3. Ideally, we would like to do this via git-annex as the back-end of video.debian.net is being migrated to git-annex by me, atm.
-
-Obviously, we will need clear text names and proper directory structure, not SHA512E file names. This would need to be supported by the S3 special remote.
-
-I talked to TobiasTheViking in the past and he hinted at a reasonably clean way to do this, but that a clean solution would need support from git-annex. I will link him to this page and ask him to supply whatever info is needed.
-
-
-Thanks,
-Richard
-
-> This is not feaisble given git-annex's design. If I wanted to
-> make something completely unlike git-annex, I suppose it could be done,
-> but it's off topic here. [[wontfix|done]] --[[Joey]]
diff --git a/doc/todo/clear_file_names_in_special_remotes/comment_1_630f17c9a7ce9a77d5d5867a6e0c799b._comment b/doc/todo/clear_file_names_in_special_remotes/comment_1_630f17c9a7ce9a77d5d5867a6e0c799b._comment
deleted file mode 100644
index 7ca8e1916..000000000
--- a/doc/todo/clear_file_names_in_special_remotes/comment_1_630f17c9a7ce9a77d5d5867a6e0c799b._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.41"
- subject="comment 1"
- date="2014-03-26T17:26:37Z"
- content="""
-I don't see how this can possibly be done. A single git-annex object can have any number of file names, which can change at any time.
-"""]]
diff --git a/doc/todo/clear_file_names_in_special_remotes/comment_2_823c279683ac3f39c921be3fcbf6bfe2._comment b/doc/todo/clear_file_names_in_special_remotes/comment_2_823c279683ac3f39c921be3fcbf6bfe2._comment
deleted file mode 100644
index b7f5a409e..000000000
--- a/doc/todo/clear_file_names_in_special_remotes/comment_2_823c279683ac3f39c921be3fcbf6bfe2._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
- nickname="Richard"
- subject="comment 2"
- date="2014-03-26T22:32:18Z"
- content="""
-In that case, we would need to export the same file name several times, just like direct mode does.
-
-Could files be tracked via metadata? And yes, fsck would be... interesting...
-"""]]
diff --git a/doc/todo/clear_file_names_in_special_remotes/comment_3_4704e465025b543e47c18d565abd2747._comment b/doc/todo/clear_file_names_in_special_remotes/comment_3_4704e465025b543e47c18d565abd2747._comment
deleted file mode 100644
index a925cb2de..000000000
--- a/doc/todo/clear_file_names_in_special_remotes/comment_3_4704e465025b543e47c18d565abd2747._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.41"
- subject="comment 3"
- date="2014-03-27T17:44:46Z"
- content="""
-Sounds like \"I want a pony to me\".
-"""]]
diff --git a/doc/todo/command_line_interface_for_required_content_setthings.mdwn b/doc/todo/command_line_interface_for_required_content_setthings.mdwn
deleted file mode 100644
index 30889f8bb..000000000
--- a/doc/todo/command_line_interface_for_required_content_setthings.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-Someone in the forum noticed that `git annex wanted`
-handles preferred content settings, but there is no analagous `git annex
-required`.
-
-Probably worth adding that, although required content is not an often
-used feature, and vicfg can already configure it.
-
-(I don't much like the `git annex required` name. Nor the `git annex wanted`
-one when it comes to that. Oh well.)
-
---[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/commit_in_direct_mode.mdwn b/doc/todo/commit_in_direct_mode.mdwn
deleted file mode 100644
index 93dbf40bf..000000000
--- a/doc/todo/commit_in_direct_mode.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-As of right now, the only way to commit changes to direct repositories is `git annex sync [remote]`.
-There is no way to specify what directory to operate on.
-When moving around files on a larger scale, the ability to commit specific subsets of changes would be rather nice.
-
-`git annex commit [path]` or `git annex sync [remote] -- [path]` would probably make sense.
-
-
-Thanks,
-Richard
-
-> I've documented in the git-annex-proxy man page how to use it to do
-> per-file commits. [[done]] --[[Joey]]
diff --git a/doc/todo/commit_in_direct_mode/comment_1_7d9e62010905e0d70cb586534cc09a75._comment b/doc/todo/commit_in_direct_mode/comment_1_7d9e62010905e0d70cb586534cc09a75._comment
deleted file mode 100644
index 55454db7e..000000000
--- a/doc/todo/commit_in_direct_mode/comment_1_7d9e62010905e0d70cb586534cc09a75._comment
+++ /dev/null
@@ -1,67 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-07-03T17:59:39Z"
- content="""
-I am reluctant to make direct mode grow to replicate significant (and
-really quite complex) git commands like commit. Which is why I have not
-added this.
-
-`git annex proxy` brings a lot of regular git commands to
-direct mode.
-
-It's possible to use it to make a commit in direct mode. You only have
-to manually `git annex add` the modified files first, to get them staged
-in the index.
-
- joey@darkstar:~/tmp/a>date > newfile
- joey@darkstar:~/tmp/a>echo modified > foo
- joey@darkstar:~/tmp/a>git annex add newfile foo
- add newfile ok
- add foo ok
- (recording state in git...)
- joey@darkstar:~/tmp/a>git annex proxy -- git commit foo -m foo
- ok
- (recording state in git...)
- [annex/direct/master 739c518] foo
- 1 file changed, 1 insertion(+), 1 deletion(-)
- joey@darkstar:~/tmp/a>git show
- commit 739c518997cc9d0a21e920213394079fce9e7a11
- Author: Joey Hess <joeyh@joeyh.name>
- Date: Fri Jul 3 14:04:19 2015 -0400
-
- foo
-
- diff --git a/foo b/foo
- index 4925a0e..0f22f36 120000
- --- a/foo
- +++ b/foo
- @@ -1 +1 @@
- -.git/annex/objects/fV/Zq/SHA256E-s30--79d01999a1e7d689136859f7462651dbe179b9c779c45d4e0b2815f426628b75/SHA256E-s30--79d01999a1e7d689136859f7462651dbe179b9c779c45d4e0b2815f426628b75
- \ No newline at end of file
- +.git/annex/objects/qw/8m/SHA256E-s9--4487e24377581c1a43c957c7700c8b49920de7b8500c05590cee74996ef73f42/SHA256E-s9--4487e24377581c1a43c957c7700c8b49920de7b8500c05590cee74996ef73f42
- \ No newline at end of file
- joey@darkstar:~/tmp/a>git annex proxy -- git commit -a -m added\ newfile
- ok
- [annex/direct/master 9abe7a4] added newfile
- 1 file changed, 1 insertion(+)
- create mode 120000 newfile
- joey@darkstar:~/tmp/a>git show
- commit 9abe7a4fa083ea0e4529df0054f44f4e30d9e0ae
- Author: Joey Hess <joeyh@joeyh.name>
- Date: Fri Jul 3 14:04:38 2015 -0400
-
- added newfile
-
- diff --git a/newfile b/newfile
- new file mode 120000
- index 0000000..1bb8d0d
- --- /dev/null
- +++ b/newfile
- @@ -0,0 +1 @@
- +.git/annex/objects/23/q9/SHA256E-s30--42fb3eaea7c7932a9056e531f764ca83d117c69c79d4458f9860c6e525f8e498/SHA256E-s30--42fb3eaea7c7932a9056e531f764ca83d117c69c79d4458f9860c6e525f8e498
- \ No newline at end of file
-
-This works because `git annex proxy` sets up a temporary work tree,
-using the content of the index. So you can commit any/all staged files.
-"""]]
diff --git a/doc/todo/credentials-less_access_to_s3.mdwn b/doc/todo/credentials-less_access_to_s3.mdwn
deleted file mode 100644
index dca0a16c9..000000000
--- a/doc/todo/credentials-less_access_to_s3.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-My situation is this: while i know i can *read and write* to [[special_remotes/S3]] fairly easily with the credentials, I cannot read from there from other remotes that do not have those credentials enabled.
-
-This seems to be an assumption deeply rooted in git-annex, specifically in `Remote/S3.hs:390`.
-
-It would be *very* useful to allow remotes to read from S3 transparently. I am aware of the tips mentionned in the comments of [[tips/publishing_your_files_to_the_public/]] that use the `addurl` hack, but this seems not only counter-intuitive, but also seem to add significant per-file overhead in the storage. It also requires running an extra command after every `git annex add` which is a problem if you are running the assistant that will add stuff behind your back.
-
-Besides, you never know if and when the file really is available on s3, so running addurl isn't necessarily accurate.
-
-How hard would it be to fix that in the s3 remote?
-
-Thanks! --[[anarcat]]
-
-> [[done]], see [[tips/public_Amazon_S3_remote/]] --[[Joey]]
diff --git a/doc/todo/credentials-less_access_to_s3/comment_1_eda703c0902d346e063c6d7ae00f6400._comment b/doc/todo/credentials-less_access_to_s3/comment_1_eda703c0902d346e063c6d7ae00f6400._comment
deleted file mode 100644
index e6218a799..000000000
--- a/doc/todo/credentials-less_access_to_s3/comment_1_eda703c0902d346e063c6d7ae00f6400._comment
+++ /dev/null
@@ -1,38 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-06-02T17:24:10Z"
- content="""
-The S3 remote already does it when using the IA as a special case --
-it knows how to map from IA S3 buckets to archive.org urls, and so the
-special remote adds the url automatically. It would be quite easy to
-add that for non-IA; the user would just need to configure the url where
-the files in the bucket can be found.
-
-As noted, this does increase storage needs, since that's written to the
-git-annex branch. Although I'd expect it will compress pretty well when git
-gets around to packing it, since the added data is static base of the
-url, plus the key. Plus a little bit of overhead for hash directories and
-timestamps. Oh, and plus modifying the location tracking info to indicate
-that the file is present in the web special remote. Ok, maybe it's a lot of
-overhead. :)
-
-Could avoid writing this info to the git-annex branch, and just use a
-function to generate urls for keys that are known to be in S3. The
-`whereisKey` interface already exists -- it's how the web special remote
-adds urls to `whereis` display itself.
-
-But I'm not sure what to do about the complication that the S3
-special remote may not be enabled -- and if not, it doesn't get the
-opportunity to register such a function.
-
-Maybe this would need the S3 special remote to be enabled in read-only
-mode? Although, if we're going to do that, it could just handle the
-read-only retrieval itself, and not involve the web special remote at all.
-
-So:
-
- git annex initremote S3 type=s3 ... bucket=foo readonlyurl=http://foo.s3.amazon.com/
- # elsewhere
- git annex enableremote S3 readonly=true
-"""]]
diff --git a/doc/todo/credentials-less_access_to_s3/comment_2_cefe0fbf1c3c6037c677ec6cff0aa6d6._comment b/doc/todo/credentials-less_access_to_s3/comment_2_cefe0fbf1c3c6037c677ec6cff0aa6d6._comment
deleted file mode 100644
index 4455a4fe4..000000000
--- a/doc/todo/credentials-less_access_to_s3/comment_2_cefe0fbf1c3c6037c677ec6cff0aa6d6._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="autodetection?"
- date="2015-06-02T18:11:15Z"
- content="""
-couldn't the remote fallback to readonly mode when no credentials are available?
-
-also, it seems to me that once you have the bucket name, you can automatically guess the URL (http://$bucket.s3.amazon.com or whatever)...
-"""]]
diff --git a/doc/todo/credentials-less_access_to_s3/comment_3_26de94e8e3fefc9b47d1510bfb2dac9b._comment b/doc/todo/credentials-less_access_to_s3/comment_3_26de94e8e3fefc9b47d1510bfb2dac9b._comment
deleted file mode 100644
index 8a9ff4db2..000000000
--- a/doc/todo/credentials-less_access_to_s3/comment_3_26de94e8e3fefc9b47d1510bfb2dac9b._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 3"""
- date="2015-06-05T20:17:38Z"
- content="""
-The remote can indeed fallback when there are no creds.
-
-Also, git-annex can set an ACL on files it uploads, if the remote is
-configured with public=yes, so no manual ACL setting will be needed.
-"""]]
diff --git a/doc/todo/direct_mode_undo.mdwn b/doc/todo/direct_mode_undo.mdwn
deleted file mode 100644
index 82c2e4ab8..000000000
--- a/doc/todo/direct_mode_undo.mdwn
+++ /dev/null
@@ -1,88 +0,0 @@
-A fairly common request is that a repo is using direct mode, and the user
-has made some change, and now wants to undo it. Since direct mode doesn't
-allow using `git revert`, the repo would need to be switched to indirect
-mode first, which can range from annoying to really annoying to impossible
-(on eg FAT).
-
-## general approach
-
-`git annex proxy $gitcmd` could:
-
-1. check out a local clone of the repo
-2. run "git $gitcmd" inside the clone
-3. Merge any changes from the clone back into the direct mode repo
- and update the work tree the same as is done by `git annex merge`.
-4. If a different branch was checked out in the clone, update the repo
- to have that same branch checked out.
-
-This is a general bypass for the direct mode guard. It should work anywhere
-(even on FAT). It avoids problems like `git commit -a` being unsafe in
-direct mode, since running such a command in a local clone, which does not
-use direct mode is always safe.
-
-Beyond handling undo, #4 means that this can be used to check
-out past versions of the repo (eg, `git annex proxy checkout HEAD^^`)
-
-One problem with it is that it can only operate on changes that have been
-committed. If you've just accidentially deleted a file and want to undo
-that, and haven't run `git annex sync` to commit it, you can't revert it.
-
-The need to make a local clone will make it a bit slow, since the whole
-work tree will need to be set up. It might be possible to reuse the clone
-next time (after resetting it to reflect the current HEAD).
-
-Some things like the reflog and local branches don't get cloned, so
-git commands that try to act on those wouldn't work. Maybe it would be
-better to make it use a separate work tree, but the same .git directory?
-Then step #3 would instead update the direct mode work tree to refect
-the new HEAD, and step #4 would not be needed.
-
-> This is done.. But, I think an undo command would also be good
-> to do, as a nicer user interface that can integrate well with a file
-> manager. --[[Joey]]
-
-## git annex undo
-
-I don't want to recapitulate all of the git commands in git-annex for
-direct mode. So I don't want to add `git annex revert` and `git annex
-branch` etc, etc.
-
-So, adding `git annex undo` feels like a step down a slippery slope. But it
-might be justified as providing just enough functionality to make direct
-mode a lot more useful, without trying to recapitulate all the flexability
-of git. Like `git annex merge` and `git annex sync` also do.
-
-Another use case is binding `git annex undo $file` to an action in a file
-manager.
-
-Here's a design for undo:
-
-1. Can be passed one or more files. Which may or may not exist in the work tree.
-2. First, commits the current state of the files as staged in the index,
- or in the working tree. This may involve checksumming modified files.
-3. Then, for each file, looks back through git history, to find the commit
- just before the most recent change that was made to that file.
- Stage the version of the file as it was in that commit.
-4. Updates work tree, and leaves the changes staged
- but not committed. (To allow the user to bundle up multiple undos in a
- single commit).
-6. Does not get or drop content. The content may even be completely
- missing after an undo.
-
-Note that undoing an undo should get back to the original state. This is
-why #2 commits changes first. This way, if a file has a staged change,
-it gets committed, and then that commit is reverted, resulting in another
-commit. Which a later run of undo can in turn revert. If it didn't commit,
-the history about the staged change that was reverted would be lost.
-
-What about undoing changes to a whole directory? Recursively undoing
-the last change to each file would be expensive, and likely confusing.
-Instead, when a directory is passed, it could find the most recent commit
-that touched files in that directory, and undo the changes to those files.
-
-> [[done]] --[[Joey]]
-
-Also, --depth could make undo look for an older commit than the most
-recent one to affect the specified file.
-
-See [[direct_mode]] for documentation about this feature.
diff --git a/doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment b/doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment
deleted file mode 100644
index 35e1b90b0..000000000
--- a/doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="comment 1"
- date="2015-02-15T05:46:01Z"
- content="""
-> This way, if a file has a staged change, it gets committed, and then that commit is reverted, resulting in another commit. Which a later run of undo can in turn revert. If it didn't commit, the history about the staged change that was reverted would be lost.
-
-so far, my experience with this is that unstaged changes get dropped and the change that gets undoed is the last committed change. In other words, if i have:
-
- $ git annex status
- M file
-
-`git annex undo` is going to drop that modification and `git revert HEAD`. but maybe i got confused, in which care some of the documentation i just did in [[direct mode]] needs to be corrected. --[[anarcat]]
-"""]]
diff --git a/doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment b/doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment
deleted file mode 100644
index 1f300b881..000000000
--- a/doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="sigh... nevermind"
- date="2015-02-15T05:52:02Z"
- content="""
-seems like i was wrong. i could have sworn i saw a committed file get unstaged. what i saw was:
-
- $ git annex status
- M file
- $ git annex undo file
- $ git annex status
- ? file
-
-the thing is: the file was *removed* in a previous version, so i thought this was what it reverted to. i'm unsure as to why the file was marked as missing there - i ended up reverting from a backup (from another remote, by hand). after trying to reproduce this, i failed, so there may have been some PEBKAC in action again.
-
-this feature is so useful though, thanks for this. --[[anarcat]]
-"""]]
diff --git a/doc/todo/do_not_commit_with_empty_messages.mdwn b/doc/todo/do_not_commit_with_empty_messages.mdwn
deleted file mode 100644
index 3c6c8415a..000000000
--- a/doc/todo/do_not_commit_with_empty_messages.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-it seems that `git-annex` sometimes does commits with empty commit messages. this makes rebasing git-annex branches much much harder than they need to, because rebase freaks out on those weird commits:
-
-<pre>
-anarcat@marcos:video$ git rebase --continue
-Waiting for Emacs...
-Aborting commit due to empty commit message.
-Could not commit staged changes.
-</pre>
-
-This was trying to fix [[a broken merge|forum/canceling_wrong_repository_merge/]]... --[[anarcat]]
-
-> While I think it's silly to use empty dummy commit messages when there
-> is nothing of value to say about the commit, I guess I can add value
-> by putting in the name of the repository where the commit was made. So,
-> [[done]] --[[Joey]]
diff --git a/doc/todo/do_not_commit_with_empty_messages/comment_1_3cff336e58c26eafade4a37b0c9e0634._comment b/doc/todo/do_not_commit_with_empty_messages/comment_1_3cff336e58c26eafade4a37b0c9e0634._comment
deleted file mode 100644
index c2cd7833f..000000000
--- a/doc/todo/do_not_commit_with_empty_messages/comment_1_3cff336e58c26eafade4a37b0c9e0634._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-02-11T17:15:04Z"
- content="""
-It's completely legal for git commits to have empty commit messages. Why
-would rebase care? Seems like a bug in rebase.
-
-Note that only the git-annex assistant currently uses empty commit
-messages.
-"""]]
diff --git a/doc/todo/do_not_commit_with_empty_messages/comment_2_46a80050beba50360b1c212a9ab5a6b2._comment b/doc/todo/do_not_commit_with_empty_messages/comment_2_46a80050beba50360b1c212a9ab5a6b2._comment
deleted file mode 100644
index 0ce37dc7c..000000000
--- a/doc/todo/do_not_commit_with_empty_messages/comment_2_46a80050beba50360b1c212a9ab5a6b2._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="git bug indeed"
- date="2015-02-11T18:14:34Z"
- content="""
-i agree. this does seems like a bug in git. i tried various ways of coercing git into doing what i need, but in the end just ended up adding comments to those commits.
-
-i thought of reporting this to the mailing list, but it turns out there's already patches floating around to fix a bunch of issues with rebase:
-
-<http://search.gmane.org/?query=rebase+empty+commit+message&group=gmane.comp.version-control.git>
-
-in particular:
-
-<http://article.gmane.org/gmane.comp.version-control.git/255411/>
-
-not sure what those will become.
-"""]]
diff --git a/doc/todo/enable_fsck_--fast_for_S3_remotes.mdwn b/doc/todo/enable_fsck_--fast_for_S3_remotes.mdwn
deleted file mode 100644
index 77392b36d..000000000
--- a/doc/todo/enable_fsck_--fast_for_S3_remotes.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-At the moment, ``git annex fsck --fast -f S3remote`` fails as
-
-[[!format sh """
-> git annex fsck --fast -f S3remote
-(checking cloud...) [2015-04-24 21:39:35 BST] String to sign: "HEAD\n\n\nFri, 24 Apr 2015 20:39:35 GMT\n/BUCKET/GPGHMACSHA1--6e7e880f80de44ddd845c6241198622b9102eaa1"
-[2015-04-24 21:39:35 BST] Host: "BUCKET.s3-ap-southeast-2.amazonaws.com"
-[2015-04-24 21:39:35 BST] Path: "/GPGHMACSHA1--6e7e880f80de44ddd845c6241198622b9102eaa1"
-[2015-04-24 21:39:35 BST] Query string: ""
-[2015-04-24 21:39:36 BST] Response status: Status {statusCode = 200, statusMessage = "OK"}
-[2015-04-24 21:39:36 BST] Response header 'x-amz-id-2': 'D9wtD8voZZgijJRc6i8i0QasAo85REdMMf4GpRaER5+g6sDaUYtCKi42RCdYU0kBxrx4d4dM4xM='
-[2015-04-24 21:39:36 BST] Response header 'x-amz-request-id': 'DDF95C327078E584'
-[2015-04-24 21:39:36 BST] Response header 'Date': 'Fri, 24 Apr 2015 20:39:37 GMT'
-[2015-04-24 21:39:36 BST] Response header 'Last-Modified': 'Sun, 02 Nov 2014 05:42:48 GMT'
-[2015-04-24 21:39:36 BST] Response header 'ETag': '"3bd1b766a68a305ba0495af36b353a07"'
-[2015-04-24 21:39:36 BST] Response header 'Accept-Ranges': 'bytes'
-[2015-04-24 21:39:36 BST] Response header 'Content-Type': ''
-[2015-04-24 21:39:36 BST] Response header 'Content-Length': '775647'
-[2015-04-24 21:39:36 BST] Response header 'Server': 'AmazonS3'
-[2015-04-24 21:39:36 BST] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
-
- failed to download file from remote
-
-failed
-"""]]
-
-
-while ``git annex fsck -f S3remote`` works fine. But, to check for the presence of a file (which is my understanding of what ``--fast`` is for here), it shouldn't be necessary to download the file.
-
-> [[fixed|done]]; it was not supposed to fail at all in this case, and
-> won't anymore. --[[Joey]]
diff --git a/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_1_b9c1da34a1d55333f864f2b7f9f4e4c7._comment b/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_1_b9c1da34a1d55333f864f2b7f9f4e4c7._comment
deleted file mode 100644
index 83e95b6df..000000000
--- a/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_1_b9c1da34a1d55333f864f2b7f9f4e4c7._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-04-25T01:28:34Z"
- content="""
-It's HEADing the file, you can see it in the transcript.
-
-Appears the error message could be better though.
-"""]]
diff --git a/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_2_cf86f921db2a9f1f5ffad14616e3279b._comment b/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_2_cf86f921db2a9f1f5ffad14616e3279b._comment
deleted file mode 100644
index 90c39d2ae..000000000
--- a/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_2_cf86f921db2a9f1f5ffad14616e3279b._comment
+++ /dev/null
@@ -1,84 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
- nickname="Walter"
- subject="Output for a full fsck"
- date="2015-04-25T08:07:35Z"
- content="""
-Sorry, I should have provided this output also, which is when I do a non-fast fsck. Below that is the output for a fsck in a file not in the remote. Basically, they both work. The case of a file not present with --fast also works (it gets a 404 response). But fscking a file with --fast that *is* there gets a 200 response for the HEAD, and then decides it didn't get downloaded properly (it shouldn't download it), and reports a fail. It should see the 200 response and report OK.
-
-I guess this should have been a bug report instead of todo.
-
-[[!format sh \"\"\"
-> git annex fsck -f cloud file --debug
-[2015-04-25 08:52:51 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
-[2015-04-25 08:52:51 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
-[2015-04-25 08:52:51 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..7f6b0b58ef362edd43fc89d8ef641e18cfebcb4a\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 08:52:51 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..19ca78351e854273ccb2b6a83fbaf7e2ed9b32da\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 08:52:51 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
-[2015-04-25 08:52:51 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"file\"]
-[2015-04-25 08:52:51 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"]
-[2015-04-25 08:52:51 BST] read: git [\"--version\"]
-fsck file [2015-04-25 08:52:51 BST] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
-(checking cloud...) [2015-04-25 08:52:51 BST] String to sign: \"HEAD\n\n\nSat, 25 Apr 2015 07:52:51 GMT\n/BUCKET/GPGHMACSHA1--6e7e880f80de44ddd845c6241198622b9102eaa1\"
-[2015-04-25 08:52:51 BST] Host: \"BUCKET.s3-ap-southeast-2.amazonaws.com\"
-[2015-04-25 08:52:51 BST] Path: \"/GPGHMACSHA1--6e7e880f80de44ddd845c6241198622b9102eaa1\"
-[2015-04-25 08:52:51 BST] Query string: \"\"
-[2015-04-25 08:52:52 BST] Response status: Status {statusCode = 200, statusMessage = \"OK\"}
-[2015-04-25 08:52:52 BST] Response header 'x-amz-id-2': 'mLGNeVBzsS7BusAEsDpIyECSpmErjO0HLA/G04svlIgIwsD+K8FpquTvtuA/UoIJK5FrJV0geCE='
-[2015-04-25 08:52:52 BST] Response header 'x-amz-request-id': '2E977E4D5EC072F6'
-[2015-04-25 08:52:52 BST] Response header 'Date': 'Sat, 25 Apr 2015 07:52:53 GMT'
-[2015-04-25 08:52:52 BST] Response header 'Last-Modified': 'Sun, 02 Nov 2014 05:42:48 GMT'
-[2015-04-25 08:52:52 BST] Response header 'ETag': '\"3bd1b766a68a305ba0495af36b353a07\"'
-[2015-04-25 08:52:52 BST] Response header 'Accept-Ranges': 'bytes'
-[2015-04-25 08:52:52 BST] Response header 'Content-Type': ''
-[2015-04-25 08:52:52 BST] Response header 'Content-Length': '775647'
-[2015-04-25 08:52:52 BST] Response header 'Server': 'AmazonS3'
-[2015-04-25 08:52:52 BST] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
-
-[2015-04-25 08:52:52 BST] String to sign: \"GET\n\n\nSat, 25 Apr 2015 07:52:52 GMT\n/BUCKET/GPGHMACSHA1--6e7e880f80de44ddd845c6241198622b9102eaa1\"
-[2015-04-25 08:52:52 BST] Host: \"BUCKET.s3-ap-southeast-2.amazonaws.com\"
-[2015-04-25 08:52:52 BST] Path: \"/GPGHMACSHA1--6e7e880f80de44ddd845c6241198622b9102eaa1\"
-[2015-04-25 08:52:52 BST] Query string: \"\"
-[2015-04-25 08:52:53 BST] Response status: Status {statusCode = 200, statusMessage = \"OK\"}
-[2015-04-25 08:52:53 BST] Response header 'x-amz-id-2': 'QufZ3GyBdogXO8nVnqmJGU5mKZ7+I4DnU95aBUhy04f4158CGAIlp8vHrnGAMDVgLnLuM2TA70A='
-[2015-04-25 08:52:53 BST] Response header 'x-amz-request-id': 'A4EBAB4DD9E11352'
-[2015-04-25 08:52:53 BST] Response header 'Date': 'Sat, 25 Apr 2015 07:52:54 GMT'
-[2015-04-25 08:52:53 BST] Response header 'Last-Modified': 'Sun, 02 Nov 2014 05:42:48 GMT'
-[2015-04-25 08:52:53 BST] Response header 'ETag': '\"3bd1b766a68a305ba0495af36b353a07\"'
-[2015-04-25 08:52:53 BST] Response header 'Accept-Ranges': 'bytes'
-[2015-04-25 08:52:53 BST] Response header 'Content-Type': ''
-[2015-04-25 08:52:53 BST] Response header 'Content-Length': '775647'
-[2015-04-25 08:52:53 BST] Response header 'Server': 'AmazonS3'
-[2015-04-25 08:52:53 BST] Response metadata: S3: request ID=A4EBAB4DD9E11352, x-amz-id-2=QufZ3GyBdogXO8nVnqmJGU5mKZ7+I4DnU95aBUhy04f4158CGAIlp8vHrnGAMDVgLnLuM2TA70A=
-74% 189.4KB/s 1s[2015-04-25 08:52:56 BST] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--batch\",\"--passphrase-fd\",\"15\",\"--decrypt\"]
-(checksum...)
-ok
-\"\"\"]]
-
-
-In contrast, here is the output for a file that isn't in the remote
-[[!format sh \"\"\"
-> git annex fsck -f cloud notpresent --debug
-git annex fsck -f cloud notpresent --debug --numcopies 1
-[2015-04-25 09:00:34 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
-[2015-04-25 09:00:34 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
-[2015-04-25 09:00:34 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..071d29cd21384f0ca129c76442c95c705b4ddc7b\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 09:00:34 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..7f6b0b58ef362edd43fc89d8ef641e18cfebcb4a\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 09:00:34 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
-[2015-04-25 09:00:34 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"notpresent\"]
-fsck notpresent [2015-04-25 09:00:34 BST] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
-(checking cloud...) [2015-04-25 09:00:35 BST] String to sign: \"HEAD\n\n\nSat, 25 Apr 2015 08:00:35 GMT\n/BUCKET/GPGHMACSHA1--e46ce4a11bc47622fb40affac818d6128bcd94bd\"
-[2015-04-25 09:00:35 BST] Host: \"BUCKET.s3-ap-southeast-2.amazonaws.com\"
-[2015-04-25 09:00:35 BST] Path: \"/GPGHMACSHA1--e46ce4a11bc47622fb40affac818d6128bcd94bd\"
-[2015-04-25 09:00:35 BST] Query string: \"\"
-[2015-04-25 09:00:35 BST] Response status: Status {statusCode = 404, statusMessage = \"Not Found\"}
-[2015-04-25 09:00:35 BST] Response header 'x-amz-request-id': 'AFA9934844CD547C'
-[2015-04-25 09:00:35 BST] Response header 'x-amz-id-2': 'sDLFvcFj1pBh4Dhar/nxGGneN2ZP9XXPlI7GHyzuO1XiyW94b52pypel/1uSeFouWl8dXo4xOjc='
-[2015-04-25 09:00:35 BST] Response header 'Content-Type': 'application/xml'
-[2015-04-25 09:00:35 BST] Response header 'Transfer-Encoding': 'chunked'
-[2015-04-25 09:00:35 BST] Response header 'Date': 'Sat, 25 Apr 2015 08:00:34 GMT'
-[2015-04-25 09:00:35 BST] Response header 'Server': 'AmazonS3'
-[2015-04-25 09:00:35 BST] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
-ok
-\"\"\"]]
-"""]]
diff --git a/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_3_b7402508dfc7bbbd09382692aa740c39._comment b/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_3_b7402508dfc7bbbd09382692aa740c39._comment
deleted file mode 100644
index daa24f0cc..000000000
--- a/doc/todo/enable_fsck_--fast_for_S3_remotes/comment_3_b7402508dfc7bbbd09382692aa740c39._comment
+++ /dev/null
@@ -1,88 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
- nickname="Walter"
- subject="comment 3"
- date="2015-04-25T08:36:25Z"
- content="""
-I also obtain the expected result if a file is thought to be present, but isn't.
-
-[[!format sh \"\"\"
-> git annex setpresentkey `git annex lookupkey notpresent` be992080-b1db-11e1-8f79-1b10bb4092ef 1
-setpresentkey SHA256E-s37--2f9b7d77d43f49b59fb00148bc1b3d31a887ba717c988be55b9377d403a91f53 ok
-
-> git annex fsck --debug -f cloud --fast notpresent
-[2015-04-25 09:24:25 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
-[2015-04-25 09:24:25 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
-[2015-04-25 09:24:25 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..0547dfd2d61ff9a24a08ff97cf4984bebbd4f0f1\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 09:24:25 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..b43028d651236ce59a3e47240bead91cdbfc37ea\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 09:24:25 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
-[2015-04-25 09:24:25 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"notpresent\"]
-fsck notpresent [2015-04-25 09:24:25 BST] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
-(checking cloud...) [2015-04-25 09:24:25 BST] String to sign: \"HEAD\n\n\nSat, 25 Apr 2015 08:24:25 GMT\n/BUCKET/GPGHMACSHA1--e46ce4a11bc47622fb40affac818d6128bcd94bd\"
-[2015-04-25 09:24:25 BST] Host: \"BUCKET.s3-ap-southeast-2.amazonaws.com\"
-[2015-04-25 09:24:25 BST] Path: \"/GPGHMACSHA1--e46ce4a11bc47622fb40affac818d6128bcd94bd\"
-[2015-04-25 09:24:25 BST] Query string: \"\"
-[2015-04-25 09:24:25 BST] Response status: Status {statusCode = 404, statusMessage = \"Not Found\"}
-[2015-04-25 09:24:25 BST] Response header 'x-amz-request-id': 'D562150974717AB1'
-[2015-04-25 09:24:25 BST] Response header 'x-amz-id-2': 'Geq6BKC3Sg1rUuhgOHE7fOa5fq+L5ecShidW0ktI/ri3zNXKudhK5O5qT2qmUraJP6BCzDFuj1Q='
-[2015-04-25 09:24:25 BST] Response header 'Content-Type': 'application/xml'
-[2015-04-25 09:24:25 BST] Response header 'Transfer-Encoding': 'chunked'
-[2015-04-25 09:24:25 BST] Response header 'Date': 'Sat, 25 Apr 2015 08:24:24 GMT'
-[2015-04-25 09:24:25 BST] Response header 'Server': 'AmazonS3'
-[2015-04-25 09:24:25 BST] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
-(fixing location log)
- ** Based on the location log, notpresent
- ** was expected to be present, but its content is missing.
-failed
-\"\"\"]]
-
-
-That leaves only one case: when the file isn't thought to be in cloud, but is. For completeness
-
-[[!format sh \"\"\"
-> git annex copy --to cloud notpresent
-copy notpresent (checking cloud...) (to cloud...)
-ok
-(recording state in git...)
-> git annex setpresentkey `git annex lookupkey notpresent` be992080-b1db-11e1-8f79-1b10bb4092ef 0
-setpresentkey SHA256E-s37--2f9b7d77d43f49b59fb00148bc1b3d31a887ba717c988be55b9377d403a91f53 ok
-
-> git annex fsck --debug -f cloud --fast notpresent
-[2015-04-25 09:26:33 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"]
-[2015-04-25 09:26:33 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
-[2015-04-25 09:26:33 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..dca379d2631cd39bd205ccb7d6c192faea7c05c5\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 09:26:33 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..b43028d651236ce59a3e47240bead91cdbfc37ea\",\"-n1\",\"--pretty=%H\"]
-[2015-04-25 09:26:33 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"]
-[2015-04-25 09:26:33 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"notpresent\"]
-fsck notpresent [2015-04-25 09:26:33 BST] chat: gpg [\"--batch\",\"--no-tty\",\"--use-agent\",\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"]
-(checking cloud...) [2015-04-25 09:26:33 BST] String to sign: \"HEAD\n\n\nSat, 25 Apr 2015 08:26:33 GMT\n/BUCKET/GPGHMACSHA1--e46ce4a11bc47622fb40affac818d6128bcd94bd\"
-[2015-04-25 09:26:33 BST] Host: \"BUCKET.s3-ap-southeast-2.amazonaws.com\"
-[2015-04-25 09:26:33 BST] Path: \"/GPGHMACSHA1--e46ce4a11bc47622fb40affac818d6128bcd94bd\"
-[2015-04-25 09:26:33 BST] Query string: \"\"
-[2015-04-25 09:26:34 BST] Response status: Status {statusCode = 200, statusMessage = \"OK\"}
-[2015-04-25 09:26:34 BST] Response header 'x-amz-id-2': '4Ti/62fBMzjW0woyrX5C++tQUw4uV97bbowjSiCkUNI6X2bAt+JCKbRYvZf/Is1QSY6SI2Aqgv4='
-[2015-04-25 09:26:34 BST] Response header 'x-amz-request-id': '9311809D4C8485FD'
-[2015-04-25 09:26:34 BST] Response header 'Date': 'Sat, 25 Apr 2015 08:26:35 GMT'
-[2015-04-25 09:26:34 BST] Response header 'Last-Modified': 'Sat, 25 Apr 2015 08:26:22 GMT'
-[2015-04-25 09:26:34 BST] Response header 'ETag': '\"c5c3c0f720110210e73c7bf962d76390\"'
-[2015-04-25 09:26:34 BST] Response header 'Accept-Ranges': 'bytes'
-[2015-04-25 09:26:34 BST] Response header 'Content-Type': 'binary/octet-stream'
-[2015-04-25 09:26:34 BST] Response header 'Content-Length': '99'
-[2015-04-25 09:26:34 BST] Response header 'Server': 'AmazonS3'
-[2015-04-25 09:26:34 BST] Response metadata: S3: request ID=<none>, x-amz-id-2=<none>
-
- failed to download file from remote
-(fixing location log) failed
-[2015-04-25 09:26:34 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
-[2015-04-25 09:26:34 BST] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"]
-[2015-04-25 09:26:34 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
-(recording state in git...)
-[2015-04-25 09:26:34 BST] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"]
-[2015-04-25 09:26:34 BST] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"83cec04d148757f98565eacda236d6e9dbd48678\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
-[2015-04-25 09:26:34 BST] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"31d4a714f6977197029faf23b099ea32a298be59\"]
-git-annex: fsck: 1 failed
-\"\"\"]]
-
-This correctly determines that the file is present, and updates the location log. But I don't understand why the message ``failed to download file from remote`` is used (which is also used when a file is present, and thought to be present). For a fast fsck it shouldn't be trying to download the file. Also, I don't think this is specific to S3, I expect any remote will have the same behaviour.
-
-"""]]
diff --git a/doc/todo/extensible_addurl.mdwn b/doc/todo/extensible_addurl.mdwn
deleted file mode 100644
index 44b19fef0..000000000
--- a/doc/todo/extensible_addurl.mdwn
+++ /dev/null
@@ -1,88 +0,0 @@
-`git annex addurl` supports regular urls, as well as detecting videos that
-quvi can download. We'd like to extend this to support extensible uri
-handling.
-
-Use cases range from torrent download support, to pulling data
-from scientific data repositories that use their own APIs.
-
-The basic idea is to have external special remotes (or perhaps built-in
-ones in some cases), which addurl can use to download an object, referred
-to by some uri-like thing. The uri starts with "$downloader:" to indicate
-that it's not a regular url and so is not handled by the web special
-remote.
-
- git annex addurl torrent:$foo
- git annex addurl CERN:$bar
-
-Problem: This requires mapping from the name of the downloader, which is
-probably the same as the git-annex-remote-$downloader program implementing
-the special remote protocol (but not always), to the UUID of a remote.
-That's assuming we want location tracking to be able to know that a file is
-both available from CERN and from a torrent, for example.
-
-Solution: Add a new method to remotes:
-
- claimUrl :: Maybe (URLString -> Annex Bool)
-
-Remotes that implement this method (including special remotes) will
-be queried when such an uri is added, to see which claims it.
-
-Once the remote is known, addurl --file will record that the Key is present
-on that remote, and record the uri in the url log.
-
-----
-
-What about using addurl to add a new file? In this mode, the Key is not yet
-known. addurl currently handles this by generating a dummy Key for the url
-(hitting the url to get its size), and running a Transfer using the dummy
-key that downloads from the web. Once the download is done, the dummy Key
-is upgraded to the final Key.
-
-Something similar could be done for other remotes, but the url log for the
-dummy key would need to have the url added to it, for the remote to know
-what to download, and then that could be removed after the download. Which
-causes ugly churn in git, and would leave a mess if interrupted.
-
-One option is to add another new method to remotes:
-
- downloadUrl :: Maybe (URLString -> Annex FilePath)
-
-Or, the url log could have support added for recording temporary key
-urls in memory. (done)
-
-Another problem is that the size of the Key isn't known. addurl
-could always operate in relaxed mode, where it generates a size-less Key.
-Or, yet another method could be added: (done)
-
- sizeUrl :: URLString -> Annex (Maybe Integer)
-
-----
-
-Retrieval of the Key works more or less as usual. The only
-difference being that remotes that support this interface can look
-at the url log to find the one with the right "$downloader:" prefix,
-and so know where to download from. (Much as the web special remote already
-does.)
-
-Prerequisite: Expand the external special remote interface to support
-accessing the url log. (done)
-
-----
-
-It would also be nice to be able to easily configure a regexp that normal
-urls, if they match, are made to use a particular downloader. So, for
-torrents, this would make matching urls have torrent: prefixed to them.
-
- git config annex.downloader.torrent.regexp '(^magnet:|\.torrent$)'
-
-It might also be useful to allow bypassing the complexity of the external
-special remote interface, and let a downloader be specified simply by:
-
- git config annex.downloader.torrent.command 'aria2c %url $file'
-
-This could be implemented in either the web special remote or even in an
-external special remote.
-
-Some other discussion at <https://github.com/datalad/datalad/issues/10>
-
-> [[done]]! --[[Joey]]
diff --git a/doc/todo/extensible_addurl/comment_1_5dca2eb8ee9e8676d372cd4bc6934975._comment b/doc/todo/extensible_addurl/comment_1_5dca2eb8ee9e8676d372cd4bc6934975._comment
deleted file mode 100644
index 857df4254..000000000
--- a/doc/todo/extensible_addurl/comment_1_5dca2eb8ee9e8676d372cd4bc6934975._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
- nickname="Yaroslav"
- subject="allow multiple urls"
- date="2014-12-04T21:59:25Z"
- content="""
-echoing https://github.com/datalad/datalad/issues/9 \"parallel download of a file from multiple URLs (and special remotes?)\"
-might be worth adding e.g.
-
-git config annex.downloader.torrent.allowmultiple True
-
-and then using downloader which could fetch from multiple originating URLs simultaneously. In respect to aria2 (which seems to not support ATM specification of the output filename) see
-https://github.com/tatsuhiro-t/aria2/issues/190
-"""]]
diff --git a/doc/todo/extensible_addurl/comment_2_0e27f12c998a3ac4f0d4c3d4c9898d26._comment b/doc/todo/extensible_addurl/comment_2_0e27f12c998a3ac4f0d4c3d4c9898d26._comment
deleted file mode 100644
index 191cc3ff7..000000000
--- a/doc/todo/extensible_addurl/comment_2_0e27f12c998a3ac4f0d4c3d4c9898d26._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2014-12-05T17:45:57Z"
- content="""
-I think this issue of multiple files in a torrent is another place that
-using an external special remote (or maybe one built into git-annex)
-is better than just specifying a download command. A special remote for
-torrents could use a temp directory that accumulates all the files in the
-torrent, and then pluck out specific files as git-annex requests them.
-
-When git-annex exits, the special remote could clean up any unused files.
-"""]]
diff --git a/doc/todo/fast_migrate.mdwn b/doc/todo/fast_migrate.mdwn
deleted file mode 100644
index 1571d880a..000000000
--- a/doc/todo/fast_migrate.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-Moved this comment to todo list --[[Joey]]
-
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnfM7ZF0Q5U9k1LljyDXH37cuXU5Gx6gtM"
- nickname="A"
- subject="fast migrate"
- date="2014-07-05T08:21:20Z"
- content="""
-dear Joey and everybody else,
- some time ago I used \"git annex migrate\" to bring all my repositories up-to-date; after that I found (to my dismay) that some keys are SHA256, some others are SHA256E, so my data is not really deduplicated ; now, it would possible to migrate from SHAnnnE to SHAnnn (and vice versa) very fast... but currently AFAICS git-annex recomputes the whole checksum, and this (on my USB2.0 old disks) takes forever; may somebody please implement a fast migration?
-"""]]
-
-> Certianly doable, for $hashE to $hash. Probably about an hour's work.
-> --[[Joey]]
-
->> [[done]] --[[Joey]]
diff --git a/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn b/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn
deleted file mode 100644
index 3743886a9..000000000
--- a/doc/todo/fcntl_locks_break_with_threaded_concurrency.mdwn
+++ /dev/null
@@ -1,29 +0,0 @@
-When using git-annex get -J2, one thread can clear another thread's
-transfer lock.
-
-This happens because fcntl locking is used, and it is not thread-safe.
-<https://github.com/haskell/unix/issues/44>
-
-> * If a process closes any file descriptor referring to a
-> file, then all of the process's locks on that file are
-> released, regardless of the file descriptor(s) on which the
-> locks were obtained.
-
-One thread starts a transfer and locks it; the second thread starts a
-transfer of a different file, and in order to check annex.diskreserve,
-checks to see which other transfers are currently running. In doing this
-check, it closes a fd attached to the first thread's lock, which causes the
-lock to be dropped.
-
-This only affects -J mode.
-
-To fix it, probably need to use STM to keep a list of transfers all threads
-in the current process are doing. Then the lock checking code can avoid
-re-opening locks for transfers in the STM list.
-
-A more generic approach is to use Annex.LockFile for everything,
-and make it check its lock pool via STM for other threads holding a lock.
-(Currently, the pool is only used for shared locks.)
---[[Joey]]
-
-> [[fixed|done]] via LockPools. --[[Joey]]
diff --git a/doc/todo/get_--incomplete.mdwn b/doc/todo/get_--incomplete.mdwn
deleted file mode 100644
index 783108beb..000000000
--- a/doc/todo/get_--incomplete.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-Use case: Resuming downloads that are incomplete (files in .git/annex/tmp),
-without needing to remember the original get command(s) that started the
-download.
-
-`git annex get --incomplete` could do this. (With or without --from to
-specify which remote to get from.) --[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex-standalone_Debian_package.mdwn b/doc/todo/git-annex-standalone_Debian_package.mdwn
deleted file mode 100644
index e45a72843..000000000
--- a/doc/todo/git-annex-standalone_Debian_package.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-As proposed with a sketch in https://github.com/joeyh/git-annex/pull/39, for DataLad we would need to get recent annex on older Debian/Ubuntu releases to get our testing farm and perspective users equipped with bleeding edge annex
-
-> merged [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_1_ef36b0265127611ffeea3a5ed8c29515._comment b/doc/todo/git-annex-standalone_Debian_package/comment_1_ef36b0265127611ffeea3a5ed8c29515._comment
deleted file mode 100644
index ad3f8b9e5..000000000
--- a/doc/todo/git-annex-standalone_Debian_package/comment_1_ef36b0265127611ffeea3a5ed8c29515._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-04-11T13:52:28Z"
- content="""
-I think this will work. I don't see a way to do it other than as a patch
-to debian/ though.. Unless perhaps you could pass flags to stuff to make
-a different directory be used. If you could do that, it could be included
-in git-annex's master.
-
-The package needs to depend on git (any version) so that the user can run
-"git annex".
-
-The rest of the depends are not necessary though. The standalone tarball
-includes its own wget, rsync, gpg, curl, and ssh, so git-annex will be able
-to use those.
-
-If removing eg, the depends on wget though, you will want to add a
-recommends on ca-certificates..
-"""]]
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_2_456413718e9faf3561a11000ee611611._comment b/doc/todo/git-annex-standalone_Debian_package/comment_2_456413718e9faf3561a11000ee611611._comment
deleted file mode 100644
index 50a2bf516..000000000
--- a/doc/todo/git-annex-standalone_Debian_package/comment_2_456413718e9faf3561a11000ee611611._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
- nickname="Yaroslav"
- subject="now available"
- date="2015-04-12T13:49:04Z"
- content="""
-from stock NeuroDebian repository across all debian/ubuntu releases. Packaging is within debian-standalone branch of http://github.com/yarikoptic/git-annex
-
-So far -- built manually (well -- debian/build-standalone) on my laptop. Later will be automated on the buildbot.
-"""]]
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_3_22539df11d1a514987b9c257fd8b1998._comment b/doc/todo/git-annex-standalone_Debian_package/comment_3_22539df11d1a514987b9c257fd8b1998._comment
deleted file mode 100644
index 7f0d1d51a..000000000
--- a/doc/todo/git-annex-standalone_Debian_package/comment_3_22539df11d1a514987b9c257fd8b1998._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
- nickname="Yaroslav"
- subject="missed the comment"
- date="2015-04-12T13:55:50Z"
- content="""
-blind me managed to miss your comment, for which I am thankful. A branch sounded like the best way to go so I don't need to mess with patching BUT now thinking about it, I might just indeed move it into a new debian/patch/series-standalone which would be the quilt series to use to patch things for building standalone. Then it could be shipped in the main repo and applied only when necessary. Sounds good?
-"""]]
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_4_0aecbfdc9048df2131d99ad316f5d6f7._comment b/doc/todo/git-annex-standalone_Debian_package/comment_4_0aecbfdc9048df2131d99ad316f5d6f7._comment
deleted file mode 100644
index 0f2393fc1..000000000
--- a/doc/todo/git-annex-standalone_Debian_package/comment_4_0aecbfdc9048df2131d99ad316f5d6f7._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 4"""
- date="2015-04-14T19:14:16Z"
- content="""
-The quilt series sounds reasonable if there's tooling to support building
-that way.
-"""]]
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_5_b0730c577937f57547fabdd1ec57c01c._comment b/doc/todo/git-annex-standalone_Debian_package/comment_5_b0730c577937f57547fabdd1ec57c01c._comment
deleted file mode 100644
index 3d19477c9..000000000
--- a/doc/todo/git-annex-standalone_Debian_package/comment_5_b0730c577937f57547fabdd1ec57c01c._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="comment 5"
- date="2015-06-08T19:27:02Z"
- content="""
-is there a plan to distribute those packages officially somewhere? as mentionned in [[todo/git-annex_in_debian_sid/]], the official debian packages are seriously lagging behind...
-"""]]
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_6_18bc628db6b9ec8942552fdf587e7d4f._comment b/doc/todo/git-annex-standalone_Debian_package/comment_6_18bc628db6b9ec8942552fdf587e7d4f._comment
deleted file mode 100644
index ab0ff4ec4..000000000
--- a/doc/todo/git-annex-standalone_Debian_package/comment_6_18bc628db6b9ec8942552fdf587e7d4f._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="comment 6"
- date="2015-06-09T13:51:10Z"
- content="""
-nevermind, i found [the neurodebian archive](http://neuro.debian.net/pkgs/git-annex-standalone.html) and i think it's what i was looking for - although it does pull in way more stuff than just git-annex, which is unfortunate.
-
-i have documented this in the [[install]] page, i hope that's alright.
-"""]]
diff --git a/doc/todo/git-annex-standalone_Debian_package/comment_7_f8cce1be3153f2b2e069800cb60c4fd3._comment b/doc/todo/git-annex-standalone_Debian_package/comment_7_f8cce1be3153f2b2e069800cb60c4fd3._comment
deleted file mode 100644
index 0b7fa25cc..000000000
--- a/doc/todo/git-annex-standalone_Debian_package/comment_7_f8cce1be3153f2b2e069800cb60c4fd3._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="frederik@ffbea6a549cb3f460d110386c0f634c1ddc6a68a"
- nickname="frederik"
- subject="comment 7"
- date="2015-06-10T12:43:45Z"
- content="""
-Longshot, but would it be an option for [Yaroslav](https://alioth.debian.org/users/yoh/) to take over git-annex maintenance in Debian, given he's involved in creating this version for NeuroDebian?
-"""]]
diff --git a/doc/todo/git-annex_in_debian_sid.mdwn b/doc/todo/git-annex_in_debian_sid.mdwn
deleted file mode 100644
index 99befd98a..000000000
--- a/doc/todo/git-annex_in_debian_sid.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-git-annex in debian sid is still at version 5.20141125: [https://tracker.debian.org/pkg/git-annex](https://tracker.debian.org/pkg/git-annex)
-
-Any chance that it gets updated soon?
-
-> Let's track this in the Debian bts, it can't be fixed here. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/git-annex_in_debian_sid/comment_1_6225fd6237f77ab753429c72d60a9a9b._comment b/doc/todo/git-annex_in_debian_sid/comment_1_6225fd6237f77ab753429c72d60a9a9b._comment
deleted file mode 100644
index 78952c679..000000000
--- a/doc/todo/git-annex_in_debian_sid/comment_1_6225fd6237f77ab753429c72d60a9a9b._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-06-09T16:50:04Z"
- content="""
-I don't know what the holdup is. <http://bugs.debian.org/777577>
-"""]]
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support.mdwn b/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
deleted file mode 100644
index e20cdc928..000000000
--- a/doc/todo/git-annex_info___34__du__34___remote_support.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-so i know about the various discussions around a `du` that follows git-annex symlinks (e.g. [[forum/__34__du__34___equivalent_on_an_annex__63__/]] or [[forum/gadu_-_git-annex_disk_usage/]]. this is not about that, or at least not directly. :)
-
-i believe there's a distinct use-case for a simpler `du` subcommand that will calculate the disk space used locally (in case of the default `--in here`) but could also use the tracking log to determine the space usage in *other* locations. this would be especially useful on remotes that we don't have shell access to, s3 comes to mind. i thought that `git annex info` could output that, but it seems it doesn't:
-
-<pre>
-$ git annex info . --in s3 --exclude='video/original/*'
-directory: .
-local annex keys: 0
-local annex size: 0 bytes
-annexed files in working tree: 0
-size of annexed files in working tree: 0 bytes
-numcopies stats:
-repositories containing these files:
-$ git annex info --in s3 --exclude='video/original/*'
-repository mode: indirect
-trusted repositories: 0
-semitrusted repositories: 6
- 00000000-0000-0000-0000-000000000002 -- bittorrent
- 2d61a8de-a24e-44e3-9aa0-54f033fec1e9 -- host-mp20120507-1.mp.isuma.tv
- 9401d7b3-44d2-48ab-a9f1-c77fac469a1a -- s3
- c510ddad-24cd-4353-b5f4-03581f6f9dca -- cs.isuma.tv [here]
- d2a7d4ff-1dbf-4bfa-bb97-ae593626daf6 -- sneakernet
- e747d5c8-ea47-480f-8c5d-2986ce65ed89 -- isuma.tv
-untrusted repositories: 2
- 00000000-0000-0000-0000-000000000001 -- web
- 36d2cb94-e0a2-446a-87c9-02f73135b302 -- anarcat@desktop008:~/src/isuma/isuma-files
-transfers in progress: none
-available local disk space: 67.66 gigabytes (+1 megabyte reserved)
-local annex keys: 0
-local annex size: 0 bytes
-annexed files in working tree: 0
-size of annexed files in working tree: 0 bytes
-bloom filter size: 16 mebibytes (0% full)
-backend usage:
-</pre>
-
-just to be clear here, the problem isn't as much providing `du-like output`, which `git annex info $path` does pretty well. the problem is that it doesn't work on remote servers, at least that is what i observed above.
-
-i still think it would be nice to have a `du` command, just because it's a command "WTF" situation users seem to get stuck into.. but this issue is only about having this work on remote repositories. thanks! -- [[anarcat]]
-
-> Fixed via time machine. [[done]] --[[Joey]]
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support/comment_1_9d3ac51bdf3bb749bc40a1bb05edbc76._comment b/doc/todo/git-annex_info___34__du__34___remote_support/comment_1_9d3ac51bdf3bb749bc40a1bb05edbc76._comment
deleted file mode 100644
index 59607928e..000000000
--- a/doc/todo/git-annex_info___34__du__34___remote_support/comment_1_9d3ac51bdf3bb749bc40a1bb05edbc76._comment
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-07-02T19:58:10Z"
- content="""
-Actually, this was added in version 5.20150420, when info is run
-with a directory parameter.
-
- joey@darkstar:~/lib/sound/misc>git annex info .
- directory: .
- local annex keys: 2
- local annex size: 10.5 megabytes
- annexed files in working tree: 21
- size of annexed files in working tree: 288.98 megabytes
- numcopies stats:
- numcopies +3: 19
- numcopies +4: 2
- repositories containing these files: 11
- 288.98 MB: 0c443de8-e644-11df-acbf-f7cd7ca6210d -- oldgnu
- 288.98 MB: 1b5ecc94-abb3-45f7-8f4c-5bc65f78d518 -- toshiba passport 1tb [passport]
- 288.98 MB: 6fa26a5f-cb05-4ef0-951b-bc59266ee4e4 -- archive-10 [archive]
- 288.98 MB: 7570b02e-15e9-11e0-adf0-9f3f94cb2eaa -- archive-4 sata drive
- 288.98 MB: 8da3593e-63d2-11e1-a026-43b95a8b93d2 -- archive-7 sata drive
- 288.98 MB: b0bb7176-98e6-457d-b68e-41bfd49be147 -- joey@gnu:~/lib/sound [gnu]
- 288.98 MB: b238695e-e617-11df-9d8b-c350f0825fb0 -- turtle internal [turtle]
- 288.98 MB: ca9c5d52-f03a-11df-ac14-6b772ffe59f9 -- archive-5 sata drive
- 288.98 MB: f1c0ce8d-d848-4d21-988c-dd78eed172e8 -- archive-8 sata drive
- 10.5 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar [here]
-
-"""]]
diff --git a/doc/todo/git-annex_info___34__du__34___remote_support/comment_2_1547eb348bf30e5a06686aee082062f4._comment b/doc/todo/git-annex_info___34__du__34___remote_support/comment_2_1547eb348bf30e5a06686aee082062f4._comment
deleted file mode 100644
index d7e59b6a0..000000000
--- a/doc/todo/git-annex_info___34__du__34___remote_support/comment_2_1547eb348bf30e5a06686aee082062f4._comment
+++ /dev/null
@@ -1,45 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2015-07-02T20:04:19Z"
- content="""
-Note that using `--in remote` also limits the display to files that
-are present in the specified remote, much as --exclude limits the display.
-
- joey@darkstar:~/lib/sound/podcasts/Agile_in_3_Minutes>git annex info . --in archive-10
- directory: .
- local annex keys: 13
- local annex size: 27.88 megabytes
- annexed files in working tree: 13
- size of annexed files in working tree: 27.88 megabytes
- numcopies stats:
- numcopies +1: 9
- numcopies +2: 4
- repositories containing these files: 5
- 27.88 MB: 00000000-0000-0000-0000-000000000001 -- web
- 27.88 MB: 1b5ecc94-abb3-45f7-8f4c-5bc65f78d518 -- toshiba passport 1tb [passport]
- 27.88 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar [here]
- 27.88 MB: 6fa26a5f-cb05-4ef0-951b-bc59266ee4e4 -- archive-10 [archive]
- 8.3 MB: b0bb7176-98e6-457d-b68e-41bfd49be147 -- joey@gnu:~/lib/sound [gnu]
- joey@darkstar:~/lib/sound/podcasts/Agile_in_3_Minutes>git annex info .
- directory: .
- local annex keys: 16
- local annex size: 34.32 megabytes
- annexed files in working tree: 16
- size of annexed files in working tree: 34.32 megabytes
- numcopies stats:
- numcopies +1: 9
- numcopies +2: 4
- numcopies +0: 3
- repositories containing these files: 5
- 34.32 MB: 00000000-0000-0000-0000-000000000001 -- web
- 34.32 MB: 1b5ecc94-abb3-45f7-8f4c-5bc65f78d518 -- toshiba passport 1tb [passport]
- 34.32 MB: 587b9ccf-4548-4d6f-9765-27faecc4105f -- darkstar [here]
- 27.88 MB: 6fa26a5f-cb05-4ef0-951b-bc59266ee4e4 -- archive-10 [archive]
- 8.3 MB: b0bb7176-98e6-457d-b68e-41bfd49be147 -- joey@gnu:~/lib/sound [gnu]
-
-In the first command above, it is only considering files that are in the archive-10 remote,
-and it shows what size those files are taking up on each listed repository. The second command
-considers all files and we can see that some other repos have files not present in the archive-10 remote.
-
-"""]]
diff --git a/doc/todo/git-annex_metadata_extractor_progress_bar.mdwn b/doc/todo/git-annex_metadata_extractor_progress_bar.mdwn
deleted file mode 100644
index 87fcdae92..000000000
--- a/doc/todo/git-annex_metadata_extractor_progress_bar.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-it can take a significant amount of time for the [[automatic metadata script|tips/automatically_adding_metadata/]] to run on commit. it would be nice to have some progress, otherwise it just looks like the command is hanging.
-
-here it's been processing my photos for more than three hours, and it's probably not even halfway done, according to ps... [[anarcat]]
-
-> Well, I added an echo of each file as it's processed. More complex
-> progress could be done, patches accepted. But I suppose a file list is
-> good enough; it's good enough for git-annex itself. [[done]] --[[Joey]]
diff --git a/doc/todo/git_annex_get___60__file__62___should_verify_file_hash.mdwn b/doc/todo/git_annex_get___60__file__62___should_verify_file_hash.mdwn
deleted file mode 100644
index fd93554ec..000000000
--- a/doc/todo/git_annex_get___60__file__62___should_verify_file_hash.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-### Please describe the problem.
-git annex get fileName- should perform a hash check on the file content before adding to the local repository
-
-
-### What steps will reproduce the problem?
-Two scenarios:
-1) Malicious user and owner of repository being pulled from can edit his/her local .git/annex/objects directory
-to alter the file content. For src code, this could be to insert a bug, insert a backdoor, or for example
-to replace an image file artifact for a website, with a pornographic image.
-The user pulling the file content with "git annex get fileName" might not be aware of the file contents
-until they actually examine the file or perform an fsck or commit locally.
-In the meantime a kiddy porn image could be sitting in their repository or a src code backdoor can get incorporated and deployed etc.
-2) a file could also simply get corrupted during download. An inherent hash check during the 'annex get' would
-point out the problem immediately.
-To reproduce: create repoNum1, and clone it to create repoNum2. manual edit/replace content in repoNum1/.git/annex/objects/...
-then perform a 'git annex get <fileName>' from repoNum2 on the file that has been manipulated
-
-
-### What version of git-annex are you using? On what operating system?
-3.2012112ubuntu2 on running linux mint
-
-
-### Please provide any additional information below.
-
-Aside: Thanks Joey - this is fantastic work you are doing. You have really improved git. The ability to checkout
-an entire tree - but selectively get only the content actually needed is a real killer feature.
-Kudos and again many many thanks
-M.
-
-
-# End of transcript or log.
-"""]]
-
-> [[duplicate|done]] of [[checksum_verification_on_transfer]] --[[Joey]]
diff --git a/doc/todo/git_annex_get___60__file__62___should_verify_file_hash/comment_1_650e01a04104120ef1db4ff16fedc4f1._comment b/doc/todo/git_annex_get___60__file__62___should_verify_file_hash/comment_1_650e01a04104120ef1db4ff16fedc4f1._comment
deleted file mode 100644
index 621e01d6f..000000000
--- a/doc/todo/git_annex_get___60__file__62___should_verify_file_hash/comment_1_650e01a04104120ef1db4ff16fedc4f1._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.87"
- subject="comment 1"
- date="2013-12-15T19:38:48Z"
- content="""
-If you don't trust a remote repository, then you should either
-
-a) Not use that repository at all, because its malicious owner could put any evil file he wants in it with an entirely correct hash.
-
-b) Make it a gcrypt remote so all content stored on it is encrypted. Decrypting it will include validating that you get out what you originally put in.
-
-So these scenarios are not good arguments for validating every file after it's downloaded.
-
-If it were possible to do a rolling checksum as part of the download, rather than needing to pull the entire file back off disk and checksum it, I'd do so. But it's generally not; for example when git-annex is downloading a file using rsync it may resume part way through a previous interrupted download, and rsync is storing the file to disk, not streaming it to git-annex.
-"""]]
diff --git a/doc/todo/git_annex_grep.mdwn b/doc/todo/git_annex_grep.mdwn
deleted file mode 100644
index 8cff25e9b..000000000
--- a/doc/todo/git_annex_grep.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-### Please describe the problem.
-
-inability to quickly grep locally present files
-
-### What steps will reproduce the problem?
-
-run "git annex grep"
-
-> i don't understand this request. just running `grep` will grep all the locally present files: sure there will be warnings, but you can use `2>/dev/null` to silence those. as for the suggested solution in comment, that greps for the filenames. please clarify the feature request here or this is [[invalid|done]]. --[[anarcat]]
-
->> The reason `git grep` exists is partly speed (git objects can
->> sometimes be read more efficiently than traversing the fileststem),
->> and partly the ability to grep a whole tree of source code, but
->> avoid grepping build artifacts, etc. The former reason doesn't apply
->> with git-annex. The latter reason applies somewhat, but it's much less
->> common to want to grep large binary files than it is to want to grep a
->> source tree. `git annex find` can be fed to `grep` when one wants to do
->> that. So I don't see a compelling case to add this to git-annex.
->> --[[Joey]]
diff --git a/doc/todo/git_annex_grep/comment_1_890b3ecb679b941f9c0075ed360b203e._comment b/doc/todo/git_annex_grep/comment_1_890b3ecb679b941f9c0075ed360b203e._comment
deleted file mode 100644
index 30351c2ed..000000000
--- a/doc/todo/git_annex_grep/comment_1_890b3ecb679b941f9c0075ed360b203e._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="CandyAngel"
- subject="comment 1"
- date="2015-06-04T12:31:32Z"
- content="""
-You can do this:
-
- git annex find --in here | grep
-"""]]
diff --git a/doc/todo/inject_on_import.mdwn b/doc/todo/inject_on_import.mdwn
deleted file mode 100644
index d33267987..000000000
--- a/doc/todo/inject_on_import.mdwn
+++ /dev/null
@@ -1,63 +0,0 @@
-Would it be possible to add an `--inject` option to import?
-
-Say, for example, I have an annex on computer A which has a subset of files and a directory of files which are potentional duplicates of files in the annex.
-
-I would like to do something like this:
-
- mkdir ~/annex/import
- cd ~/annex/import
- git annex import --deduplicate --inject ~/directory/of/files
-
-This would do the same as `--deduplicate`, except if the file is not present in the annex, it would be injected. For example:
-
-Annex knows about A and B, A is present but B is not.
-$DIR contains A, B and C.
-
-A would be deleted from $DIR due to `--deduplicate`.
-B would be injected into the repo (making it present) due to `--inject`, then deleted from $DIR.
-C would be added to the annex, resulting in this
-
- $ ls ~/annex/import
- C
-
-> You seem to have described exactly what --deduplicate already does.
-> For example:
-
-<pre>
-# mkdir x
-# cd x
-# l
-# git init
-Initialized empty Git repository in /home/joey/tmp/x/.git/
-# git annex init
-init ok
-(Recording state in git...)
-# echo hello > foo
-# git annex add foo
-add foo ok
-(Recording state in git...)
-# mkdir ../src
-# echo hello > ../src/bar
-# echo new > ../src/baz
-# git annex import --deduplicate ../src
-import src/bar (duplicate) ok
-import src/baz ok
-(Recording state in git...)
-# ls
-foo@ src/
-# ls ../src/
-# ls src
-baz@
-</pre>
-
-> And, if you look at the documentation for --deduplicate,
-> this is what it says:
-
-<pre>
- To only import files whose content has not been seen
- before by git-annex, use the --deduplicate option.
- Duplicate files will be deleted from the import loca‐
- tion.
-</pre>
-
-> So, [[done]] I suppose... --[[Joey]]
diff --git a/doc/todo/inject_on_import/comment_1_314de82da94f47539e754e9bec950d7b._comment b/doc/todo/inject_on_import/comment_1_314de82da94f47539e754e9bec950d7b._comment
deleted file mode 100644
index 693f967cf..000000000
--- a/doc/todo/inject_on_import/comment_1_314de82da94f47539e754e9bec950d7b._comment
+++ /dev/null
@@ -1,67 +0,0 @@
-[[!comment format=mdwn
- username="Xyem"
- subject="comment 1"
- date="2015-03-20T10:51:59Z"
- content="""
-I just tested this and git-annex does not act according to its documentation.
-
- ## git init annex
- Initialized empty Git repository in ./annex/.git/
- ## mkdir to_import
- mkdir: created directory ‘to_import’
- ## echo A > annex/A
- ## echo B > annex/B
- ## echo A > to_import/A
- ## echo B > to_import/B
- ## echo C > to_import/C
- ## cd annex/
- ## git annex init
- init ok
- (Recording state in git...)
- ## git annex add .
- add A ok
- add B ok
- (Recording state in git...)
- ## git commit -m \"commit\"
- [master (root-commit) f2628f0] commit
- 2 files changed, 2 insertions(+)
- create mode 120000 A
- create mode 120000 B
-
- ## git annex drop B --force
- drop B ok
- (Recording state in git...)
-
-Annex knows about A and B, A is present but B is not.
-
-to_import contains A, B and C.
-
- ## git annex import --deduplicate ../to_import/
- import to_import/C ok
- import to_import/A (duplicate) ok
- import to_import/B ok
- (Recording state in git...)
- ## ls -R
- .:
- A B to_import
-
- ./to_import:
- B C
-
-According to the docs, it would look like this:
-
- ## ls -R
- .:
- A B to_import
-
- ./to_import:
- C
-
-and B would be a dangling symlink (due to the content having been seen by the annex before, but not present).
-
-So '--import --deduplicate' actually imports/deduplicates files whose content /is not present/ in the annex, rather than 'has not been seen before'.
-
-Fortunately, this error is on the side of caution and data is never lost, but you do end up with duplicates (2 symlinks pointing to the same content).
-
-The behaviour is acceptable (to me at least, better duplicate symlinks than lost data), but the documentation is misleading and should probably refer to content presence rather than having ever been present.
-"""]]
diff --git a/doc/todo/inject_on_import/comment_2_205ecbc7401f99fc83719acbf5da174e._comment b/doc/todo/inject_on_import/comment_2_205ecbc7401f99fc83719acbf5da174e._comment
deleted file mode 100644
index acd661feb..000000000
--- a/doc/todo/inject_on_import/comment_2_205ecbc7401f99fc83719acbf5da174e._comment
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2015-03-26T15:28:45Z"
- content="""
-Well, you've found an edge case here.
-
-It behaves as documented as long as the file being imported is located in some
-repository know to git-annex. The file content does not have to be present in
-the local repository for it to behave as documented.
-
-In your case, the file being imported has a symlink in the git repo, but
-git-annex knows about 0 annexed copies of the file, so it's treated as
-if it's a new file and not a duplicate.
-
-Since import is working at the key level, there's not a good way to look up
-that there are some symlinks in the git repo even though the content is
-gone. And even if there was, I think I'd be uncomfortable with it deleting
-the file as "duplicate" when its content is not available in any known
-repository. The only behavior improvement might be to import the content
-but not make a redundant symlink in this case.
-
-I think it's best to change the documentation. I've added a new
-paragraph that more exactly and clearly explains what duplicate files
-are for the purposes of importing.
-"""]]
diff --git a/doc/todo/merge_in_ram___40__disk__41____63__.mdwn b/doc/todo/merge_in_ram___40__disk__41____63__.mdwn
deleted file mode 100644
index 42090f673..000000000
--- a/doc/todo/merge_in_ram___40__disk__41____63__.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-git-annex is great. But for my repos the merge and recording state operations take forever.
-
-(merging fotos_enc_pg/synced/git-annex into git-annex...)
-
-Since git-annex is another branch (than master) and git usually needs a worktree for merging I assume that git-annex branch is temporarily checked out somewhere. Would it be possible to move this operation to RAM? Or a RAM-Disk?
-
-> No, it is not checked out. All operations are done with the most
-> effective available git plumbing. [[done]] --[[Joey]]
diff --git a/doc/todo/notifications.mdwn b/doc/todo/notifications.mdwn
deleted file mode 100644
index d332d1029..000000000
--- a/doc/todo/notifications.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-Just started today with git-annex and it looks great replacement for proprietary syncing solutions (well in allot of aspects it's much better than proprietary solutions) but I do believe desktop and email notifications are must have features.
-
-I think these services would be nice to have: growl, libnotify, email, twitter (publicly sharing with a group or repository stored on public server for users to download).
-
-> git-annex has desktop notifications. I think that if you want something
-> beyond that, you should script it. So, [[done]] --[[Joey]]
diff --git a/doc/todo/podcatching_handling_updated_files.mdwn b/doc/todo/podcatching_handling_updated_files.mdwn
deleted file mode 100644
index 2d9800283..000000000
--- a/doc/todo/podcatching_handling_updated_files.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-Files in feeds can be updated, and if this update includes changing the
-url, `importfeed` will treat this as a new file. This results in `foo.mp3`
-having a `2_foo.mp3` added next to it.
-
-This seems to happen especially commonly with feeds using FeedBurner.
-Saw several with same size, different checksum and url.
-
-To detect this, `importfeed` could store the item's guid in the metadata
-of the key. Where it currently builds a `Map URLString Key` of all
-known items, it could instead build a `Map (Either URlString GUID) Key`.
-
-This would at least prevent the duplication, when the feed has guids.
-
-> [[done]] --[[Joey]]
-
-It would be even nicer if the old file could be updated with the new
-content. But, since files can be moved around, deleted, tagged, etc,
-that only seems practical at all if the file is still in the directory
-where `importfeed` created it.
diff --git a/doc/todo/remote_groups_support_for_sync.mdwn b/doc/todo/remote_groups_support_for_sync.mdwn
deleted file mode 100644
index b49016427..000000000
--- a/doc/todo/remote_groups_support_for_sync.mdwn
+++ /dev/null
@@ -1,5 +0,0 @@
-`git remote update $group` looks at the $group.away git config and fetches
-from the listed remotes. It would be useful if `git annex sync $group` did the same.
---[[Joey]]
-
-[[done]]
diff --git a/doc/todo/replace_dataenc_with_sandi.mdwn b/doc/todo/replace_dataenc_with_sandi.mdwn
deleted file mode 100644
index 9ce29663b..000000000
--- a/doc/todo/replace_dataenc_with_sandi.mdwn
+++ /dev/null
@@ -1,6 +0,0 @@
-<https://github.com/joeyh/git-annex/pull/15>
-
-sandi is available in jessie, but not wheezy, so this is pending
-EOL of wheezy support. --[[Joey]]
-
-> [[fixed|done]] --[[Joey]]
diff --git a/doc/todo/resuming_encrypted_uploads.mdwn b/doc/todo/resuming_encrypted_uploads.mdwn
deleted file mode 100644
index 44a58a141..000000000
--- a/doc/todo/resuming_encrypted_uploads.mdwn
+++ /dev/null
@@ -1,29 +0,0 @@
-Resuming interrupted uploads to encrypted special remotes is not currently
-possible, because gpg does not produce consistent output. Special remotes
-that could support resuming include rsync and glacier.
-
-Without consistent output, git-annex would need to locally cache the encrypted
-file, and reuse that cache when resuming an upload. This would make
-encrypted uploads more expensive in terms of both file IO and disk space
-used.
-
-[It would be possible to write to the cache at the same time the special
-remote is being fed data, and if the special remote upload fails, continue
-writing the rest of the file. That would avoid half the overhead, since
-the file would not need to be read from, just written to. (Although OS
-caching may accomplish the same thing.)]
-
-Also, `git annex unused` would need to show temp files for uploads,
-the same as it currently shows temp files for downloads, and users would
-sometimes need to manually dropunused old uploads, that never completed.
-
-The question, then, is whether resuming uploads is useful enough to add
-this overhead and user-visible complexity.
---[[Joey]]
-
-> The new-style chunking code chunks and then encrypts. This means that
-> each individual chunk is a stand-alone file that can be decrypted later,
-> and so resumes of uploads to encrypted, chunked remotes works now.
->
-> I think that's better than the ideas discussed above, so [[done]]
-> --[[Joey]]
diff --git a/doc/todo/resuming_encrypted_uploads/comment_1_1832a6fb78e8ad7c838582f46731ac3b._comment b/doc/todo/resuming_encrypted_uploads/comment_1_1832a6fb78e8ad7c838582f46731ac3b._comment
deleted file mode 100644
index cf35de049..000000000
--- a/doc/todo/resuming_encrypted_uploads/comment_1_1832a6fb78e8ad7c838582f46731ac3b._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://phil.0x539.de/"
- nickname="Philipp Kern"
- subject="comment 1"
- date="2012-12-28T23:23:29Z"
- content="""
-Doesn't the encryption part already write an encrypted version completely to disk before starting to upload? (At least with the rsync remote?) So the disk space and I/O usage is already there. (Except that it's probably a temporary file that's deleted after it was created, so that it's not kept around by the filesystem when certain destructive events strike.)
-"""]]
diff --git a/doc/todo/resuming_encrypted_uploads/comment_2_2ecc8e782f49e90ed1549e9179eb1a1e._comment b/doc/todo/resuming_encrypted_uploads/comment_2_2ecc8e782f49e90ed1549e9179eb1a1e._comment
deleted file mode 100644
index a2bab9244..000000000
--- a/doc/todo/resuming_encrypted_uploads/comment_2_2ecc8e782f49e90ed1549e9179eb1a1e._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
- nickname="Michael"
- subject="comment 2"
- date="2012-12-29T08:00:56Z"
- content="""
-Being able to resume transfers of encrypted files would absolutely be useful! Disk space is cheap, but bandwidth is not.
-"""]]
diff --git a/doc/todo/server-level_daemon__63__.mdwn b/doc/todo/server-level_daemon__63__.mdwn
deleted file mode 100644
index 544624031..000000000
--- a/doc/todo/server-level_daemon__63__.mdwn
+++ /dev/null
@@ -1,203 +0,0 @@
-coming from [[bugs/weird_entry_in_process_list]] - are there plans to make an init.d / systemd .service file for git-annex?
-
-my use case is that i have dedicated machines that will sync a common directory. they will run only one assistant - would patches to make a `git-annex` user, and the associated startup scripts, in the debian package be welcome? --[[anarcat]]
-
-Here's a sample startup script:
-
-<pre>
-#!/bin/sh
-### BEGIN INIT INFO
-# Provides: gitannex
-# Required-Start: $local_fs $network $remote_fs $syslog
-# Required-Stop: $local_fs $network $remote_fs $syslog
-# Default-Start: 2 3 4 5
-# Default-Stop: 0 1 6
-# Short-Description: start the git-annex assistant
-# Description: start the git-annex assistant in the given directory
-### END INIT INFO
-
-# Author: Antoine Beaupré <anarcat@koumbit.org>
-
-# Do NOT "set -e"
-
-# PATH should only include /usr/* if it runs after the mountnfs.sh script
-PATH=/sbin:/usr/sbin:/bin:/usr/bin
-DESC="gitannex"
-NAME=gitannex
-USER=$NAME
-DAEMON=git-annex
-DAEMON_ARGS="assistant"
-PIDFILE=/var/run/$NAME.pid
-SCRIPTNAME=/etc/init.d/$NAME
-ANNEX=auto
-
-# Read configuration variable file if it is present
-[ -r /etc/default/$NAME ] && . /etc/default/$NAME
-
-# Exit if the package is not installed
-[ -x "$DAEMON" ] || exit 0
-
-# Load the VERBOSE setting and other rcS variables
-. /lib/init/vars.sh
-
-# Define LSB log_* functions.
-# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
-# and status_of_proc is working.
-. /lib/lsb/init-functions
-
-if [ "$ANNEX" = "auto" ]; then
- DAEMON_ARGS="$DAEMON_ARGS --autostart"
-else
- cd $ANNEX
- PIDFILE="$ANNEX/.git/annex/daemon.pid"
- EXTRA_OPTS="--chdir $ANNEX"
-fi
-
-#
-# Function that starts the daemon/service
-#
-do_start()
-{
- # Return
- # 0 if daemon has been started
- # 1 if daemon was already running
- # 2 if daemon could not be started
- start-stop-daemon --start --quiet --user $USER --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
- || return 1
- start-stop-daemon --start --quiet --user $USER --chuid $USER $EXTRA_OPTS --pidfile $PIDFILE --exec $DAEMON -- \
- $DAEMON_ARGS \
- || return 2
- # The above code will not work for interpreted scripts, use the next
- # six lines below instead (Ref: #643337, start-stop-daemon(8) )
- #start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \
- # --name $NAME --test > /dev/null \
- # || return 1
- #start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \
- # --name $NAME -- $DAEMON_ARGS \
- # || return 2
-
- # Add code here, if necessary, that waits for the process to be ready
- # to handle requests from services started subsequently which depend
- # on this one. As a last resort, sleep for some time.
-}
-
-#
-# Function that stops the daemon/service
-#
-do_stop()
-{
- # Return
- # 0 if daemon has been stopped
- # 1 if daemon was already stopped
- # 2 if daemon could not be stopped
- # other if a failure occurred
- su $USER -c "$DAEMON $DAEMON_ARGS --stop" && return 0
- # Wait for children to finish too if this is a daemon that forks
- # and if the daemon is only ever run from this initscript.
- # If the above conditions are not satisfied then add some other code
- # that waits for the process to drop all resources that could be
- # needed by services started subsequently. A last resort is to
- # sleep for some time.
- start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --user $USER --exec $DAEMON
- [ "$?" = 2 ] && return 2
- # Many daemons don't delete their pidfiles when they exit.
- rm -f $PIDFILE
- return "$RETVAL"
-}
-
-#
-# Function that sends a SIGHUP to the daemon/service
-#
-do_reload() {
- #
- # If the daemon can reload its configuration without
- # restarting (for example, when it is sent a SIGHUP),
- # then implement that here.
- #
- start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
- return 0
-}
-
-case "$1" in
- start)
- [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
- do_start
- case "$?" in
- 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
- 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
- esac
- ;;
- stop)
- [ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
- do_stop
- case "$?" in
- 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
- 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
- esac
- ;;
- status)
- status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit $?
- ;;
- #reload|force-reload)
- #
- # If do_reload() is not implemented then leave this commented out
- # and leave 'force-reload' as an alias for 'restart'.
- #
- #log_daemon_msg "Reloading $DESC" "$NAME"
- #do_reload
- #log_end_msg $?
- #;;
- restart|force-reload)
- #
- # If the "reload" option is implemented then remove the
- # 'force-reload' alias
- #
- log_daemon_msg "Restarting $DESC" "$NAME"
- do_stop
- case "$?" in
- 0|1)
- do_start
- case "$?" in
- 0) log_end_msg 0 ;;
- 1) log_end_msg 1 ;; # Old process is still running
- *) log_end_msg 1 ;; # Failed to start
- esac
- ;;
- *)
- # Failed to stop
- log_end_msg 1
- ;;
- esac
- ;;
- *)
- #echo "Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}" >&2
- echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
- exit 3
- ;;
-esac
-
-:
-</pre>
-
-Now this is not without problems:
-
- 1. it assumes a gitannex user is created outside of the script
- 2. it assumes a gitannex repository is created outside of the script and specified in the `/etc/default/gitannex` file (or added to the autostart file)
- 3. it is Debian-specific (a proper init script would be POSIX only and/or a `.service` file)
-
-Maybe using [metainit](https://wiki.debian.org/MetaInit) would be a good idea here? --[[anarcat]]
-
-> This strikes me as a bad idea if the system has regular desktop etc
-> users; the assistant can already start itself when they login and
-> a separate user has the same problems the separate mpd user seems to;
-> of separating the user from the files that effcetively belong to them.
->
-> It's fine if you're doing something more specialized, but that seems
-> like an unusual case and not one that git-annex should cater to.
->
-> Anyway, it's about 5 lines to write a systemd service file. I've added
-> `git annex assistant --autostop` that such a service can use if desired.
->
-> Since I don't want to include that in git-annex and be stuck supporting
-> it, and it should be easy for users to add if they need it, I think I'm
-> going to call this [[done]]. --[[Joey]]
diff --git a/doc/todo/server-level_daemon__63__/comment_1_1abea0cbfcc603da779a811731c38b5f._comment b/doc/todo/server-level_daemon__63__/comment_1_1abea0cbfcc603da779a811731c38b5f._comment
deleted file mode 100644
index e6d6e297a..000000000
--- a/doc/todo/server-level_daemon__63__/comment_1_1abea0cbfcc603da779a811731c38b5f._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 1"""
- date="2015-02-25T18:06:57Z"
- content="""
-That strikes me as a bad idea in general. Why a dedicated user? What's wrong
-with starting the assistant from the user account where you want it
-to run on boot? (Using cron @reboot, or systemd, or logind, or surely
-many other methods.)
-"""]]
diff --git a/doc/todo/server-level_daemon__63__/comment_2_4a5ccb0e772352adbf20940c010895a5._comment b/doc/todo/server-level_daemon__63__/comment_2_4a5ccb0e772352adbf20940c010895a5._comment
deleted file mode 100644
index cc6ab9848..000000000
--- a/doc/todo/server-level_daemon__63__/comment_2_4a5ccb0e772352adbf20940c010895a5._comment
+++ /dev/null
@@ -1,9 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="comment 2"
- date="2015-02-26T23:52:52Z"
- content="""
-because this is a server without a generic \"user account\". there are multiple admins with each their own account, and i'd like to have git-annex run as its own account. and yes, probably under systemd, but under wheezy, under init.d.
-
-i would avoid @reboot cron jobs because systemd can't restart it if they fail.
-"""]]
diff --git a/doc/todo/server-level_daemon__63__/comment_3_60c5030a21c28b79f634f0655bc6c05d._comment b/doc/todo/server-level_daemon__63__/comment_3_60c5030a21c28b79f634f0655bc6c05d._comment
deleted file mode 100644
index 974cc0a11..000000000
--- a/doc/todo/server-level_daemon__63__/comment_3_60c5030a21c28b79f634f0655bc6c05d._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- subject="comment 3"
- date="2015-02-26T23:53:32Z"
- content="""
-why would that be a bad idea anyways?
-"""]]
diff --git a/doc/todo/subsecond_timestamping_of_the_--debug_output.mdwn b/doc/todo/subsecond_timestamping_of_the_--debug_output.mdwn
deleted file mode 100644
index 8d963c432..000000000
--- a/doc/todo/subsecond_timestamping_of_the_--debug_output.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-ATM --debug uses timestamps at second precision. Would be nice (to see where time is spent) to have subsecond timing
-
-> [[done]], I was able to get fractional seconds down to 0.000001
-> in the debug output. --[[Joey]]
diff --git a/doc/todo/unused_by_refspec.mdwn b/doc/todo/unused_by_refspec.mdwn
deleted file mode 100644
index ea84599bb..000000000
--- a/doc/todo/unused_by_refspec.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-Currently `git annex unused` assumes that all branches (including remote
-tracking branches) and tags are "used" and finds only objects not used by
-any of those refs.
-
-That's a reasonable default, but in some cases, we don't care about
-specific refs. Perhaps we don't consider remote tracking branches
-important. Or perhaps we only want objects in HEAD to be considered used.
-
-This could be handled by adding an option to specify a refspec when running
-git-annex unused. Only matching refs would be checked. It's probably worth
-making this be both a command-line option --used-refspec, as well as a
-annex.used-refspec config setting.
-
-git's refspec format is not quite right (since it specifies a local side
-and a remote side for push/pull). But, it can be used as a point of
-departure. Let's allow wildcards as it does, and use leading '+' to add a
-ref, and '-' to remove. Let the user specify multiple such expressions,
-separated by ':'.
-
- +refs/heads/*:+HEAD^:+refs/tags/*:-refs/tags/old-tag
-
-This is processed by starting with an empty set of refs, and walking the
-refspec in order.
-
-* Each + is matched against all known refs (from `git show-ref`), and adds
- everything it matches to the set. If the + does not contain a wildcard,
- it is literally added to the set, rather than looking in the known refs.
- This allows "+refs/heads/*" to match all heads, and "+HEAD"
- to match HEAD, or even "+sha" to match a given SHA, or "+HEAD^" to match
- the previous head.
-* Each - is matched against the contents of the set, and removes everything
- it matches, using a lexographic matching with wildcards (not looking at
- the SHAs that the refs point to, so -refs/heads/master does not remove
- +HEAD).
-
-Hmm, unused currently does a separate pass to find files used in the work
-tree. I think it's best to keep that as-is.
-
---[[Joey]]
-
-> [[done]] --[[Joey]]
diff --git a/doc/todo/unused_by_refspec/comment_1_4612b5f485b313d59eb51bb519eb9471._comment b/doc/todo/unused_by_refspec/comment_1_4612b5f485b313d59eb51bb519eb9471._comment
deleted file mode 100644
index 44cc30731..000000000
--- a/doc/todo/unused_by_refspec/comment_1_4612b5f485b313d59eb51bb519eb9471._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
- subject="comment 1"
- date="2015-05-14T16:17:08Z"
- content="""
-since, if I got it right, I will be able to point to any treeish (or collection of those), I should be able to implement any strategy in mind (e.g. for upgrade drop all not referenced in master, or even its HEAD and HEAD^ to allow a quick roll back). So sounds good to me -- thanks joey!
-"""]]
diff --git a/doc/todo/vicfg_comment_gotcha.mdwn b/doc/todo/vicfg_comment_gotcha.mdwn
deleted file mode 100644
index 910af01a4..000000000
--- a/doc/todo/vicfg_comment_gotcha.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-A user might run vicfg and want to reset a line back to the default value
-from the value they have periously set. A natural way to do that is to
-comment out the line (or delete it). However, what that actually does is
-vicfg parses the result and skips over that setting, since it's not
-present, and so no change is saved.
-
-It could try to parse commented out lines and detect deleted lines,
-but that way lies madness. Also, it's not at all clear what the "default"
-should be in response to such an action. The default varies per type of
-configuration, and vicfg does't know about defaults.
-
-> [[fixed|done]]; this was a job for Data.Default! --[[Joey]]
-
-Instead, I think it should detect when a setting provided in the input
-version of the file is not present in the output version, and plop the user
-back into the editor with an error, telling them that cannot be handled,
-and suggesting they instead change the value to the value they now want it
-to have.
-
-> Nah, too complicated.
diff --git a/doc/todo/view_git_annex_log_in_webapp.mdwn b/doc/todo/view_git_annex_log_in_webapp.mdwn
deleted file mode 100644
index 63b2792a8..000000000
--- a/doc/todo/view_git_annex_log_in_webapp.mdwn
+++ /dev/null
@@ -1,7 +0,0 @@
-Just gave git annex a quick try for a few minutes and I must admit it's pretty great.
-
-A must have feature for me is to be able to view git annex log in the web app as "git annex log" doesn't got BIDI support (RTL scripts like Arabic, Farsi, Hebrew).
-Adding Bi-directional text support would be too much to ask from a developer that don't know these languages thus the solution is to use the already the web browser to handle that.
-
-> Closing as it's not clear what the submitter wanted done here. [[done]]
-> --[[Joey]]
diff --git a/doc/todo/view_git_annex_log_in_webapp/comment_1_945054441d93423b2c7b81712b364a3c._comment b/doc/todo/view_git_annex_log_in_webapp/comment_1_945054441d93423b2c7b81712b364a3c._comment
deleted file mode 100644
index 362119bae..000000000
--- a/doc/todo/view_git_annex_log_in_webapp/comment_1_945054441d93423b2c7b81712b364a3c._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmHp5oVW8Z9v_vHs5FRtlYj80TYMQWVTS0"
- nickname="dhead"
- subject="comment 1"
- date="2014-05-30T00:13:27Z"
- content="""
-...the already built in BIDI support the web browser to handle that.
-"""]]
diff --git a/doc/todo/view_git_annex_log_in_webapp/comment_2_0f434dfe80e90951870218bc1b76c374._comment b/doc/todo/view_git_annex_log_in_webapp/comment_2_0f434dfe80e90951870218bc1b76c374._comment
deleted file mode 100644
index f9e14a55f..000000000
--- a/doc/todo/view_git_annex_log_in_webapp/comment_2_0f434dfe80e90951870218bc1b76c374._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.176"
- subject="comment 2"
- date="2014-05-30T00:32:25Z"
- content="""
-I don't understand this request at all
-
-* There are plenty of console emulators with bidi support. If you need bidi support, surely you have already found and are using one of them?
-* `git annex log` does not output much that seems likely to need bidi support. At least no more than any other git-annex command, specifically names of remotes, and names of files.
-* `git annex log` is a low-level tool, almost a debugging tool. Users of the webapp might be interested in which repositories a file has gotten to, but surely not the history of past locations of files.
-"""]]
diff --git a/doc/todo/windows_git-annex_service.mdwn b/doc/todo/windows_git-annex_service.mdwn
deleted file mode 100644
index 5a7e91752..000000000
--- a/doc/todo/windows_git-annex_service.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-## git-annex as service on windows
-
-Use nssm to run git-annex as a service. Will need to include it in the
-git-annex bundle.
-
-Problem: nssm runs git-annex as a service as a LocalService user. (Or some
-similar user.) This leads to permission problems, when the normal user
-tries to write to its directory.
-
-Solution: Make `git-annex mkservice $repo` command (only avilable on
-Windows) that does:
-
-1. git -c core.sharedRepository=true init $repo
-2. cd $repo; git annex init
-4. chmod 777 -R $repo
-5. Add $repo to C:\.config\git-annex\autostart
-6. If git-annex service does not yet exist in nssm, set it up and start it.
-
-**Problem**: With 2 users writing to one repository, files and subdirs
-will end up owned by git-annex or by the desktop user, and the other user
-won't be able to eg, edit a file or remove a file from a directory.
-
-Make git-annex read `C:\.config\git-annex\autostart`
-on Windows, in addition to the one in $HOME. This way, `git annex assistant
---autostart` and `git annex webapp` will use it, no matter which user.
-
-WIP git branch: `winservice`
-
-> I am calling this [[done]], it's not done using a service, but it works.
-> --[[Joey]]
diff --git a/doc/todo/windows_git-annex_service/comment_11_c3af14453e99dae5425deaa26ca7310e._comment b/doc/todo/windows_git-annex_service/comment_11_c3af14453e99dae5425deaa26ca7310e._comment
deleted file mode 100644
index 83e2ba514..000000000
--- a/doc/todo/windows_git-annex_service/comment_11_c3af14453e99dae5425deaa26ca7310e._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm9ocq1Kb0WL-cz-LPpvd2Xm-q8tIQvqXA"
- nickname="Dominik"
- subject="running as service"
- date="2014-05-13T17:40:57Z"
- content="""
-Hey, just tried git-annex on windows. Love the idea, but the windows port still seems to be a work in progress. I thought I'd check in here and see if i could help. Maybe this is a start:
-
-You can setup any executable file as a windows service using Sc.exe included in the Windows Resource Kit.
-https://support.microsoft.com/kb/251192?SmcNavTabIndex=1
-Its pretty easy and straightforward
-
-Another option would be installing the service using nsis, here is one possible plugin that should do the trick: http://nsis.sourceforge.net/NSIS_Simple_Service_Plugin
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_11_e2dda1037cc85f03613f2774c139ad56._comment b/doc/todo/windows_git-annex_service/comment_11_e2dda1037cc85f03613f2774c139ad56._comment
deleted file mode 100644
index df945b517..000000000
--- a/doc/todo/windows_git-annex_service/comment_11_e2dda1037cc85f03613f2774c139ad56._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 11"
- date="2014-06-16T23:47:36Z"
- content="""
-I am stuck with apparently intractable permissions problems, if the git-annex service doesn't run as the same user who wants to use the git-annex repository.
-
-nssm is supposed to let the user the service runs as be set on the Log on tab, but I cannot get it to accept any user/password there, on my XP test VM. If anyone gets that tab in nssm to work, let me know.
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_12_249a48a241f14f32dab49f381d2de3b3._comment b/doc/todo/windows_git-annex_service/comment_12_249a48a241f14f32dab49f381d2de3b3._comment
deleted file mode 100644
index 9b7e87654..000000000
--- a/doc/todo/windows_git-annex_service/comment_12_249a48a241f14f32dab49f381d2de3b3._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm9ocq1Kb0WL-cz-LPpvd2Xm-q8tIQvqXA"
- nickname="Dominik"
- subject="comment 12"
- date="2014-06-17T00:01:35Z"
- content="""
-To get rid of permission problems, you may find setacl useful. Chmod and chown from msys dont't seem to work correctly with windows 8
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_12_d3d91ddc00bc275455022d86b779b148._comment b/doc/todo/windows_git-annex_service/comment_12_d3d91ddc00bc275455022d86b779b148._comment
deleted file mode 100644
index df4545911..000000000
--- a/doc/todo/windows_git-annex_service/comment_12_d3d91ddc00bc275455022d86b779b148._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 12"
- date="2014-05-15T20:36:09Z"
- content="""
-@Dominik, thanks for the links. Now that the webapp handles prompting for ssh passwords, the console is entirely vestigial and I'd like to get rid of it. The sc commands seems possible to use; there are also haskell libraries for building windows services.
-
-The tricky part is that multiple git-annex assistant processes can be running, if there are multiple local repositories. This seems to be hard to do as a service.
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_13_59fbe4d07cdbeb786bae792f9c709ddd._comment b/doc/todo/windows_git-annex_service/comment_13_59fbe4d07cdbeb786bae792f9c709ddd._comment
deleted file mode 100644
index 3d630ed0c..000000000
--- a/doc/todo/windows_git-annex_service/comment_13_59fbe4d07cdbeb786bae792f9c709ddd._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://johan.kiviniemi.name/"
- nickname="Johan"
- subject="comment 13"
- date="2014-05-16T02:27:51Z"
- content="""
-“The tricky part is that multiple git-annex assistant processes can be running, if there are multiple local repositories.”
-
-This would probably mean a lot of work, but it might be nice if there was just a single git-annex assistant per user which could take care of multiple local repos. The UI would be nicer, too, since the status of and notifications from every repository could be shown in the same place.
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_13_f1d254fe85b0e5cbc7edf9096af4f942._comment b/doc/todo/windows_git-annex_service/comment_13_f1d254fe85b0e5cbc7edf9096af4f942._comment
deleted file mode 100644
index 894eb4b6c..000000000
--- a/doc/todo/windows_git-annex_service/comment_13_f1d254fe85b0e5cbc7edf9096af4f942._comment
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 13"
- date="2014-06-17T16:52:55Z"
- content="""
-I have messed with the windows ACLs some yesterday, but I don't know how or if it's possible to set ACLs on a directory, such that everything created inside it will be writable by two different users. Certainly this is doable on POSIX; if it's doable on Windows, I'll revisit services.
-
-----
-
-
-For now, it seems that a better option may be to not run git-annex as a service, but use various dos-window hiding technologies.
-
-<http://stackoverflow.com/questions/21031171/how-to-run-a-command-on-the-background-on-windows/21031281#21031281>
-
-I have successfully gotten this to work using nircmd. make a git-annex-webapp.bat, containing:
-
-<pre>
-title GitAnnex
-nircmd.exe win hide ititle \"GitAnnex\"
-git annex webapp
-</pre>
-
-This works, although the DOS box flashes onscreen for maybe 1/10th of a second before nircmd hides it. A git-annex-assistant.bat could run git-annex assistant --autostart, and would be suitable to be setup to run on startup.
-
-(It seems that it's possible to write a VBScript or C# program that sets up a hidden WScript.Shell and runs a command in it. That might avoid the window flash. However, it seems hard to get VBScript to run, and I have not investigated C#.)
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_14_79fc0ff98c5bba2ed616e52e5a58e28f._comment b/doc/todo/windows_git-annex_service/comment_14_79fc0ff98c5bba2ed616e52e5a58e28f._comment
deleted file mode 100644
index 9d7fb9ff0..000000000
--- a/doc/todo/windows_git-annex_service/comment_14_79fc0ff98c5bba2ed616e52e5a58e28f._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm9ocq1Kb0WL-cz-LPpvd2Xm-q8tIQvqXA"
- nickname="Dominik"
- subject="multiple git-annex assistant processes"
- date="2014-05-16T23:05:28Z"
- content="""
-shouldn't be a problem though if all processes are spawned from the same service though, right? Or what problems did you have in mind?
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_14_7d5fdac0084c4742967879f5f0f9fccf._comment b/doc/todo/windows_git-annex_service/comment_14_7d5fdac0084c4742967879f5f0f9fccf._comment
deleted file mode 100644
index 5aba4e8e4..000000000
--- a/doc/todo/windows_git-annex_service/comment_14_7d5fdac0084c4742967879f5f0f9fccf._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 14"
- date="2014-06-17T16:56:32Z"
- content="""
-Note that nircmd is not free software; but can be distributed free of charge, provided all the files in the zip are included and unmodified. Sucks, but it's windows..
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_15_8f10491f8c0a151284e6d81a83eab212._comment b/doc/todo/windows_git-annex_service/comment_15_8f10491f8c0a151284e6d81a83eab212._comment
deleted file mode 100644
index c7247ce45..000000000
--- a/doc/todo/windows_git-annex_service/comment_15_8f10491f8c0a151284e6d81a83eab212._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 15"
- date="2014-06-17T17:10:28Z"
- content="""
-<http://www.ntwind.com/software/hstart.html> is another option.
-
-How to run VB script:
-
-<http://stackoverflow.com/questions/289498/running-batch-file-in-background-when-windows-boots-up>
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_15_fcd34607116183cc1a764fb307eabe0a._comment b/doc/todo/windows_git-annex_service/comment_15_fcd34607116183cc1a764fb307eabe0a._comment
deleted file mode 100644
index 57505d1d9..000000000
--- a/doc/todo/windows_git-annex_service/comment_15_fcd34607116183cc1a764fb307eabe0a._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 15"
- date="2014-06-04T20:49:26Z"
- content="""
-`sc` can only be used by the administrator. That is problimatic.
-
-Also, in order for sc to be used, the program has to have support for it. It cannot be any arbitrary program. win32-service adds such support. However, I have not been able to get programs using win32-service to build: <https://github.com/mikesteele81/Win32-services/issues/3>
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_16_51800fd83cd979b021eabdd4c44cfd61._comment b/doc/todo/windows_git-annex_service/comment_16_51800fd83cd979b021eabdd4c44cfd61._comment
deleted file mode 100644
index 7efe7b338..000000000
--- a/doc/todo/windows_git-annex_service/comment_16_51800fd83cd979b021eabdd4c44cfd61._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 16"
- date="2014-06-17T17:18:34Z"
- content="""
-Using wscript to run a file containing this will start the webapp w/o any console flicker:
-
-<pre>
-Set objshell=CreateObject(\"Wscript.Shell\")
-objShell.Run(\"git-annex webapp\"), 0, False
-</pre>
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_16_6a6424f23772e57f1adb1807ca8b93fa._comment b/doc/todo/windows_git-annex_service/comment_16_6a6424f23772e57f1adb1807ca8b93fa._comment
deleted file mode 100644
index 53b705d05..000000000
--- a/doc/todo/windows_git-annex_service/comment_16_6a6424f23772e57f1adb1807ca8b93fa._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="service not needed"
- date="2014-06-04T21:16:06Z"
- content="""
-Seems that all I need to do is pass -optl-mwindows when building git-annex; this will produce a binary that does not open a console window when started from the start menu, but still runs in the background. So it will work as the webapp.
-
-**However**, it can't be used at the command line. So, I think I should make a git-annex-webapp shim that's built that way and starts the real webapp.
-
-But, some work needs to be done, because when run this way, git-annex can't write to stdout or stderr, which it tries to do, and so crashes on startup.
-
-Also, when git-annex is built that way and tries to run git.. windows helpfully opens a command.exe to display any output git might have. So we get lots of flickering command.exe windows.
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_17_62a1a33c2aaf4b0b8a0149ec526907d7._comment b/doc/todo/windows_git-annex_service/comment_17_62a1a33c2aaf4b0b8a0149ec526907d7._comment
deleted file mode 100644
index 520e50154..000000000
--- a/doc/todo/windows_git-annex_service/comment_17_62a1a33c2aaf4b0b8a0149ec526907d7._comment
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm9ocq1Kb0WL-cz-LPpvd2Xm-q8tIQvqXA"
- nickname="Dominik"
- subject="comment 17"
- date="2014-06-05T16:42:02Z"
- content="""
-Actually you can create a service from any program or batch file using srvany.exe from the windows resource kit: http://support.microsoft.com/kb/137890. An alternative would be the Non-Sucking Service Manager http://nssm.cc/
-Also nsis has some plugins for creating services, but i havent tried any of them: http://nsis.sourceforge.net/How_do_I_start/stop/create/remove/check_a_service
-
-Upsides:
-1) You don't have to touch your code or change anything in the compilation just to create the service
-2) git-annex will still work fine from the console
-Downside: You'd have to include an extra binary or plugin in your installer for creating the service
-
-But I'm pretty sure that none of the commandline calls would pop up in a new window that way, but if you need the verbose mode, you could still start the webapp from console instead as service and everything will show as expected
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_18_3a408492107ca6f120b631ce8c41faef._comment b/doc/todo/windows_git-annex_service/comment_18_3a408492107ca6f120b631ce8c41faef._comment
deleted file mode 100644
index 494e3f43a..000000000
--- a/doc/todo/windows_git-annex_service/comment_18_3a408492107ca6f120b631ce8c41faef._comment
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="nssm notes"
- date="2014-06-10T18:16:00Z"
- content="""
-* Have to install and run nssm as an administrator. (It may be possible to get it to run as a non-administrator user if the admin sets it up. I haven't succeeded.)
-* `nssm install git-annex`
-* Set path to git-annex, and set Arguments to: `assistant --autostart`
-* In Exit tab, change Restart to \"No action\"
-* In Process tab, uncheck \"Console window\"
-* Repositories to start up have to be listed in `C:\Documents and Settings\LocalService\.config\git-annex\autostart`
- (rather than the normal user home directory)
-
-After all that it works! Even opening git-annex webapp from the menu avoids the console window (it appears briefly but then goes away).
-
-Most of this setup could be boiled down to a command line invocation, which git-annex could do at install time. However, it would still need to be run by the admin. Luckily the git-annex installation process already only works as admin (and I guess I could close the bug about that if it gets a legitimate reason to need admin..)
-
-Some changes in git-annex would improve this.
-
-* Maybe have a way to specify the user that git-annex is running on behalf of, and look in that user's home directory, rather than LocalService. (Other parts of the webapp UI, like adding a new repository, also use LocalService as the home directory, which is confusing).
-* Starting the webapp for the first time to create a repository still opens a console window, so find a workaround for this.
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_19_c6cbc8fe9218f90c661cd1026658c939._comment b/doc/todo/windows_git-annex_service/comment_19_c6cbc8fe9218f90c661cd1026658c939._comment
deleted file mode 100644
index ec3cf7b09..000000000
--- a/doc/todo/windows_git-annex_service/comment_19_c6cbc8fe9218f90c661cd1026658c939._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawm9ocq1Kb0WL-cz-LPpvd2Xm-q8tIQvqXA"
- nickname="Dominik"
- subject="comment 19"
- date="2014-06-10T18:24:22Z"
- content="""
-That sounds great! I'll try it out on windows 8 aswell once i get around to it.
-"""]]
diff --git a/doc/todo/windows_git-annex_service/comment_20_ca245781a37db5546da3f7204adbeebb._comment b/doc/todo/windows_git-annex_service/comment_20_ca245781a37db5546da3f7204adbeebb._comment
deleted file mode 100644
index badb5308a..000000000
--- a/doc/todo/windows_git-annex_service/comment_20_ca245781a37db5546da3f7204adbeebb._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="108.236.230.124"
- subject="comment 20"
- date="2014-06-10T19:11:57Z"
- content="""
-This seems pretty close to a command line to install the service with nssm.
-
-<pre>
-nssm install git-annex 'C:\Program Files\Git\cmd\git-annex.exe' assistant --autostart
-nssm set git-annex AppExit 0 Ignore
-nssm set git-annex AppExit 1 Ignore
-nssm set git-annex AppDirectory C:\
-nssm set git-annex AppNoConsole 1
-nssm start git-annex
-</pre>
-"""]]