diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2017-09-29 12:55:42 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-09-29 12:55:42 -0400 |
| commit | 0dfc1d4e6eb37aadaba47a210539b2438fba97f5 (patch) | |
| tree | e0beee12909c581f06829060a93a72d6686ca730 /doc/todo | |
| parent | bd2a9fb40ef0bbe812e8ea375a5caabd6e628ef2 (diff) | |
remove old closed bugs and todo items to speed up wiki updates and reduce size
Remove closed bugs and todos that were last edited or commented before 2017.
Command line used:
for f in $(grep -l '|done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; done
for f in $(grep -l '\[\[done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; done
Diffstat (limited to 'doc/todo')
182 files changed, 0 insertions, 2740 deletions
diff --git a/doc/todo/--batch_for_add.mdwn b/doc/todo/--batch_for_add.mdwn deleted file mode 100644 index c0450c11f..000000000 --- a/doc/todo/--batch_for_add.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -should be extremely helpful when adding many files one at a time ;) - -[[!meta author=yoh]] - -> Implemented; made it not recurse into directories and output a blank line -> if it doesn't add the file, so there's aways 1 line of output for each -> input. [[done]] --[[Joey]] diff --git a/doc/todo/--batch_for_find.mdwn b/doc/todo/--batch_for_find.mdwn deleted file mode 100644 index 825ca560f..000000000 --- a/doc/todo/--batch_for_find.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -I am using `annex find filename` after running 'annex add` to figure out if file was added to annex or to git. - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/--batch_for_info.mdwn b/doc/todo/--batch_for_info.mdwn deleted file mode 100644 index 8f7fba456..000000000 --- a/doc/todo/--batch_for_info.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -I guess as other commands which take separate files/keys as its argument(s), having --batch for info command would be of benefit - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/--batch_for_whereis.mdwn b/doc/todo/--batch_for_whereis.mdwn deleted file mode 100644 index 11cd3e8f8..000000000 --- a/doc/todo/--batch_for_whereis.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -subject. IMHO yet another useful command to be batched - -> [[done]] --[[Joey]] diff --git a/doc/todo/Compile_error_with_GHC_prerelease.mdwn b/doc/todo/Compile_error_with_GHC_prerelease.mdwn deleted file mode 100644 index 5f024d5dd..000000000 --- a/doc/todo/Compile_error_with_GHC_prerelease.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -For various reasons we cannot use v8.0 (prereleases) yet, -but GHC v7.11.20150407 - -There was a compilation hiccup with polymorphic types. I corrected it in - -https://github.com/ggreif/git-annex/tree/patch-1 - -The commit is - -https://github.com/ggreif/git-annex/commit/a0ddad8d395b5eb61d1e7e6fdcbfa766c05de3d4 - -Cheers, - - Gabor - -> Applied, thanks. [[done]] --[[Joey]] diff --git a/doc/todo/Improve_direct_mode_using_copy_on_write.mdwn b/doc/todo/Improve_direct_mode_using_copy_on_write.mdwn deleted file mode 100644 index 4a57ac5e4..000000000 --- a/doc/todo/Improve_direct_mode_using_copy_on_write.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -Direct mode is great because it removes symlinks. A must-have for directories like `~/Documents`. Unfortunately, it removes the possibility to use `git` commands other than `git-annex`. Also, it doen't preserve history of files. - -I would be great to have a mode where: - -- files are available in plain, not as sylinks -- the repository could still be trusted to hold version of some files from other repositories -- from a user point of view, the history of a file before the checkout would be preserved. - -In feature rich file systems that have copy on write feature, it could be implemented by having the files in both places at the same time: - -- the current version of a file would be in the working copy -- the file in the working copy would be a copy-on-write of the file in the annex repository -- when the file in the working copy changes, `git-annex` notices it and copy the file in the annex repository using copy-on-write semantic - -If the file system do not support copy-on-write, it could be an option (do you want secure direct mode that takes twice the disk space or light direct mode that don't preserve the history of your files?) - -This would make direct more much more robust. - -copy on write is available using `cp --reflink=always`. It correspond to the following code ([coreutils src/copy.c line 224](http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy.c#n224)): - - /* Perform the O(1) btrfs clone operation, if possible. - Upon success, return 0. Otherwise, return -1 and set errno. */ - static inline int - clone_file (int dest_fd, int src_fd) - { - #ifdef __linux__ - # undef BTRFS_IOCTL_MAGIC - # define BTRFS_IOCTL_MAGIC 0x94 - # undef BTRFS_IOC_CLONE - # define BTRFS_IOC_CLONE _IOW (BTRFS_IOCTL_MAGIC, 9, int) - return ioctl (dest_fd, BTRFS_IOC_CLONE, src_fd); - #else - (void) dest_fd; - (void) src_fd; - errno = ENOTSUP; - return -1; - #endif - } - -Looking at the code it would be preferable to exec directly to `cp`, see [copy_range() on LWN](http://lwn.net/Articles/550621/) and this [more recent article about splice() on LWN](http://lwn.net/Articles/567086/) - -Also, `cp --reflink` fall back to copy when copy-on-write is not available while `cp --reflink=always` do not. - -> The new v6 repository mode works this way. [[done]] --[[Joey]] diff --git a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes.mdwn b/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes.mdwn deleted file mode 100644 index b13bceccf..000000000 --- a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -It would be great to have something to call in post-update-annex which would give a list of all new and lost files given in the update. - -This could be `git annex log --all --max-count=1` or somesuch. - -This capability could alternatively be provided with a new post-transfer hook, called for every file. - -> [[done]] --[[Joey]] diff --git a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_1_1b1439d08fd064314e28f94caaa850be._comment b/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_1_1b1439d08fd064314e28f94caaa850be._comment deleted file mode 100644 index c03673f06..000000000 --- a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_1_1b1439d08fd064314e28f94caaa850be._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="baffo32" - subject="Use-case expansion" - date="2016-06-17T23:55:52Z" - content=""" -My use-case is to store the absolute disk offsets for files, to aid recovery in case of accidental loss. - -I'd like to run a script for every key added to the repo in which the script resides. The script calls filefrag to determine the physical location of the key on the disk and adds it as metadata. - -If interested, my pre-commit-annex snippet is: - - # requires recent e2fsprogs - if [ -x /usr/sbin/filefrag ] - then - field=\"$(git config annex.uuid)\"-extents - LC_ALL=C /usr/sbin/filefrag -ev \"$f\" | sed -n \ - -e 's/.*([0-9]* blocks* of \([0-9]*\) bytes).*/!bs \1/p'\ - -e 's/^ *[0-9]*: *\([0-9]*\)\.\. *[0-9]*: *\([0-9]*\)\.\. *[0-9]*: *\([0-9]*\): *.*/\1 \2 \3/p' | - while read value - do - # !bs 4096 means values are in multiples of 4096 bytes (blocksize) - # 0 5287839 5 means 5 blocks starting at block 0 of the file start at block 5287839 of the disk - # extents which are not listed are from sparse files and contain all zeros - equal='+=' addmeta \"$f\" \"$field\" \"$value\" - done - fi - -"""]] diff --git a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_2_18d1c7d8f4f0214c4d89119e9efb9b4a._comment b/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_2_18d1c7d8f4f0214c4d89119e9efb9b4a._comment deleted file mode 100644 index b22b9ed1b..000000000 --- a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_2_18d1c7d8f4f0214c4d89119e9efb9b4a._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-07-17T19:09:41Z" - content=""" -Implelemented `git annex log --all`. It turned out to fit really well -to add the functionality there. - -You can use --max-count, or even --since to limit the log -that's displayed. - -The output streams, so you could just remember the first line you saw when -running it before, and close the pipe when the subsequent run outputs that -line. (Although this method may skip over changes that got merged in from -another repository.) -"""]] diff --git a/doc/todo/Nearline_support.mdwn b/doc/todo/Nearline_support.mdwn deleted file mode 100644 index f21af64cf..000000000 --- a/doc/todo/Nearline_support.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -This has been described as Google's [[special_remotes/glacier]]. - -* [Announcement](http://googlecloudplatform.blogspot.in/2015/03/introducing-Google-Cloud-Storage-Nearline-near-online-data-at-an-offline-price.html) -* <https://cloud.google.com/storage/docs/nearline-storage> - -> This is a dup of -> [[bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage]], -> which has more useful info, so [[closing|done]]. -> -> However, that about using its S3 compatability API. There's an external -> special remote just for nearline, which may be a better choice due to -> using the native API, and already works. --[[Joey]] diff --git a/doc/todo/Nearline_support/comment_1_185e4cce55ac26756e74c668d0fe2a8c._comment b/doc/todo/Nearline_support/comment_1_185e4cce55ac26756e74c668d0fe2a8c._comment deleted file mode 100644 index ec6bfc54d..000000000 --- a/doc/todo/Nearline_support/comment_1_185e4cce55ac26756e74c668d0fe2a8c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-03-16T17:47:18Z" - content=""" -I have not read anything about this yet, but there is another post -which seems to indicate that the S3 interface could be used with git-annex, -if it were possible to set storageclass=NEARLINE, which it is currently -not due to a limitation with the aws library git-annex is using. -""]] diff --git a/doc/todo/Nearline_support/comment_3_2d320d2c636c36c3006d91469b8c5ca9._comment b/doc/todo/Nearline_support/comment_3_2d320d2c636c36c3006d91469b8c5ca9._comment deleted file mode 100644 index fe095f5ca..000000000 --- a/doc/todo/Nearline_support/comment_3_2d320d2c636c36c3006d91469b8c5ca9._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c" - nickname="Justin" - subject="comment 3" - date="2015-03-18T04:43:22Z" - content=""" -To be clear, I'm not sure that using storageclass=NEARLINE would work. Perhaps we need to omit storageclass entirely, or perhaps the storageclass=STANDARD isn't actually the problem. I'm just guessing at this point. -"""]] diff --git a/doc/todo/Nearline_support/comment_4_ae360f07fb87d63f09725b43b85cb210._comment b/doc/todo/Nearline_support/comment_4_ae360f07fb87d63f09725b43b85cb210._comment deleted file mode 100644 index d01955fce..000000000 --- a/doc/todo/Nearline_support/comment_4_ae360f07fb87d63f09725b43b85cb210._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-03-26T16:04:01Z" - content=""" -This is waiting on support in the AWS library git-annex uses. - -<https://github.com/aristidb/aws/issues/155> -"""]] diff --git a/doc/todo/Nearline_support/comment_4_cb30f90ad3f2c22b3067527298dec849._comment b/doc/todo/Nearline_support/comment_4_cb30f90ad3f2c22b3067527298dec849._comment deleted file mode 100644 index 2c0c50bd1..000000000 --- a/doc/todo/Nearline_support/comment_4_cb30f90ad3f2c22b3067527298dec849._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmSedKB9mVUCUcxmY5snWkfFVvTSnmiNKo" - nickname="Jeffery" - subject="comment 4" - date="2015-03-18T12:14:55Z" - content=""" -According to the documentation for nearline: \"You can access data in a Nearline bucket in the same way you access data in a Standard bucket.\" and that you just use \"Nearline\" as the storage class... so this might work? -"""]] diff --git a/doc/todo/Nearline_support/comment_5_81b487864dbe7f4934f354839273fb69._comment b/doc/todo/Nearline_support/comment_5_81b487864dbe7f4934f354839273fb69._comment deleted file mode 100644 index a661dc17d..000000000 --- a/doc/todo/Nearline_support/comment_5_81b487864dbe7f4934f354839273fb69._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91" - nickname="justin.lebar" - avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e" - subject="comment 5" - date="2016-11-01T04:11:20Z" - content=""" -BTW I've been using this for the past few weeks, and it works great! Thank you for helping get this working. - -(Of course, there's now coldine to make work. But I don't have so much data that this makes a big difference to me. :) -"""]] diff --git a/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn b/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn deleted file mode 100644 index 9a7ce26a7..000000000 --- a/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -I made an attempt to tackle the following bug: - -[webapp should notice when remote deletion cannot complete due to not syncing](https://git-annex.branchable.com/bugs/webapp_should_notice_when_remote_deletion_cannot_complete_due_to_not_syncing/) - -My changes are in the following git repository - -[https://github.com/kathawala/git-annex.git](https://github.com/kathawala/git-annex.git) - -And the specific commit which fixes the bug is in a branch titled "unsync-nodelete". I have tested the change, it greys out and disables the "Delete" option in the "Actions" dropdown menu of the webapp for any repo in the "Repolist" view which has its syncing disabled. There is also some hover text which explains why the option is greyed out. Hope it is satisfactory! Thanks for your great work!! - -> I merged this patch, thank you! [[done]] --[[Joey]] diff --git a/doc/todo/Recommended_route_to_learning_Haskell__63__.mdwn b/doc/todo/Recommended_route_to_learning_Haskell__63__.mdwn deleted file mode 100644 index 9e1c30a94..000000000 --- a/doc/todo/Recommended_route_to_learning_Haskell__63__.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -Like many, I'm an experienced coder in procedural and object-oriented languages only. - -Could you recommend a route to learning Haskell I could work on a little bit every month, such that I might eventually become familiar enough to hack on git-annex? - -[[done]] diff --git a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_1_69bab2e1ab6382ba1149298e08ba659f._comment b/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_1_69bab2e1ab6382ba1149298e08ba659f._comment deleted file mode 100644 index f5b13dadc..000000000 --- a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_1_69bab2e1ab6382ba1149298e08ba659f._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-02T15:01:52Z" - content=""" -I'm taking this as an indication that [[/contribute]] needed some pointers -for learning haskell, so have made some changes there that might answer -your question, as well as others who see that page. -"""]] diff --git a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_2_857fffd7db3921718d2578944cfbaa09._comment b/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_2_857fffd7db3921718d2578944cfbaa09._comment deleted file mode 100644 index 92fa3bb44..000000000 --- a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_2_857fffd7db3921718d2578944cfbaa09._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" - nickname="0xloem" - avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" - subject="comment 2" - date="2016-11-06T11:42:48Z" - content=""" -thanks ! -"""]] diff --git a/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn b/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn deleted file mode 100644 index d159ce535..000000000 --- a/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -Please pull branch `patch-1` from repo - -https://github.com/ggreif/git-annex.git - -It contains some cleanups from warnings that appear with GHC 7.11 (and probably 8.0 too). - -> Merged and thank you! [[done]] --[[Joey]] diff --git a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_.mdwn b/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_.mdwn deleted file mode 100644 index c4a1acaf5..000000000 --- a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -If I understand it correctly, the original formulation is in fact incorrect. - -Please see https://github.com/joeyh/git-annex/pull/52/commits/e5bb450f44c6dfd01d7b2c84b3fa40c25867a47e for the patch. - -> [[done]] --[[Joey]] diff --git a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_/comment_1_411b3c1256a8f192707b0302e0fb5701._comment b/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_/comment_1_411b3c1256a8f192707b0302e0fb5701._comment deleted file mode 100644 index 78d712f64..000000000 --- a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_/comment_1_411b3c1256a8f192707b0302e0fb5701._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-06T16:31:03Z" - content=""" -No, it was correct as written. But, I think that was a confusing example -since it essentially contained a double negative, and so I changed it a -while ago to a --include example. -"""]] diff --git a/doc/todo/__34__copy_--failed__34__.mdwn b/doc/todo/__34__copy_--failed__34__.mdwn deleted file mode 100644 index fa3b071d7..000000000 --- a/doc/todo/__34__copy_--failed__34__.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -I often "copy --to remote" many files at once, and inevitably the transfer fails for some files (few out of hundreds). It would be great to subsequently be able to "copy --failed --to remote" to re-try only the transfers for failed files (similarly to how one can use "--unused"). - -Related: <https://git-annex.branchable.com/todo/make_copy_--fast__faster/> - -git-annex is awesome btw. Thanks! - -> [[done]] --[[Joey]] diff --git a/doc/todo/__34__copy_--failed__34__/comment_1_ff81023df39f9faac5935f6417ad2b38._comment b/doc/todo/__34__copy_--failed__34__/comment_1_ff81023df39f9faac5935f6417ad2b38._comment deleted file mode 100644 index b17372714..000000000 --- a/doc/todo/__34__copy_--failed__34__/comment_1_ff81023df39f9faac5935f6417ad2b38._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-08-03T15:07:43Z" - content=""" -Nice idea, and there's already an implementation of a log of recent failed -transfers that the assistant uses, that can be reused for this. -"""]] diff --git a/doc/todo/__34__copy_--failed__34__/comment_2_9044c9b76f25114914f68afe0c7c0506._comment b/doc/todo/__34__copy_--failed__34__/comment_2_9044c9b76f25114914f68afe0c7c0506._comment deleted file mode 100644 index 57ae3727e..000000000 --- a/doc/todo/__34__copy_--failed__34__/comment_2_9044c9b76f25114914f68afe0c7c0506._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="eslgastal" - subject="comment 2" - date="2016-08-04T00:56:30Z" - content=""" -That was fast! Thanks again Joey. -"""]] diff --git a/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn b/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn deleted file mode 100644 index 5e0598816..000000000 --- a/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -ATM in DataLad we rely on 'git annex find' to determine either files have content locally. Even though it could be used in a batch mode, I wondered if we could may be just use 'annex info' to obtain information either a file (or a key) has content locally? Another benefit would be is that within single command output we could determine also if a file under annex or not (instead of first doing e.g. 'info' to figure out if under annex and then 'find' again to figure out if content is present locally) - - -[[!meta author=yoh]] - -> sure, [[done]] --[[Joey]] diff --git a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option.mdwn b/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option.mdwn deleted file mode 100644 index 9a4e925b2..000000000 --- a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -This commit is also available in the "log-raw-missing-dash" branch at <https://github.com/sunny256/git-annex.git>. - -[[!format hs """ -From 5e00265dae057e1846d5a256f450c8a1e1803c97 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Wed, 24 Jun 2015 17:07:37 +0200 -Subject: [PATCH] Log.hs: Add missing dash to --raw option - -After commit eb33569f ("remove Params constructor from -Utility.SafeCommand", 2015-06-01), git-annex aborted with the error -message "fatal: unrecognized argument: -raw" when executing "git annex -log". ---- - Command/Log.hs | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/Command/Log.hs b/Command/Log.hs -index 9ee7f85..495c43c 100644 ---- a/Command/Log.hs -+++ b/Command/Log.hs -@@ -151,7 +151,7 @@ getLog key os = do - [ Param "log" - , Param "-z" - , Param "--pretty=format:%ct" -- , Param "-raw" -+ , Param "--raw" - , Param "--abbrev=40" - , Param "--remove-empty" - ] ++ os ++ --- -2.4.4.408.g16da57c - -"""]] - -> Thanks for the patch! Someone else reported a bug about it and I already -> patched it when I noticed this, so you missed getting in the commit log.. -> this time! ;) [[done]] --[[Joey]] diff --git a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option/comment_1_f56776e10b58547c3e8d3e55599a3fa9._comment b/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option/comment_1_f56776e10b58547c3e8d3e55599a3fa9._comment deleted file mode 100644 index 9feb93633..000000000 --- a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option/comment_1_f56776e10b58547c3e8d3e55599a3fa9._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="sunny256" - subject="comment 1" - date="2015-07-06T22:33:48Z" - content=""" -Hehe, yep. ;) But it was quite low-hanging fruit anyway, and I'm glad it's fixed. Thanks. Hope you had a nice holiday, though. You deserve it. — Øyvind -"""]] diff --git a/doc/todo/ability_to_set_metadata_from_json.mdwn b/doc/todo/ability_to_set_metadata_from_json.mdwn deleted file mode 100644 index 1129650a0..000000000 --- a/doc/todo/ability_to_set_metadata_from_json.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -I can export metadata to JSON format, which is nice as this can now be read -into any other tool and manipulated. But I cannot find a way to set the -metadata from JSON and so I am left to figure out what changes need to be -made via the g-a interface to get to the desired state, and that is hard to -get right. - -Maybe g-a metadata could grow an import-json function which would set -(overwrite) the metadata for the given file(s) from JSON input. - -Thanks, --m - -> [[done]] via `git annex metadata --batch --json` --[[Joey]] diff --git a/doc/todo/add_magicmime_support_to_OSX_dmg.mdwn b/doc/todo/add_magicmime_support_to_OSX_dmg.mdwn deleted file mode 100644 index ef69869ba..000000000 --- a/doc/todo/add_magicmime_support_to_OSX_dmg.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -The OSX .dmg is built without the MagicMime build flag. Turning it on will -take some work to ship a copy of the magic database inside the dmg. - -> [[done]] ---[[Joey]] diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn b/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn deleted file mode 100644 index c322660df..000000000 --- a/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -I thought that whereis command would report only based on the knowledge annex has locally in git-annex branch, but apparently it is trying to query for information even in --fast mode: - -[[!format sh """ -$> git annex whereis --fast bold.nii.gz -yoh@dat.... -Permission denied (publickey,password). -fatal: Could not read from remote repository. - -Please make sure you have the correct access rights -and the repository exists. -whereis bold.nii.gz -(2 copies) - 899f0347-0888-48ef-91b6-bac213ca8cef -- [datalad-archives] - c8bd3d05-33d4-4b59-9d53-ca7efbdcdd13 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/openfmri/ds000001 [here] - - datalad-archives: dl+archive:MD5E-s2527262329--bd3ea399057c529b37b09dcecec1ca60.0raw.tgz/ds001_R1.1.0/sub001/BOLD/task001_run001/bold.nii.gz#size=47241449 - -"""]] - -[[!meta author=yoh]] -Was [[done]] by [[Joey]] as of 6.20160524+gitg2b7b2c4-1~ndall+1 diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment deleted file mode 100644 index 1066455ed..000000000 --- a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-25T17:44:59Z" - content=""" -This is not specific to whereis at all. You have added a new git remote and -git-annex does not know what the uuid of it is. Until it can find out, it -won't be able to use that remote (including referring to it in whereis -output). So, git-annex always tries to get the uuid for such remotes -at startup time. - -If you don't want git-annex to use this remote, you can set -remote.name.annex-ignore. -"""]] diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment deleted file mode 100644 index 041b59028..000000000 --- a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-04-25T18:28:14Z" - content=""" -gotcha... indeed, after allowing annex to fetch uuid for it and adjust .git/config it doesn't go over ssh during whereis. -I don't have a strong use case yet to further support --no-network or alike for whereis ATM so feel free to close, but I am afraid it might bite me again later whenever I wouldn't expect any demand from annex/ssh for interactive prompts while running some command which doesn't usually require interaction (e.g. whereis) due to querying remote locations. -"""]] diff --git a/doc/todo/annex.hardlink_should_also_affect_copy_to_origin.mdwn b/doc/todo/annex.hardlink_should_also_affect_copy_to_origin.mdwn deleted file mode 100644 index d79c13f92..000000000 --- a/doc/todo/annex.hardlink_should_also_affect_copy_to_origin.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -When a repo has annex.hardlink set, objects are hard-linked into the -repository when eg `git annex copy --from origin`. This should also -be done when copying files --to origin (or other remotes on the same -filesystem). This way, a quick shared clone can be used to add/modify -files, and cheaply send the changes back to the parent repo. --[[Joey]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/autoenable__61__true_for_special_remotes.mdwn b/doc/todo/autoenable__61__true_for_special_remotes.mdwn deleted file mode 100644 index 7e93ded0d..000000000 --- a/doc/todo/autoenable__61__true_for_special_remotes.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -Just passing along from https://github.com/datalad/datalad/issues/77#issuecomment-134688459 - -joey: I do think there could be a use case for configuring a special remote with autoenable=true and have git-annex init try to enable all such remotes. - -> [[done]], I made both `git init` and `git annex reinit` auto-enable -> such special remotes. For now, the assistant does not (could change). -> -> There was also the question of what to do when git-annex auto-inits -> in a clone of a repository. It wouldn't do for a command like -> `git annex find`'s output to include any messages that might be shown while -> auto-enabling special remotes as a result of an auto-init. -> Since I can't guarantee enabling special remotes will be quiet, I've not -> tried to auto-enable special remotes in this case. -> -> I think I'd have to -> exec a git-annex init process with stdout sent to stderr to implement -> this in a safe way, and due to calls to ensureInitialized in Remote.Git, -> which can auto-init a local remote, that gets particularly tricky. Best, I -> feel, to wait and see if anyone needs that. ---[[Joey]] diff --git a/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment b/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment deleted file mode 100644 index b04a8c245..000000000 --- a/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - subject="comment 1" - date="2015-08-25T18:25:44Z" - content=""" -There are going to be many configurations where auto-enable of a special remote fails. Ie, when creds are needed. While some of these could be detected and skipped, I sort of like the simplicity of having it try to enable everything. - -Maybe a command is also needed to autoenable remotes after the first git-annex init? Since it's actually ok to re-run git-annex init in an initalized repo, I suppose it could just be run again. -"""]] diff --git a/doc/todo/autoenable__61__true_for_special_remotes/comment_2_e099d623a471c42bb9d14d0e965d6ba0._comment b/doc/todo/autoenable__61__true_for_special_remotes/comment_2_e099d623a471c42bb9d14d0e965d6ba0._comment deleted file mode 100644 index 7cf9225ec..000000000 --- a/doc/todo/autoenable__61__true_for_special_remotes/comment_2_e099d623a471c42bb9d14d0e965d6ba0._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da" - subject="should annex merge autoenable newly added autoenable'ed special remotes" - date="2016-11-04T12:43:55Z" - content=""" -relevant case: https://github.com/datalad/datalad/issues/1093 -"""]] diff --git a/doc/todo/batch_get__47__drop__47__etc.mdwn b/doc/todo/batch_get__47__drop__47__etc.mdwn deleted file mode 100644 index 154d4aca6..000000000 --- a/doc/todo/batch_get__47__drop__47__etc.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -in the spirit of [[todo/--batch_for_add/]], [[todo/--batch_for_info/]], [[todo/--batch_for_find/]] and [[todo/--batch_for_whereis/]], why not add `--batch` to get/drop/import operations? - -I am writing a script to get a bunch of arbitrary files and i want to avoid the overhead of running git-annex multiple times. I know i can use `annex.alwayscommit=false` but that is rather counter-intuitive as well. --[[anarcat]] - -> [[done]] for add and drop. (Not for import, but if someone requests it -> with a use case we'll see.) --[[Joey]] diff --git a/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment b/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment deleted file mode 100644 index 69b5d03a6..000000000 --- a/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-20T18:30:23Z" - content=""" -I prefer keeping --batch on things that act in terms of keys and have a -simpler interface. - -So, could add --batch to `git annex transferkey`. This would presumably -need to disable any process displays in order for success/failure to be -communicated in a machine-parsable way. (Actually, `git annex transferkeys` -already implements such a batch interface, but one that is currently -not documented due to only being built for the assistant to use it.) - -There is already `git annex dropkey --batch`, although it does not -verify that other copies exist. -"""]] diff --git a/doc/todo/checkpresentkey_without_explicit_remote.mdwn b/doc/todo/checkpresentkey_without_explicit_remote.mdwn deleted file mode 100644 index 7ad667f28..000000000 --- a/doc/todo/checkpresentkey_without_explicit_remote.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -While being asked to check if file is available from "[datalad-archives]" remote I need to check if the archive's key available. Ideally I wish I could ask through the ongoing interaction protocol, but if not, I could use smth like 'git annex checkpresentkey' but that one demands specification also of a remote which to check. In my case I just want to know if that key is available from any remote, so I could confirm that the file is still present in our archives remote, i.e. that it could be retrieved later on - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/checkpresentkey_without_explicit_remote/comment_1_eab7b9d6d026675328d0e743a385ba8a._comment b/doc/todo/checkpresentkey_without_explicit_remote/comment_1_eab7b9d6d026675328d0e743a385ba8a._comment deleted file mode 100644 index 600cae51b..000000000 --- a/doc/todo/checkpresentkey_without_explicit_remote/comment_1_eab7b9d6d026675328d0e743a385ba8a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-12T20:07:30Z" - content=""" -Makes sense, and also I will add a --batch mode to it. - -Done. -"""]] diff --git a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn b/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn deleted file mode 100644 index 3b1b929ea..000000000 --- a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -Since in datalad we are invoking git and git-annex quite frequently, and on debian systems atm relying on git-annex-standalone pkg, I wondered, if there is a possibility to get all 'shimmed' binaries prelinked against shipped core libs to avoid a current bunch of unsucesfull searches for libraries.... I thought it might provide a notable benefit. - -just an idea - -[[!meta author=yoh]] - -> [[fixed|done]], but without prelinking. --[[Joey]] diff --git a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/comment_1_1bdc41c22f472d1d6adac563952fe354._comment b/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/comment_1_1bdc41c22f472d1d6adac563952fe354._comment deleted file mode 100644 index 7ec438147..000000000 --- a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/comment_1_1bdc41c22f472d1d6adac563952fe354._comment +++ /dev/null @@ -1,59 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-06T15:59:34Z" - content=""" -Startup time is also particulary important when git-annex is being used as -a smudge/clean filter in v6 mode, since it's run once per file git operates -on. - ---- - -What I'd look at before prelinking is, does your git-annex executable -dynamically link haskell libraries? - -That was the case for a while in the standalone builds, until I noticed it -caused too much linker time and put it back to static linking of the -haskell libs. Leaving only 34 or so C shared libs. - ---- - -Did some preliminary benchmarking here of `git-annex version --raw` - -* deb package build: 0.04 seconds min -* deb package build prelinked: ~0.03 seconds min -* standalone build: 0.05 seconds min -* git-annex modified to print "hi" and exit immediately: 0.02 seconds min - -So, the overhead of the wrapper scripts for the standalone build is around -0.01 seconds. - -And, prelinking does help a little bit (although probably closer to 0.005 -seconds than 0.01; my measurements are too coarse to get a good number). - -Meanwhile, 0.02 seconds are used after git-annex starts up. This overhead -includes finding the path to the git repository, running and parsing `git -config --list`, etc. - -But what about that 0.02 seconds just to print "hi"...? - ----- - -With strace I noticed a very interesting thing. Despite being statically -linked against the haskell libraries, the linker searches in all their -paths for all C libraries. This adds around 30000 failed open() calls -to git-annex's startup. This is done even after prelinking. It must be a -significant part of the startup time. - -Filed a bug: <https://github.com/haskell/cabal/issues/3524> - -Put in a chrpath workaround, but only when git-annex is built with "make" -(not cabal install git-annex). - -Updated benchmarks: - -* deb package build: 0.02 seconds min -* deb package build prelinked: ~0.02 seconds min -* standalone build: 0.03 seconds min -* git-annex modified to print "hi" and exit immediately: 0.01 seconds min -"""]] diff --git a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already.mdwn b/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already.mdwn deleted file mode 100644 index 4e3c53e0a..000000000 --- a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already.mdwn +++ /dev/null @@ -1,4 +0,0 @@ - -While trying so establish a jabber link via a server that runs a nonstandard port I came across the problem that git-annex always appends :5222 to the jabber server address. This effectively stops the connection procedure at a point where it does not need to. - -> XMPP support has been removed from git-annex, so closing. [[done]] diff --git a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already/comment_1_bee9f8431a134e790c36b22d83bfb7ae._comment b/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already/comment_1_bee9f8431a134e790c36b22d83bfb7ae._comment deleted file mode 100644 index 275d54b15..000000000 --- a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already/comment_1_bee9f8431a134e790c36b22d83bfb7ae._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-10T17:47:05Z" - content=""" -Well, the weppapp prompts for a XMPP address, which AFAIK does not include -a port. - -`.git/annex/creds/xmpp` can contain a port, but that's only used when -the SRV record lookup doesn't find anything. Since most XMPP servers -have SRV records, and SRV includes a port. - -AFAICS, if the SRV record includes a nonstandard port, it will be used. -If there's no SRV record, port 5222 will be used, unless you edit -`.git/annex/creds/xmpp` to use another port, and then what you specified -will be used. -"""]] diff --git a/doc/todo/drop_--batch.mdwn b/doc/todo/drop_--batch.mdwn deleted file mode 100644 index 775798752..000000000 --- a/doc/todo/drop_--batch.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -There is a dropkey --batch, so I guess I could workaround but probably would be nice for consistency to have --batch mode for drop itself as well - -[[!meta author=yoh]] - -> [[done]]; went ahead and added drop --batch to be symmetric with get -> --batch. --[[Joey]] diff --git a/doc/todo/drop_--batch/comment_1_eff1bec0af5e7a7364d2fdaea6a8826f._comment b/doc/todo/drop_--batch/comment_1_eff1bec0af5e7a7364d2fdaea6a8826f._comment deleted file mode 100644 index d921d9ee0..000000000 --- a/doc/todo/drop_--batch/comment_1_eff1bec0af5e7a7364d2fdaea6a8826f._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-03T19:06:53Z" - content=""" -Might be better to make `dropkey` do the same numcopies checking as -`drop` does. Currently, `dropkey` needs `--force` to do anything (and it's -always needed that), so it could do numcopies checking when not forced, -without breaking backwards compatability. - -The benefit of keeping this in `dropkey` is that dropping by key -tends to work better with batch adds/imports of files that are occurring at -the same time. - -Only downside I see is that dropping by key is unable to honor -.gitattributes numcopies settings, since the associated filename is not -known. -"""]] diff --git a/doc/todo/external_special_remote_not_used_concurrently_with_-J.mdwn b/doc/todo/external_special_remote_not_used_concurrently_with_-J.mdwn deleted file mode 100644 index 65575f8a1..000000000 --- a/doc/todo/external_special_remote_not_used_concurrently_with_-J.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -When using an external special remote with -Jn, multiple transfers do not -happen concurrently to the remote. A single process is -started for the external special remote, and there's locking to only let -one request be made of it at a time. - -This should not be hard to make to use a pool of Externals, starting up a -new one if the pool is empty or all in use. --[[Joey]] - -[[users/yoh]] may want this for datalad? - -> [[done]] --[[Joey]] diff --git a/doc/todo/find_unused_in_any_commit.mdwn b/doc/todo/find_unused_in_any_commit.mdwn deleted file mode 100644 index cfe2faab8..000000000 --- a/doc/todo/find_unused_in_any_commit.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -`git annex unused` only looks at tags and branches. Some users would like -to drop any objects that are not pointed to by any commit, but keep any -object that any commit ever referenced. - -This could be a switch, like --ever. - -The implementation would need to walk the history of all branches and check -all commits. This would tend to be slow. It could look at tags+branches as -it does now as a first pass, and only do the slow part if there are objects -not referred to by the tags+branches. And, it could stop looking through -the whole commit history if there were no more objects to check. Still, -gonna be slooow. Another optimisation would be to get only the objects -changed by the commit, and not look at the whole tree as it appeared on -each commit. --[[Joey]] - -> Closing, --used-refspec allows doing this kind of thing. -> (It can indeed make it slow!) [[done]] --[[Joey]] diff --git a/doc/todo/find_unused_in_any_commit/comment_1_cecdf4e8600fbcf5d1541e35a91fb37b._comment b/doc/todo/find_unused_in_any_commit/comment_1_cecdf4e8600fbcf5d1541e35a91fb37b._comment deleted file mode 100644 index 04fe62666..000000000 --- a/doc/todo/find_unused_in_any_commit/comment_1_cecdf4e8600fbcf5d1541e35a91fb37b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnRFOsnEk8AJg1mXlq3mJDdt1YdYepozE8" - nickname="Murmel" - subject="Other loop strategy?" - date="2014-11-13T21:42:57Z" - content=""" -My motiviation to have such a feature is to free space if a key is unused in the \"--ever\" sense. I think it is no problem if this is a slow operation, as you don't use it often. How about this strategy: Loop over keys, for each key find out with something like \"git log -S\" if it is used. -"""]] diff --git a/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment b/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment deleted file mode 100644 index 8d489927f..000000000 --- a/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="eigengrau" - subject="comment 2" - date="2015-05-28T13:44:32Z" - content=""" -This would be absolutely awesome, because it would pruning away old data based on cut-offs. One could squash all history beyond some cut-off point. Or, probably better, one could preserve git history, but supply “git annex fsck” with a cut-off switch that specifies a date or time interval. All data referred to in commits older than the specified interval is then considered unused. -"""]] diff --git a/doc/todo/fix_git-annex-smudge.1.mdwn b/doc/todo/fix_git-annex-smudge.1.mdwn deleted file mode 100644 index 3daaa4619..000000000 --- a/doc/todo/fix_git-annex-smudge.1.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -Fixing errors in the git-annex-smudge manage. - -``` -The following changes since commit fa15580d1a55aef612a4a973e74e1728c371e98f: - - (2016-08-16 15:14:37 +0000) - -are available in the git repository at: - - https://git.jim.sh/jim/git-annex.git jim - -for you to fetch changes up to e2a55fdbaeb4acfd09910649689868f1c4f0625b: - - Don't escape leading dots in code blocks in manpage (2016-08-16 11:51:16 -0400) - ----------------------------------------------------------------- -Jim Paris (2): - Fix path in git-annex-smudge(1) - Don't escape leading dots in code blocks in manpage - - Build/mdwn2man | 2 +- - doc/git-annex-smudge.mdwn | 2 +- - 2 files changed, 2 insertions(+), 2 deletions(-) -``` - -> Thanks Jim. [[merged|done]] --[[Joey]] diff --git a/doc/todo/get_--batch.mdwn b/doc/todo/get_--batch.mdwn deleted file mode 100644 index a23b36de0..000000000 --- a/doc/todo/get_--batch.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -It seems that it would be tremendously useful, see e.g. our [datalad install](https://github.com/datalad/datalad/issues/553) - -[[!meta author=yoh]] - -> [[done]] although the output while getting a file is not -> machine-parseable. So, I made --json also work for get, but enabling -> json output disables any progress display. --[[Joey]] diff --git a/doc/todo/get_round_robin.mdwn b/doc/todo/get_round_robin.mdwn deleted file mode 100644 index 25c3a8644..000000000 --- a/doc/todo/get_round_robin.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -`git annex get` always gets files from the remote with the lowest cost. - -When two remotes have the same cost, it breaks the tie somehow, -and consistently prefers one of them over the other. - -It would be nice if it instead round-robined amoung remotes with -the same cost that have the file. In particular, with -J2, and 2 remotes -A and B having each file, one thread could download from A and the other -from B. That might be much faster than the current behavior of two threads -downloading everything from A. - -Maybe a way to implement it is to keep a list of recently used remotes, -and when starting a new get from a set of remotes that have the same cost, -prefer the remote that is futher down the recently used list (or not on it -at all). (Or, since git-annex has a remote list already, it could rotate -the remotes of the same cost whenever starting a download from one.) - -While this would be a nice improvement to -J2 from network remotes, -it might not really be desirable when not run in parallel. In particular, -if A and B are on different spinning disks, then an access pattern of -A,B,A,B might keep the disks idle enough that they spin down in-between -access. - -> done for `git annex get -JN` where two remotes have the same cost. -> -> Also for `git annex sync --content -JN` when downloading and two remotes -> have the same cost. -> -> Can't think of any other places that apply, except perhaps the assistant, -> but it does its own much different queuing of transfers. [[done]] -> --[[Joey]] diff --git a/doc/todo/git_annex_push.mdwn b/doc/todo/git_annex_push.mdwn deleted file mode 100644 index 4abdf253c..000000000 --- a/doc/todo/git_annex_push.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -A common use case for me is to use annex as really just an addition to git to store additional content. What I am ending up with is two stage procedure to submit my changes to our shared repository: git push REMOTE; git annex copy --to=REMOTE . IMHO it would only be logical if there was "git annex push REMOTE [GITPUSHOPTIONS]" which would be merely an alias for "git push REMOTE [GITPUSHOPTIONS]; git annex copy --to=REMOTE" but which will make use of annex for such common usecase simple(r) - -> After this was opened, some options were added, so use: -> `git-annex sync --no-pull --content` -> -> [[done]] --[[Joey]] diff --git a/doc/todo/git_annex_push/comment_1_54c5494ec21621298b3111cd7c2325b1._comment b/doc/todo/git_annex_push/comment_1_54c5494ec21621298b3111cd7c2325b1._comment deleted file mode 100644 index 608f1f936..000000000 --- a/doc/todo/git_annex_push/comment_1_54c5494ec21621298b3111cd7c2325b1._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-08-04T20:19:22Z" - content=""" -`git annex sync --content` does what you want, only it also does a pull and -a merge from remotes. - -I don't know that wanting to only push, w/o pull and merge, is common -enough to make a separate command for it. - -There's also the problem that to push the git-annex branch, it really -makes sense to first pull/merge from the remote. Otherwise, the push -is not likely to work as well. And too, it makes sense to update the -git-annex branch from remotes in order to know what files that have, so -that info can be better used to decide which files to send to them -- -especially when preferred content might make some file not be sent to all -remotes, depending on which other remotes contain the file. -"""]] diff --git a/doc/todo/git_annex_push/comment_2_67938223c42c2a81dbfd32cd8a6a39c2._comment b/doc/todo/git_annex_push/comment_2_67938223c42c2a81dbfd32cd8a6a39c2._comment deleted file mode 100644 index 757824cb8..000000000 --- a/doc/todo/git_annex_push/comment_2_67938223c42c2a81dbfd32cd8a6a39c2._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-08-09T03:04:31Z" - content=""" - indeed pull/merge ( ie sync) would often be needed. but the same in regular git workflow - we can't push if remote has new changes. so we know that we need to \" git pull\" ( or alternative merge dance). my whining here is pretty much about dichotomy between regular git command and accompanying annex commands for simple typical workflows - i need to educate people much more beyond \" in your typical use case, when you all collaborate on this repo, just use git annex add to place big files under annex control, and then git annex push to push all your changes\". then if annex push checked first that push of annex branch can't happen and that annex merge is due, and let user know to run it first - they will do, and things will remain clear. now there is a lot of annex uniquely named commands which do not \" correlate\" with git ones even for simple use cases, which makes adoption harder imho. -"""]] diff --git a/doc/todo/git_annex_push/comment_3_ccb822eeb9b0d60f811568e4f27f970a._comment b/doc/todo/git_annex_push/comment_3_ccb822eeb9b0d60f811568e4f27f970a._comment deleted file mode 100644 index f28008d22..000000000 --- a/doc/todo/git_annex_push/comment_3_ccb822eeb9b0d60f811568e4f27f970a._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-08-11T17:37:05Z" - content=""" -I tend to be uncomfortable with wrapping many git commands into git-annex -commands with the same name. All the regular git commands can be used -in a git-annex repository, and I don't want to get users thinking they need -to look for git-annex commands instead when the git commands work perfectly -well. - -`git annex copy` is fundamentally different than `git push`, so the user -needs to learn about the complication of needing to copy the contents -around separately. Perhaps even copying content to different (special) -remotes than where git pushes to. `git annex sync --content` is there for -users who want to keep two repos in sync and don't want to be concerned with the details. -`git annex push` would seem to be for users who want to know about the details, -but not all of them. Seems like a losing and/or confusing choice. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn b/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn deleted file mode 100644 index 68125c53b..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -It would be really nice if external tools working with annex could obtain updates on the progress of operations so they could report using their own UI back to the user. Especially relevant for --batch --json modes of operations (e.g. for get or addurl) whenever no progress is reported by annex itself at all. - -Related: -[datalad #478](https://github.com/datalad/datalad/issues/478) - - -[[!meta author=yoh]] - -> --status-fd is one way, or the progress could be included as -> part of the --batch protocol. In either case, it might make sense to -> reuse part of the external special remote protocol. (Which would let you -> relay the progress messages when datalad is doing a nested retrieval, I -> suppose.) --[[Joey]] - ->> [[done]]; --json-progress implemented. I limited the frequency of json ->> progress items to 10 per second max, and it's typically only 1 per ->> second or less, so didn't implement ->> --json-progress=N to tune it. Also added --json and --json-progress to ->> copy, move, mirror commands. --[[Joey]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment deleted file mode 100644 index df74f19cb..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment +++ /dev/null @@ -1,65 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-08T15:32:00Z" - content=""" -yoh pointed out in email that reusing the special remote interface would -not work with -J because it doesn't tell what key progress is being shown -for. - -Also, note that --json -J does not currently output json; -J overrides the ---json to instead use concurrent-output for progress display. The current -way that json is emitted incrementally would need to be changed to be usable -with -J. - -Is there any need for a program that is driving git-annex with --json -to use -J, instead of just starting several git-annex processes? The only -major benefit I can think of is the recently added better selection between -multiple remotes by parallel `git annex get`. Other performance benefits -between -J and multiple processes should mostly be small. - -To suppose --json -J, instead of a partial json object that later gets added -to as the command progresses: - - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..." - -We'd need something like this, with each json object buffered -and only output when it was complete (and output serialized so -objects are written one at a time): - - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...", "inprogress":true} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","success":true} - -If we're doing that, we might as well use json for the progress info too, -in between the two json objects in the example above: - - {"percent-progress":"25%","byte-progress":500,"key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3"} - {"percent-progress":"75%","byte-progress":1500","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3"} - -But this is a large change to the json format, and would probably break -all consumers of it. I don't like that, but also don't like the complexity -of having two different varieties of json output for parallel and -non-parallel modes. - -Hmm, if we're buffering the "command" json objects, we could keep them -formatted the same as they are now, only displaying them when done. And -progress objects could be inserted before: - - {"percent-progress":"25%","byte-progress":500,"key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar"} - {"percent-progress":"75%","byte-progress":1500","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar"} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true} - -That seems a bit verbose, but I think all that info could be needed by -consumers of the progress objects. Hmm, since the "command" json objects -are being buffered, we could even include the currently buffered object -nested inside the progress object: - - {"percent-progress":"25%","byte-progress":500,"action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}} - {"percent-progress":"75%","byte-progress":1500,"action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true} - -That's not a lot more verbose than the earlier version, and it ensures that -consumers of the progress objects have all possible information available -(including the name of the remote being downloaded from in the above -example). -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_2_f0271ed42caddb12d06f6430b8cb79f0._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_2_f0271ed42caddb12d06f6430b8cb79f0._comment deleted file mode 100644 index af8304052..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_2_f0271ed42caddb12d06f6430b8cb79f0._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-09-08T16:12:07Z" - content=""" -sounds good to me... the only remark that to not break compatibility with other git-annex consumers may be there could be additional switch to instruct annex to produce those progress records (e.g. --json-progress) which would only then provide progress reporting back, thus by default staying compatible with current behavior. - -as for -J - I guess indeed we could start multiple parallel annex processes operating on the same repository, but I wonder if then necessary locking etc between multiple processes wouldn't introduce additional performance hit etc. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment deleted file mode 100644 index 33e05de54..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-09-08T16:20:27Z" - content=""" -Needing to use file-level locking etc does make the mult-process approach -to parallelism more expensive, but only I think by a small amount. - -Yes, there might need to be a switch to enable the json progress output. -Although given the un-typed nature of json, consumers should probably be -written with a plan in mind for what to do if they encounter something they -don't understand. Any comsumer that just skips over unrecognised json -objects would not be impacted by adding the progress.. - -And here's a way to make the progress json less verbose: - - {"progress-id":"1","action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}} - {"progress-id":"1","percent-progress":"25%","byte-progress":500} - {"progress-id":"1","percent-progress":"75%","byte-progress":1500} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true} - -Makes the consumer's job a bit more complicated, and could also make the -implementation in git-annex harder. Is it worth it? -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_4_b4a1790fc4e7a7999dde819be81b4b0d._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_4_b4a1790fc4e7a7999dde819be81b4b0d._comment deleted file mode 100644 index 4c5e82dcf..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_4_b4a1790fc4e7a7999dde819be81b4b0d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-09-08T16:27:04Z" - content=""" ---json-progress=1 would also provide a way to tune how frequently the -progress updates happen (eg max once per second). Which seems better than -worrying about how large the json objects are. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_5_6cbe08fc84141f1c7c31d737ae5bdce0._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_5_6cbe08fc84141f1c7c31d737ae5bdce0._comment deleted file mode 100644 index d82cca98a..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_5_6cbe08fc84141f1c7c31d737ae5bdce0._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 5" - date="2016-09-08T18:08:49Z" - content=""" -good idea on parametrizing frequency of updates from json -- indeed we wouldn't want to deal with output from it probably more often than once in a second per file. Either \"skinny\" progress indication using IDs or full ones (so we could match by e.g. key) would work for us I think - -btw, just so that we don't forget. I guess all of this would also be needed to be done for addurl, copy, move commands, right? (copy and move do not have --json yet) ;) -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment deleted file mode 100644 index 5b1134be8..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="+may be "byte-target" field? ;)" - date="2016-09-24T02:43:21Z" - content=""" -THANK YOU for implementing this feature -- we will make use of it soon. -But so we don't do reverse estimation from \"byte-progress\" and \"percent-progress\", and didn't have to get it from a key (which might not have it e.g. in case of URL relaxed backend) -- could you just include in each record the \"byte-target\" (if known) or something like that? ;) thanks in advance! -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_7_dc29d3603ce7ce436fac7fa6d6f80871._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_7_dc29d3603ce7ce436fac7fa6d6f80871._comment deleted file mode 100644 index 2acb1e16c..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_7_dc29d3603ce7ce436fac7fa6d6f80871._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2016-09-29T20:27:46Z" - content=""" -Added a "total-size" field for the size. Although, if a key's size is not -known, git-annex does not currently do any progress displays for that key. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_8_2e11e383dd4e95e8a3df30039face3eb._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_8_2e11e383dd4e95e8a3df30039face3eb._comment deleted file mode 100644 index 0de769a5d..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_8_2e11e383dd4e95e8a3df30039face3eb._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 8" - date="2016-09-29T20:45:48Z" - content=""" -extracting size from a key I have done myself already ;) but what if it is for a relaxed download - it still wouldn't show (based on the downloader's information)? (yet to build/try to discover myself) -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_9_32bfa465567eaad105a8336bc247cc2f._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_9_32bfa465567eaad105a8336bc247cc2f._comment deleted file mode 100644 index 280cb3116..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_9_32bfa465567eaad105a8336bc247cc2f._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 9""" - date="2016-09-29T20:58:13Z" - content=""" -Gone ahead and made --json-progress be displayed when size is not known, -although of course it then has to omit the total-size and percent-progress -fields. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn b/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn deleted file mode 100644 index b80349a76..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -ATM git annex addurl ignores annex.largefiles option so to automate annexification or direct add to git for a list of files I need manually to download each one of them into a FILE and then "git annex add -c annex.largefiles='exclude=*.txt' FILE". But it would have been convenient if I could "addurl" some files directly from urls directly into git, as per largefiles settings. - -N.B. I do understand that use-case might be somewhat vague, let me know if I should expand reasoning -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_1_054568fa73fdff81b05ffd1dc7199cee._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_1_054568fa73fdff81b05ffd1dc7199cee._comment deleted file mode 100644 index cde0cd873..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_1_054568fa73fdff81b05ffd1dc7199cee._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-10T19:04:50Z" - content=""" -When addurl --relaxed is used, it doesn't hit the url at all, so doesn't -know the size, so annex.largefiles couldn't be applied in that case. - -So that's an inconsistency. Perhaps a minor one. - -`git annex import` doesn't currently honor annex.largefiles either. - -I am ambivilant about whether these commands should, but it probably makes -sense for them to behave the same. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_2_110a15c95e76b4771e31c06eb80d1f03._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_2_110a15c95e76b4771e31c06eb80d1f03._comment deleted file mode 100644 index 6f0681698..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_2_110a15c95e76b4771e31c06eb80d1f03._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-11-10T19:24:59Z" - content=""" -as for import (never used it yet) -- there is no reason not to warrant largefiles since it has all the information, right? - -as for addurl -- ideally, I guess, it could just crash iff there is a largefiles setting which relies on size and --relaxed is used (would indeed make little sense). But in the other cases (I guess of which there is majority) it could as well warrant it, thus making behavior more consistent. - -[[!meta author=yoh]] -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_3_892f232c8b8746cac01b5a80239985a2._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_3_892f232c8b8746cac01b5a80239985a2._comment deleted file mode 100644 index 1357e8783..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_3_892f232c8b8746cac01b5a80239985a2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="another side-effect of largefiles not being supported for my usecase" - date="2016-01-12T17:20:08Z" - content=""" -since there is no support for largefiles in addurl, is there ANY way to get idea either annex would have added a file to git or to annex if I do know the filename and its size? pretty much a use-case is downloading/adding (small) .txt files to git, while the rest to annex in --fast (or --relaxed) mode. -If there is no way to query annex'es opinion given necessary information, I would have no ability to decide on my end without duplicating largefiles checking logic. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_4_4721f94167bcec5841ce8432347fbc0d._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_4_4721f94167bcec5841ce8432347fbc0d._comment deleted file mode 100644 index 46468997a..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_4_4721f94167bcec5841ce8432347fbc0d._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-01-13T19:11:33Z" - content=""" -Er, re your last comment, I closed this bug because I made addurl honor -annex.largefiles.. - -That was done in December 8th. AFAICS, there's nothing more to be done -except use that feature. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_5_16390f75b3685df93f18a89e7cb56757._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_5_16390f75b3685df93f18a89e7cb56757._comment deleted file mode 100644 index 3f362489b..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_5_16390f75b3685df93f18a89e7cb56757._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject=""done" but only for non --fast/--relaxed" - date="2016-01-13T23:49:30Z" - content=""" -ah -- didn't spot that it was \"done\" (didn't see a notification on it being resolved in invoice or emails) - -unfortunately it seems to not work for --fast (or --relaxed, although that one I guess I can understand): - -[[!format sh \"\"\" - -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git -c annex.largefiles=exclude=*.txt annex addurl --file=test.txt --fast \"http://www.onerussian.com/tmp/banner.png\" -addurl test.txt ok -(recording state in git...) - -$ ls -l test.txt -lrwxrwxrwx 1 yoh yoh 132 Jan 13 18:44 test.txt -> .git/annex/objects/KW/kj/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png - -\"\"\"]] - -it does for if no --fast, or --relaxed -"""]] diff --git a/doc/todo/make_status_show_staged_files.mdwn b/doc/todo/make_status_show_staged_files.mdwn deleted file mode 100644 index 4d418bc11..000000000 --- a/doc/todo/make_status_show_staged_files.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -### Please describe the problem. - -`git annex status` does not report the fact that some files have been added but not yet committed. - -### What steps will reproduce the problem? - - $ # alwayscommit = false - $ echo "new" > new-file - $ git annex status - ? new-file - $ git annex add - add new-file - $ git annex status - $ - -Using the `git status` command directly will show the added files - - $ git -c core.bare=false status --porcelain | grep -v '^ T' - AT new-file - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20141024-g613f396 - -> [[done]] --[[Joey]] diff --git a/doc/todo/metadata_--batch.mdwn b/doc/todo/metadata_--batch.mdwn deleted file mode 100644 index b65dc3ef5..000000000 --- a/doc/todo/metadata_--batch.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta author=yoh]] - -> [[done]] (using json input) --[[Joey]] diff --git a/doc/todo/metadata_--batch/comment_1_5cfe3b1a2847cfddd46ab6be249a74e4._comment b/doc/todo/metadata_--batch/comment_1_5cfe3b1a2847cfddd46ab6be249a74e4._comment deleted file mode 100644 index 54cbe6fa6..000000000 --- a/doc/todo/metadata_--batch/comment_1_5cfe3b1a2847cfddd46ab6be249a74e4._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-19T19:18:41Z" - content=""" -The metadata command is pretty complex. A batch interface would need to -cover both setting and getting. - -There are four different ways to change a value, so it would probably -make sense for the input to be of the form "file field=value" -or "file field+=value" or "file field-=value" or "file field?=value" - -A field can have multiple values, including "". So, a batch interface -to querying the value would need to handle that in its output. Perhaps -json output? -"""]] diff --git a/doc/todo/metadata_--batch/comment_2_6230fe7d6a7b6156b74b7f4e3641c200._comment b/doc/todo/metadata_--batch/comment_2_6230fe7d6a7b6156b74b7f4e3641c200._comment deleted file mode 100644 index 5b39175a9..000000000 --- a/doc/todo/metadata_--batch/comment_2_6230fe7d6a7b6156b74b7f4e3641c200._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-02-19T20:06:19Z" - content=""" -yes -- json output would probably be the best -I know that other --batch functions do not take json input, but I wonder if it might make sense here as well? smth like {'file': 'filename', 'add-field': {'field1': 'value1'}, 'remove-field': ..., 'add-tag': ['tag1', 'tag2'], 'remove-tag': ['... and so on. -"""]] diff --git a/doc/todo/metadata_--batch/comment_3_23c88eab56628fd2f75aceb21f59992e._comment b/doc/todo/metadata_--batch/comment_3_23c88eab56628fd2f75aceb21f59992e._comment deleted file mode 100644 index 38dcd7d8c..000000000 --- a/doc/todo/metadata_--batch/comment_3_23c88eab56628fd2f75aceb21f59992e._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-02-19T20:47:28Z" - content=""" -See -<http://git-annex.branchable.com/todo/ability_to_set_metadata_from_json/> - -If it does support json input, the simplest interface would be to use the -same json objects for both output and input. - -Both aeson and json are currently dependencies, and either could be used to -parse json input. -"""]] diff --git a/doc/todo/metadata_--batch/comment_4_c72eb16b630b200265e125ebaf7d0d36._comment b/doc/todo/metadata_--batch/comment_4_c72eb16b630b200265e125ebaf7d0d36._comment deleted file mode 100644 index 4cd0f2d34..000000000 --- a/doc/todo/metadata_--batch/comment_4_c72eb16b630b200265e125ebaf7d0d36._comment +++ /dev/null @@ -1,36 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-07-25T17:39:37Z" - content=""" ---batch mode should be usable to get current metadata, set new -metadata, and remove existing metadata. The non-batch metadata command has -different syntaxes for all of these, but it would be good to have a single -interface that handles all three in batch mode. - -It could read a line containing the file or key, with any metadata -fields that should be changed: - - {"file":"foo"} - {"file":"foo","author":["bar"]} - {"key":"SHA...","author":[]} - -And reply with *all* the metadata, in nearly the same format: - - {"file":"foo","key":"SHA...","author":["bar"],lastchanged:["date"],"success":true} - -And that reply could in turn be edited and fed back in to change the -metadata. - ----- - -There's a DRY problem here because there's the current JSON generator code, -and I'd have to add an Aeson parser to parse the JSON input. But, Aeson -parsers also automatically have a matching generator, which is guaranteed -to generate code that the parser can parse. - -So, it would be nice to use the Aeson JSON generator, instead of the -current one, but that can only be done if the JSON is formatted the same, -or close enough that nothing currently consuming `metadata --json` will -break. -"""]] diff --git a/doc/todo/operate_on_branch_contents.mdwn b/doc/todo/operate_on_branch_contents.mdwn deleted file mode 100644 index 533e1ab87..000000000 --- a/doc/todo/operate_on_branch_contents.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -Currently, commands can operate on specific files in the working tree, -or on all known keys, or on a specific key. It would be useful to have -something like `--branch foo` which would operate on the files present in -the specified branch. - -For example, this would be useful in bare repos to fsck only the master -branch, and not all versions of all keys. - -It might be worth allowing a full refspec, so that eg `refs/remotes/*/master` -or `refs/tags/*` can be operated on. --[[Joey]] - -> This should be pretty easy to implement, using `git ls-tree` -> to enumerate the contents of the ref. -> -> The wrinkle is that for --all, the name of each key is shown as it's -> operated on. But in this case, we want to instead display something like -> "ref:filename". -> -> So, every command that supports --branch (which probably -> should be all the ones currently supporting --all) will need to be -> modified, to be provided some new data type that is not FilePath to a -> work tree file, but something to display while operating on an item. -> -> Not a hard change to make, but an extensive one. --[[Joey]] - ->> I've implemented the first part of this, so --branch works ->> but the name of the key is shown, rather than the file from the branch. ->> --[[Joey]] - ->>> All [[done]] now. --[[Joey]] diff --git a/doc/todo/optimise_git-annex_merge.mdwn b/doc/todo/optimise_git-annex_merge.mdwn deleted file mode 100644 index ff2da3209..000000000 --- a/doc/todo/optimise_git-annex_merge.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -Typically `git-annex merge` is fast, but it could still be sped up. - -`git-annex merge` runs `git-hash-object` once per file that needs to be -merged. Elsewhere in git-annex, `git-hash-object` is used in a faster mode, -reading files from disk via `--stdin-paths`. But here, the data is not -in raw files on disk, and I doubt writing them is the best approach. -Instead, I'd like a way to stream multiple objects into git using stdin. -Sometime, should look at either extending git-hash-object to support that, -or possibly look at using git-fast-import instead. - -> Well, I went with git hash-object --stdin-paths despite it needing to read from -> temp files. --[[Joey]] - ---- - -`git-annex merge` also runs `git show` once per file that needs to be -merged. This could be reduced to a single call to `git-cat-file --batch`, -There is already a Git.CatFile library that can do this easily. --[[Joey]] - -> This is now done, part above remains todo. --[[Joey]] - ---- - -Merging used to use memory proportional to the size of the diff. It now -streams data, running in constant space. This probably sped it up a lot, -as there's much less allocation and GC action. --[[Joey]] - -[[done]] diff --git a/doc/todo/parallel_get.mdwn b/doc/todo/parallel_get.mdwn deleted file mode 100644 index fb3f8d098..000000000 --- a/doc/todo/parallel_get.mdwn +++ /dev/null @@ -1,85 +0,0 @@ -Wish: `git annex get [files] -jN` should run up to N downloads of files -concurrently. - -This can already be done by just starting up N separate git-annex -processes all trying to get the same files. They'll coordinate themselves -to avoid downloading the same file twice. - -But, the output of concurrent git annex get's in a single teminal is a -mess. - -It would be nice to have something similar to docker's output when fetching -layers of an image. Something like: - - get foo1 ok - get foo2 ok - get foo3 -> 5% 100 KiB/s - get foo4 -> 3% 90 KiB/s - get foo5 -> 20% 1 MiB/s - -Where the bottom N lines are progress displays for the downloads that are -currently in progress. When a download finishes, it can scroll up the -screen with "ok". - - get foo1 ok - get foo2 ok - get foo5 ok - get foo3 -> 5% 100 KiB/s - get foo4 -> 3% 90 KiB/s - get foo6 -> 0% 110 Kib/S - -This display could perhaps be generalized for other concurrent actions. -For example, drop: - - drop foo1 ok - drop foo2 failed - Not enough copies ... - drop foo3 -> (checking r1...) - drop foo4 -> (checking r2...) - -But, do get first. - -Pain points: - -1. Currently, git-annex lets tools like rsync and wget display their own - progress. This makes sense for the single-file at a time get, because - rsync can display better output than just a percentage. (This is especially - the case with aria2c for torrents, which displays seeder/leecher info in - addition to percentage.) - - But in multi-get mode, the progress display would be simplified. git-annex - can already get percent done information, either as reported by individiual - backends, or by falling back to polling the file as it's downloaded. - -2. The mechanics of updating the screen for a multi-line progress output - require some terminal handling code. Using eg, curses, in a mode that - doesn't take over the whole screen display, but just moves the cursor - up to the line for the progress that needs updating and redraws that - line. Doing this portably is probably going to be a pain, especially - I have no idea if it can be done on Windows. - - An alternative would be a display more like apt uses for concurrent - downloads, all on one line: - - get foo1 ok - get foo2 ok - get [foo3 -> 5% 100 KiB/s] [foo4 -> 3% 90 KiB/s] [foo5 -> 20% 1 MiB/s] - - The problem with that is it has to avoid scrolling off the right - side, so it probably has to truncate the line. Since filenames - are often longer than "fooN", it probably has to elipsise the filename. - This approach is just not as flexible or nice in general. - -See also: [[parallel_possibilities]] - -> I am looking at using the ascii-progress library for this. -> It has nice support for multiple progress bars, and is portable. -> I have filed 7 issues on it, around 4 of which need to get fixed before -> it's suitable for git-annex to use.. --[[Joey]] - ->> `git annex get -JN` works now, but lacks any progress display. ->> Waiting on some updates to ascii-progress. --[[Joey]] - ->>> Wrote concurrent-output; [[done]] --[[Joey]] - -[[!meta author=yoh]] diff --git a/doc/todo/parallel_get/comment_1_5b7517214148731f81be6e61233ce13c._comment b/doc/todo/parallel_get/comment_1_5b7517214148731f81be6e61233ce13c._comment deleted file mode 100644 index 327e7a315..000000000 --- a/doc/todo/parallel_get/comment_1_5b7517214148731f81be6e61233ce13c._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="spinning wheel" - date="2014-12-22T20:33:44Z" - content=""" -Just tried torrents backend -- it works -- THANKS!!! -But amount of output dumped upon user is somewhat outstanding (I can't even scroll terminal back far enough for 1 file fetch). May be for such backends, where no easy/reasonable way to estimate progress it would be possible at least to have some spinning wheel animation which would react (spin) to any output received from the corresponding downloader/backend? (unless in debug mode in which normal output probably should be shown as well) -"""]] diff --git a/doc/todo/parallel_get/comment_2_c8548608023ef3d95035fe97164c8cd7._comment b/doc/todo/parallel_get/comment_2_c8548608023ef3d95035fe97164c8cd7._comment deleted file mode 100644 index a454de31a..000000000 --- a/doc/todo/parallel_get/comment_2_c8548608023ef3d95035fe97164c8cd7._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="even less verbose" - date="2014-12-23T16:50:36Z" - content=""" -While working on this one, might be worth even reserving even a quieter mode of operation which would e.g. just report a # of already processed files. e.g. - -\"0% done: fetched 100 out of 1,234,567 files\" - -;-) ? -"""]] diff --git a/doc/todo/parallel_get/comment_3_36bfc494c34a6701c4780d13d669ff71._comment b/doc/todo/parallel_get/comment_3_36bfc494c34a6701c4780d13d669ff71._comment deleted file mode 100644 index 0fecfc514..000000000 --- a/doc/todo/parallel_get/comment_3_36bfc494c34a6701c4780d13d669ff71._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="comment 3" - date="2014-12-23T16:52:43Z" - content=""" -actually a similar or exactly the same summary line might be worth appearing in the \"regular\" mode as well to give user better estimate of overall progress. If total size is known, it would also be nice if overall % in size (not just a # of items) was reported -"""]] diff --git a/doc/todo/pass_-S_to_commit-tree.mdwn b/doc/todo/pass_-S_to_commit-tree.mdwn deleted file mode 100644 index ecd7dc70e..000000000 --- a/doc/todo/pass_-S_to_commit-tree.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -In git 2.9.0, commit-tree does not respect commit.gpgsign on its own, -which it used to. - -So, in Git.Branch.commitTree, it needs to check if gpgsign is set, -and pass -S to commit-tree. - -(commit-tree -S works in older versions of git, so this can -be done without version checks.) - ---[[Joey]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog.mdwn b/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog.mdwn deleted file mode 100644 index cb48db344..000000000 --- a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog.mdwn +++ /dev/null @@ -1,147 +0,0 @@ -Hi, -these three patches sort .mailmap to get consistent ordering, add nine -names with proper emails to it, and then there is the third one, which -contains all the joeyh changes. I put them in a separate patch in case -you have other opinions about that. - -I notice you're not a fan of GitHub pull requests, and attachments -wasn't allowed here, so I just paste a `cat 000* >all.patch` here, hope -that's ok. The branches are also available from -<https://github.com/sunny256/git-annex> as the branches "edit-mailmap" -(this version) and "edit-mailmap.wip" (the whole process) in case that's -easier. - -There will be more "useful" patches in the future, have started browsing -"Learn you a Haskell for great good", it's awesome. I'll have to get the -build working first, though. There is some dependency problem: - -[[!format hs """ - -$ make -if [ "cabal " = ./Setup ]; then ghc --make Setup; fi -cabal configure -Resolving dependencies... - -Utility/Exception.hs:25:18: - Could not find module `Control.Monad.Catch' - Perhaps you meant - Control.Monad.CatchIO (from MonadCatchIO-mtl-0.3.0.4) - Control.Monad.Cont (needs flag -package mtl-2.1.1) - Control.Monad.State (needs flag -package mtl-2.1.1) - Use -v to see a list of the files searched for. -make: *** [Build/SysConfig.hs] Error 1 - -"""]] - -Mentioning it just in case you have a quick solution. Have tried to fix -it by summoning cabal in various ways, but no luck yet. The OS used is -Debian GNU/Linux 7.8 (wheezy) on x86_64. - -[[!format sh """ - -From 20317aff9fbb8662aaeda4aa2285f92e728adc58 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Sat, 2 May 2015 17:22:48 +0200 -Subject: [PATCH 1/3] Filter .mailmap through "sort -u" for predictability - ---- - .mailmap | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/.mailmap b/.mailmap -index 275b236..5d51042 100644 ---- a/.mailmap -+++ b/.mailmap -@@ -1,7 +1,7 @@ - Joey Hess <id@joeyh.name> http://joey.kitenet.net/ <joey@web> --Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <http://joeyh.name/@web> -+Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> -+Richard Hartmann <richih@debian.org> https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U <Richard@web> - Yaroslav Halchenko <debian@onerussian.com> - Yaroslav Halchenko <debian@onerussian.com> http://yarikoptic.myopenid.com/ <site-myopenid@web> - Yaroslav Halchenko <debian@onerussian.com> https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY <Yaroslav@web> --Richard Hartmann <richih@debian.org> https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U <Richard@web> --- -2.4.0 - -From b216bfdb3ab65f025e46c7fcdc86db3a3440b0af Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Mon, 4 May 2015 15:36:41 +0200 -Subject: [PATCH 2/3] .mailmap: Add nine more uncontroversial names - -Including only those with a proper email where there is no doubt about -which is the correct one. ---- - .mailmap | 13 +++++++++++++ - 1 file changed, 13 insertions(+) - -diff --git a/.mailmap b/.mailmap -index 5d51042..2dafcea 100644 ---- a/.mailmap -+++ b/.mailmap -@@ -1,7 +1,20 @@ -+Antoine Beaupré <anarcat@koumbit.org> anarcat <anarcat@web> -+Antoine Beaupré <anarcat@koumbit.org> https://id.koumbit.net/anarcat <https://id.koumbit.net/anarcat@web> -+Greg Grossmeier <greg@grossmeier.net> http://grossmeier.net/ <greg@web> -+Jimmy Tang <jtang@tchpc.tcd.ie> jtang <jtang@web> -+Joachim Breitner <mail@joachim-breitner.de> http://www.joachim-breitner.de/ <nomeata@web> - Joey Hess <id@joeyh.name> http://joey.kitenet.net/ <joey@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <http://joeyh.name/@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> -+Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <Johan@web> -+Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <http://johan.kiviniemi.name/@web> -+Nicolas Pouillard <nicolas.pouillard@gmail.com> http://ertai.myopenid.com/ <npouillard@web> -+Peter Simons <simons@cryp.to> Peter Simons <simons@ubuntu-12.04> -+Peter Simons <simons@cryp.to> http://peter-simons.myopenid.com/ <http://peter-simons.myopenid.com/@web> -+Philipp Kern <pkern@debian.org> http://phil.0x539.de/ <Philipp_Kern@web> - Richard Hartmann <richih@debian.org> https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U <Richard@web> - Yaroslav Halchenko <debian@onerussian.com> - Yaroslav Halchenko <debian@onerussian.com> http://yarikoptic.myopenid.com/ <site-myopenid@web> - Yaroslav Halchenko <debian@onerussian.com> https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY <Yaroslav@web> -+Øyvind A. Holm <sunny@sunbase.org> http://sunny256.sunbase.org/ <sunny256@web> -+Øyvind A. Holm <sunny@sunbase.org> https://sunny256.wordpress.com/ <sunny256@web> --- -2.4.0 - -From b730720bf85217051b0bd6414650f3bfd5928edb Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Mon, 4 May 2015 15:46:29 +0200 -Subject: [PATCH 3/3] .mailmap: Add all variations for Joey Hess - ---- - .mailmap | 8 ++++++++ - 1 file changed, 8 insertions(+) - -diff --git a/.mailmap b/.mailmap -index 2dafcea..3013a39 100644 ---- a/.mailmap -+++ b/.mailmap -@@ -3,9 +3,17 @@ Antoine Beaupré <anarcat@koumbit.org> https://id.koumbit.net/anarcat <https://i - Greg Grossmeier <greg@grossmeier.net> http://grossmeier.net/ <greg@web> - Jimmy Tang <jtang@tchpc.tcd.ie> jtang <jtang@web> - Joachim Breitner <mail@joachim-breitner.de> http://www.joachim-breitner.de/ <nomeata@web> -+Joey Hess <id@joeyh.name> Joey Hess <joey@gnu.kitenet.net> -+Joey Hess <id@joeyh.name> Joey Hess <joey@kitenet.net> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@debian.org> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@fischer.debian.org> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@joeyh.name> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@oberon.tam-lin.net> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@oberon.underhill.private> - Joey Hess <id@joeyh.name> http://joey.kitenet.net/ <joey@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <http://joeyh.name/@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> -+Joey Hess <id@joeyh.name> https://www.google.com/accounts/o8/id?id=AItOawmJfIszzreLNvCqzqzvTayA9_9L6gb9RtY <Joey@web> - Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <Johan@web> - Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <http://johan.kiviniemi.name/@web> - Nicolas Pouillard <nicolas.pouillard@gmail.com> http://ertai.myopenid.com/ <npouillard@web> --- -2.4.0 - -"""]] - -> [[merged|done]] --[[Joey]] -> -> Control.Monad.Catch should be provided by the exceptions package, -> which there is a dependency on in the cabal file. However, building -> git-annex on wheezy is not supported anymore. --[[Joey]] diff --git a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog/comment_1_031c5a4afe9453a5b62004c85e7e7192._comment b/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog/comment_1_031c5a4afe9453a5b62004c85e7e7192._comment deleted file mode 100644 index 474c61c1e..000000000 --- a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog/comment_1_031c5a4afe9453a5b62004c85e7e7192._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://sunny256.wordpress.com/" - nickname="sunny256" - subject="Character encoding error" - date="2015-05-06T14:53:50Z" - content=""" -Hm, seems as there are some character encoding problem there, two names (Antoine Beaupré and mine) in the second patch. The infamous 'Ø' strikes again. Just wanted to mention it so the patch doesn't introduce errors. Maybe it's safest to fetch it from GitHub. -"""]] diff --git a/doc/todo/patch__58___Command__47__Unused.hs__58___Change_--unused-refspec_back_to_--used-refspec.mdwn b/doc/todo/patch__58___Command__47__Unused.hs__58___Change_--unused-refspec_back_to_--used-refspec.mdwn deleted file mode 100644 index 87a0428f0..000000000 --- a/doc/todo/patch__58___Command__47__Unused.hs__58___Change_--unused-refspec_back_to_--used-refspec.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -This patch is also available from the "used-refspec-fix" branch at <https://github.com/sunny256/git-annex/>. - -[[!format hs """ - -From e47e743327e519eaa07817c610b08b0e6844ca8e Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Tue, 8 Sep 2015 14:29:25 +0200 -Subject: [PATCH] Command/Unused.hs: Change --unused-refspec back to - --used-refspec - -Fix typo in commit 160d4b9 ("convert Unused, and remove some dead code -for old style option parsing", 2015-07-10), the "git-annex unused ---used-refspec" option was incorrectly changed to --unused-refspec. ---- - Command/Unused.hs | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/Command/Unused.hs b/Command/Unused.hs -index a383d56..4756cda 100644 ---- a/Command/Unused.hs -+++ b/Command/Unused.hs -@@ -53,7 +53,7 @@ optParser _ = UnusedOptions - <> help "remote to check for unused content" - )) - <*> optional (option (eitherReader parseRefSpec) -- ( long "unused-refspec" <> metavar paramRefSpec -+ ( long "used-refspec" <> metavar paramRefSpec - <> help "refs to consider used (default: all branches)" - )) - --- -2.6.0.rc0.24.gec371ff -"""]] - -> applied, thanks! [[done]] --[[Joey]] diff --git a/doc/todo/refactor_shebang_handling_code_for_wider_use.mdwn b/doc/todo/refactor_shebang_handling_code_for_wider_use.mdwn deleted file mode 100644 index c7f7ce6cc..000000000 --- a/doc/todo/refactor_shebang_handling_code_for_wider_use.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -Per: https://github.com/DanielDent/git-annex-remote-rclone/pull/10 - -When launching an external special remote, use the shebang handling code which currently exists elsewhere in git-annex - -[joeyh] """Oh, git-annex already deals with this particular windows nonsense elsewhere. When it needs to run a git hook, it parses it for a shebang. Git for windows does the same. - -So, if you can please open a todo item in git-annex, I can refactor that existing code to be used in more places.""" - -> [[done]] --[[Joey]] diff --git a/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn b/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn deleted file mode 100644 index 504af11b8..000000000 --- a/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -You have noted that somewhere (may be in email), that it might help us to pipeline things if 'add' was returning the key if file was added to the annex. I guess the same could apply to 'addurl' so decided to mark this separate todo - -[[!meta author=yoh]] - -> already done earlier today [[done]] --[[Joey]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev.mdwn b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev.mdwn deleted file mode 100644 index 0b0faea90..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -I'm setting up an Android build environment, and the standalone/android/install-haskell-packages script fails while installing the Magic package. The standalone/android/buildchroot-inchroot package should run `apt-get -y install libmagic-dev` to install this dependency. - -> [[done]] --[[Joey]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_1_daef0416d365b60d36e211adcdb42ffb._comment b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_1_daef0416d365b60d36e211adcdb42ffb._comment deleted file mode 100644 index 9993b6332..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_1_daef0416d365b60d36e211adcdb42ffb._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="comment 1" - date="2016-02-21T05:15:57Z" - content=""" -I got further along in the build process, but cabal couldn't install the \"arm-linux-androideabi-4.8\" versions of `magic` and `terminal-size`. The magic library couldn't be installed because there wasn't an appropriate C library available. The terminal-size library failed with the following compilation error. - -``` -Posix.hsc: In function '_hsc2hs_test11': -Posix.hsc:32:39: error: invalid application of 'sizeof' to incomplete type 'struct winsize' -In file included from /home/builder/.ghc/android-14/arm-linux-androideabi-4.8/sysroot/usr/include/sys/types.h:33:0, - from /home/builder/.ghc/android-14/arm-linux-androideabi-4.8/sysroot/usr/include/unistd.h:33, - from Posix.hsc:21: -Posix.hsc: In function '_hsc2hs_test15': -Posix.hsc:35:48: error: invalid use of undefined type 'struct winsize' -... -``` -"""]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_2_b56653f1c57acf70eb2ed3abb4546844._comment b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_2_b56653f1c57acf70eb2ed3abb4546844._comment deleted file mode 100644 index 4c626bba9..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_2_b56653f1c57acf70eb2ed3abb4546844._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-02-23T14:55:36Z" - content=""" -My android builds include neither magic nor concurrent-output (which is -what's using terminal-size). I don't feel it's worth trying to get -these features working on androd. - -So, I've adjusted install-haskell-packages to disable the flags. - -If you are interested in working on the android port, I'd be very excited -for any help. As you can see, there is much room for improvement in the -build system for it. (It would be nice to rework it to use stack, rather -than the current approach, and using stack would automatically disable -these flags that are not portable.) And of course, there are many other -parts of the android port that need improvement. -"""]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_3_501a89c819d0e1531a8bc6548c837a77._comment b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_3_501a89c819d0e1531a8bc6548c837a77._comment deleted file mode 100644 index 1ffb94cf0..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_3_501a89c819d0e1531a8bc6548c837a77._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="comment 3" - date="2016-02-26T03:56:41Z" - content=""" -It looks like the flag in that change was incorrect. I had to change it to `--flags=\"-magicmime -concurrentoutput\"`. (no hyphen between current and output) After that, I was able to reinstall the libraries. - -I'd be happy to lend a hand, expect more patches! -"""]] diff --git a/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn b/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn deleted file mode 100644 index bb8cbd161..000000000 --- a/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -git merge has recently been made to refuse to merge disconnected histories -unless --allow-unrelated-histories is passed. This will break uses of the -webapp, eg local pairing until git-annex is changed to pass that whenever -it runs `git merge`. - -It could also perhaps break uses of `git annex sync` where a remote with a -disconnected history is added and it's expected to merge with it. Although -in this latter case, it might be argued that the default git behavior has -changed and `git annex sync` should follow suite. - -(Also, any uses of `git pull` currently would need to -be split into a fetch and a merge in order to pass the option to the merge; -but AFAICS, git-annex never uses `git pull`) - ---[[Joey]] - -> [[done]]; used the environment variable -> `GIT_MERGE_ALLOW_UNRELATED_HISTORIES` which will hopefully land in git -> `next` (currently Junio has posted a patch but not even landed it in `pu` -> yet) --[[Joey]] diff --git a/doc/todo/support_path-style_syntax_for_S3_bucket_specification.mdwn b/doc/todo/support_path-style_syntax_for_S3_bucket_specification.mdwn deleted file mode 100644 index 5376d88b1..000000000 --- a/doc/todo/support_path-style_syntax_for_S3_bucket_specification.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -It appears that currently there's no way to use the "path-style" method for accessing S3 buckets (as contrasted [here](http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html) with the "virtual hosted-style" of bucket specification). Would it be possible to add an S3-special-remote configuration parameter to adjust the underlying S3 library's "s3RequestStyle" config parameter? I believe that the "PathStyle" value would be relevant to this specific request, as mentioned in the [S3 library README](https://github.com/aristidb/aws#frequently-asked-questions). - -The virtual-hosted style of bucket specification involves a lot of DNS overhead. In my particular use case, I'm looking at running Ceph with a radosgw with S3 support, and in fact the Ceph documention [specifically indicates](http://docs.ceph.com/docs/master/radosgw/s3/commons/#bucket-and-host-name) a preference for "path-style" bucket specification. - -> [[done]] --[[Joey]] diff --git a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_1_971ab83e58128a60921e19b822323965._comment b/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_1_971ab83e58128a60921e19b822323965._comment deleted file mode 100644 index 3faf2e539..000000000 --- a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_1_971ab83e58128a60921e19b822323965._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-09T19:35:10Z" - content=""" -Sure, I've added that as requeststyle=path. I have not tested it, so once -you get an updated build let me know if it works. - -(Should be available in the daily linux autobuilds within about an hour.) -"""]] diff --git a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_2_2c8f58124ed35997e2845377af8c6b02._comment b/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_2_2c8f58124ed35997e2845377af8c6b02._comment deleted file mode 100644 index cb82f28e0..000000000 --- a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_2_2c8f58124ed35997e2845377af8c6b02._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="magibney@908c3d4677b9e87e203538d4d5e8c296255749a0" - nickname="magibney" - subject="comment 2" - date="2016-02-09T21:51:17Z" - content=""" -Just tested successfully (initremote, copy --to, get) in the daily linux autobuild. Fantastic, thank you so much, and thank you for all your work on git-annex! -"""]] diff --git a/doc/todo/unwanted_repository_version_upgrades.mdwn b/doc/todo/unwanted_repository_version_upgrades.mdwn deleted file mode 100644 index 88468ec6f..000000000 --- a/doc/todo/unwanted_repository_version_upgrades.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -Is it possible to freeze or peg repositories at a particular version, or to prevent automatic repository version upgrades? Is it possible to "downgrade" a repository? - -### Please describe the problem. - -We have a number of repositories on a shared file server. These repositories are accessed by multiple machines. Some of these repositories appear to have gotten upgraded and are now unusable on machines running older versions of git-annex. - -We're getting this message: -[[!format sh """ -user@system:/path/to/repository$ git annex status -git-annex: Repository version 5 is not supported. Upgrade git-annex. -"""]] - -The machine experiencing the problem is running Debian Wheezy (Stable). -[[!format sh """ -user@system:/path/to/repository$ git version -git version 1.7.10.4 -user@system:/path/to/repository$ git annex version -git-annex version: 3.20120629 -local repository version: 5 -default repository version: 3 -supported repository versions: 3 -upgrade supported from repository versions: 0 1 2 -"""]] - -I'm guessing that one of the machines with access to this repository was running a newer version of git-annex, and that the repository was upgraded in the course of some action. - -> I took this onboard with v6; upgrade to it is currently optional and will -> only become the default once enough years have passed that it's -> reasonable to assume most people have git-annex 6.x installed. -> -> I think at this point it's reasonable to assume most people have -> git-annex 5.x installed, so there's no point in trying to change to v3 to -> v5 forced upgrade at this point. So, [[done]] --[[Joey]] diff --git a/doc/todo/unwanted_repository_version_upgrades/comment_1_48f71865b65db4574a10e5c32ee22197._comment b/doc/todo/unwanted_repository_version_upgrades/comment_1_48f71865b65db4574a10e5c32ee22197._comment deleted file mode 100644 index 2eee18f1a..000000000 --- a/doc/todo/unwanted_repository_version_upgrades/comment_1_48f71865b65db4574a10e5c32ee22197._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 1" - date="2014-06-04T18:14:19Z" - content=""" -If your repository is not using direct mode, it's completely safe to edit .git/config and set the version back to 3. There is no change between 3 and 5 for indirect mode repositories. - -Unfortunately, using git-annex version 5 will automatically upgrade the repository to 5 again. In general, I only want git-annex to support one version at a time, to avoid complicating the code. I did try leaving the indirect mode repositories at v3, but that didn't work out (some details in [[!commit b1d7474c1d713a5b422948178abb4e5f39e85096]]). - -I kind of think that part of the problem is that you're using git-annex repositories accessed via a file server. If your server had git-annex installed on it and the clients talked to it only by sshing in and running git-annex-shell, it would not matter if the clients had a newer version, because they'd never access the central repository directly. -"""]] diff --git a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock.mdwn b/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock.mdwn deleted file mode 100644 index d9e9f79ba..000000000 --- a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -I might be wrong but given the observation that adjust --unlock took 26.04s user 33.95s system 31% cpu 3:12.36 total to finish operation on an annex (on smaug, btrfs filesystem) with a relatively small (~400) number of relatively large files, I guess no reflink copying was done. - -[[!meta author="yoh"]] - -> [[dup|done]] --[[Joey]] diff --git a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock/comment_1_1663a02563e147d53ed57e58ef7fb9da._comment b/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock/comment_1_1663a02563e147d53ed57e58ef7fb9da._comment deleted file mode 100644 index bdaa128e2..000000000 --- a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock/comment_1_1663a02563e147d53ed57e58ef7fb9da._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-06-09T19:44:14Z" - content=""" -Git's smudge interface requires git-annex to output the content to stdout; -git writes it to the file. So, git-annex does not have an opportunity to -efficiently copy the file. - -(All file copies in git-annex use cp --reflink) - -My proposed extended smudge interface at -<http://thread.gmane.org/gmane.comp.version-control.git/294425> -lets the smudge filter write the file to disk, and then git-annex could -use more efficient methods. Since this is already discussed in -[[todo/smudge]] I think I'll close this bug report as a duplicate. -"""]] diff --git a/doc/todo/use_inode_cache_in_unlocked_files.mdwn b/doc/todo/use_inode_cache_in_unlocked_files.mdwn deleted file mode 100644 index 572d80ec6..000000000 --- a/doc/todo/use_inode_cache_in_unlocked_files.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -When using git annex unlock, followed by git annex add, it currently -checksums files, even if the file has not changed. - -Direct mode has a better approach for this: The inode cache can pretty -reliably detect if a file has been modified. So, `unlock` could note -a file's inode cache info, and then `add` could check if a file's inode -cache is unchanged, and rather than re-checksum it, just perform a fast -`lock`. - -Question: How would `add` know what key's inode cache to look at? Seems it -would need to either check the git branch (as direct mode does, but this is -rather slow and would slow down `add` in the more common case of adding -lots of new files), or use a yet-unimplemented [[design/caching_database]]. -Or, the inode cache could be stored in a map with the work tree filename, -but that diverges from how direct mode uses inode caches. - -Observation: Using the inode cache info to detect changes is not perfect; -if a file is modified without changing its size or mtime, the inode cache -won't be able to tell it's changed. This is unlikely, but possible. In -direct mode, the worst that can happen in this case is probably that a -modified file doesn't get added and committed. But, using the inode cache -for unlocked files would result in any such modified versions being thrown -away when the file is added, which is much more data lossy.. - -> This bug was regarding v5 unlock/lock. In v6 mode, locking a -> file doesn't need to rechecksum it; the key is pulled out of the -> associated files database, and the inode cache is used to detect if the -> unlocked file has been modified and so avoid data loss. -> -> So, this is [[done]] but only for v6 mode. I don't think I want to -> backport it to v5 mode though; it fell out naturally as a consequence of -> v6 mode, but to support it in v5 mode would be a lot more work. -> --[[Joey]] diff --git a/doc/todo/use_inode_cache_in_unlocked_files/comment_1_b13f66eb9840d26fc34b967f5c857b9d._comment b/doc/todo/use_inode_cache_in_unlocked_files/comment_1_b13f66eb9840d26fc34b967f5c857b9d._comment deleted file mode 100644 index 282f27de6..000000000 --- a/doc/todo/use_inode_cache_in_unlocked_files/comment_1_b13f66eb9840d26fc34b967f5c857b9d._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="explicit arguments?" - date="2015-07-06T16:01:47Z" - content=""" -just a suggestion (yet to comprehend full idea here): might be worth making it less magical, e.g. expanding \"add\" with two options: - --u (similar to git) would check only known to git files --a would also automatically add new files - -So I could just \"git annex add -au .\" to commit all the changes in files which happened to be created or modified, without penalty of checksumming all the files. -"""]] diff --git a/doc/todo/use_inode_cache_in_unlocked_files/comment_2_bc288991fa9e235695252b09bc82537e._comment b/doc/todo/use_inode_cache_in_unlocked_files/comment_2_bc288991fa9e235695252b09bc82537e._comment deleted file mode 100644 index fe026b448..000000000 --- a/doc/todo/use_inode_cache_in_unlocked_files/comment_2_bc288991fa9e235695252b09bc82537e._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-07-06T17:46:16Z" - content=""" -Adding a -u option, and perhaps also one to only add new files, would be -pretty easy to do. Of course you can feed git-ls-files output to git annex -add to accompish the same thing. Does it help with the same use case where -adding unlocked files is slower than desirable? -"""]] diff --git a/doc/todo/whishlist__58___temporary_relinking_to_remotes.mdwn b/doc/todo/whishlist__58___temporary_relinking_to_remotes.mdwn deleted file mode 100644 index 3b1ca70eb..000000000 --- a/doc/todo/whishlist__58___temporary_relinking_to_remotes.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -Imagine the following situation: -You have a directory structure like this: - -`./` -`+--dir1` -`|+--file1 (local)` -`|+--file2 (remote1)` -`|+--file3 (remote2)` - -Now when these files are quite big and you need them in one directory temporarily you would need to use `git annex get dir1` to copy them all over to local. This can take some time. - -I whish we had a command like this: -`git annex getlinks dir1` -where git annex would try to not link to the missing local objects but to the remote ones. So there is no need to copy the data around just to use it for a short time. After you are done you could use `git annex resetlinks dir1` to reset the links to the local objects. - -I know that many specialremotes will not support this without much hassle, but it would be cool to be able to get atleast the links from external drives and maybe ssh remotes via sshfs. -To keep the data consistent there can be a constraint that every action (add, sync, commit or others) first issue a `resetlinks`. - -What do you think of that? - -> Already implemented via the `annex.hardlink` configuration. -> -> I don't think that separate commands/options to control whether or not -> to hard link makes sense, because a repository containing hardlinks -> needs to be set as untrusted to avoid breaking numcopies counting. -> Which is done automatically by git-annex when it detects the repository -> was cloned with `git clone --shared`. -> -> [[done]] -> --[[Joey]] diff --git a/doc/todo/wishlist__58___--all_option_for_sync.mdwn b/doc/todo/wishlist__58___--all_option_for_sync.mdwn deleted file mode 100644 index fd609a091..000000000 --- a/doc/todo/wishlist__58___--all_option_for_sync.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -I wish to preserve all history on the backup drives using standard groups and the `sync` command. Namely, if I do the following - - touch test-of-annex-backup.txt - git annex add test-of-annex-backup.txt - git commit --message='test: Create empty test-of-annex-backup.txt file' - git annex edit test-of-annex-backup.txt - echo "This line creates version 2 of this file" > test-of-annex-backup.txt - git annex add test-of-annex-backup.txt - git commit --message='test: Create version 2 of test-of-annex-backup.txt' - git annex sync --content --all - -I expect to see 2 copies of `test-of-annex-backup.txt` be copied to each accessible annex repository in the `backup` [standard group](http://git-annex.branchable.com/preferred_content/standard_groups/) - -At present, the `backup` standard group prefers unused files, but the `sync` command cannot act on this configuration, since it lacks an `--all` option. This is surprising to me as a user, and appears to contradict the intent of the preferred content, as evinced by the awkward explanation of why it is there in [preferred content](http://git-annex.branchable.com/preferred_content/) - -Please add an `--all` option to the `sync` command - -Thanks - -Andrew - -> Implemented; [[done]]. --[[Joey]] diff --git a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav.mdwn b/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav.mdwn deleted file mode 100644 index 83f75bb93..000000000 --- a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -It would be very nice with an "advanced settings" for jabber and webdav support. - -Currently XMPP fails if you use a google apps account. Since the domain provided in the email is not the same as the XMPP server. - -Same goes for webdav support. If i have my own webdav server somewhere on the internet there is no way to set it up in the assistant. - -[[!tag /design/assistant]] - -> [[done]]; xmpp support has been removed --[[Joey]] diff --git a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav/comment_1_11c7444ab4988c60732af505b52bde3c._comment b/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav/comment_1_11c7444ab4988c60732af505b52bde3c._comment deleted file mode 100644 index 61cd3fc2e..000000000 --- a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav/comment_1_11c7444ab4988c60732af505b52bde3c._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA" - nickname="Tobias" - subject="Hooks too" - date="2013-05-22T10:40:33Z" - content=""" -It would actually be very nice if this could be done with hooks too. - -Especially with the new hook method. - -Take this hook - - mega-hook = /usr/bin/python2 ~/sources/megaannex/megaannex.py - -git-annex could make a request with either the parameter(or environment variable) \"getsettingsobject\" that could return. {\"username\": \"\", \"password\": \"\", \"folder\": \"\"}. - -The point being git-annex can request from the hooks program what settings it takes, and give a web interface to set it. Then store the information in the creds folder(ew ew, that folder is unencrypted, oh well) and pass it to the hook on run. - -The advantage being that users wouldn't have to edit a settings file manually (this is currently also the case for the IMAP special remote, which also requires a settings file). -"""]] diff --git a/doc/todo/wishlist__58___Unix_time_in_git_annex_log.mdwn b/doc/todo/wishlist__58___Unix_time_in_git_annex_log.mdwn deleted file mode 100644 index 27540c088..000000000 --- a/doc/todo/wishlist__58___Unix_time_in_git_annex_log.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -Could `git annex log` show the modification times using the Unix time instead of human-readable timestamps? - -This is an example of the output of `git annex log`: - -``` -+ 2014-10-27 01:00:18 ev-2014.pdf | 50083bd6-7e20-4356-a32f-a1dde07de441 -- penn -``` - -If the timestamp were in Unix time, it would be easier to process in a mechanical way. Unix time would also avoid having to guess what is the correct timezone for the timestamp. - -``` -+ 1414368018 ev-2014.pdf | 50083bd6-7e20-4356-a32f-a1dde07de441 -- penn -``` - -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___Unix_time_in_git_annex_log/comment_1_e13341ff3713716e595f2d2d3ed110d0._comment b/doc/todo/wishlist__58___Unix_time_in_git_annex_log/comment_1_e13341ff3713716e595f2d2d3ed110d0._comment deleted file mode 100644 index 02cd1cca3..000000000 --- a/doc/todo/wishlist__58___Unix_time_in_git_annex_log/comment_1_e13341ff3713716e595f2d2d3ed110d0._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-03-29T18:35:26Z" - content=""" -I don't think that's a good default, but I will add the time zone to the -date displayed. And add a --raw-date option for epoch. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case.mdwn b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case.mdwn deleted file mode 100644 index d53fa56ab..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -We're using git-annex to manage large files as part of a team. - -We have a central repository of large files that everyone grabs from. - -We would like to be able to get the files without updating the `git-annex` branch. This way it doesn't pollute the history with essentially always unreachable locations. - -I think the easiest way would be to just add an option to not update the `git-annex` branch when `annex get` is executed. - -Thoughts? - -> See [[untracked_remotes]] for a todo item that will probably -> be useful in this sitation. Since that describes better what -> this bug report seems to be asking for, I am closing this one. -> [[closed|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_1_5c8812973cf91b046e7fc44d7e86c78e._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_1_5c8812973cf91b046e7fc44d7e86c78e._comment deleted file mode 100644 index 61d82e2ae..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_1_5c8812973cf91b046e7fc44d7e86c78e._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.6.48" - subject="comment 1" - date="2013-07-17T23:23:50Z" - content=""" -I'm interested to hear that your team is using git-annex. - -Have you tried `git config annex.alwayscommit false`? This will avoid committing, and just store the info in a local journal -- so even `git annex fsck` will still work. - -Hmm, perhaps you want to update the branch when running `git annex copy` to put files onto the server, but not when getting them? A switch to disable updating the branch would then make sense. Any use of fsck would notice the inconsistency though, and commit a fix to the git-annex branch -- unless you also used the new switch when running fsck. - -But what happens if someone makes a change, pushes to the server, but forgets to `git annex copy` the file? Everyone would then be left with a missing file that git annex doesn't know where it is. One of the reasons it tracks the locations is so that if necessary you know which repository such a misplaced fail is stored in. And can go track down that person's laptop and apply a cluebat. ;) Do you do something on the server to prevent this scenario? -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_2_f36b6a5b128423211aac91a252ecf85f._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_2_f36b6a5b128423211aac91a252ecf85f._comment deleted file mode 100644 index 3379742d2..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_2_f36b6a5b128423211aac91a252ecf85f._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="http://caust1c.myopenid.com/" - nickname="asbraithwaite" - subject="comment 2" - date="2013-07-17T23:42:25Z" - content=""" -What would happen if we wanted to copy a file to the server -with that set? or even when running `git annex add` -You understood me exactly though. -We'd like to be able to get the files without a commit, but copy them -with a commit of the changes. -The way we operate, if somebody makes a change with regards to -largefiles, they should also add a test for it. -Ideally, the test suite would catch it. That or people would -realize that theres a new big file and send around an email to -see who was trying to a largefile when they couldn't reach it. - -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_3_ad1569b2405acacd2e37f42b82f24c88._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_3_ad1569b2405acacd2e37f42b82f24c88._comment deleted file mode 100644 index 14ab5f65a..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_3_ad1569b2405acacd2e37f42b82f24c88._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.6.48" - subject="comment 3" - date="2013-07-18T00:12:39Z" - content=""" -Actually, when a file is sent to a git repository on the server, it will update the location log on that side. So even if the client has alwayscommit=false, other clients will learn the file has reached the server. - -So that might just work for you. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_4_8aba90150fe178ce9712ad951628f3d6._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_4_8aba90150fe178ce9712ad951628f3d6._comment deleted file mode 100644 index c1f148fdb..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_4_8aba90150fe178ce9712ad951628f3d6._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 4" - date="2013-07-18T18:03:00Z" - content=""" -If you can have developers only add large files on the central server, avoiding using git annex sync and only pulling from git repo should work, I think. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_5_6f42d240e0021f4dfa37146bea3f5d7e._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_5_6f42d240e0021f4dfa37146bea3f5d7e._comment deleted file mode 100644 index aa547d790..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_5_6f42d240e0021f4dfa37146bea3f5d7e._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://caust1c.myopenid.com/" - nickname="asbraithwaite" - subject="comment 5" - date="2013-07-18T21:17:45Z" - content=""" -Wow. This worked better than expected. I'm still trying to understand the implementation (I'm not familiar with Haskell), but there is some magic going on. - -To explain: - -I didn't expect that when I added a file (Locally and to the annex remote) that when somebody else did a pull, git-annex would recognize this and update the working copy to download and include that file. - -I'm not sure if this is intended behavior or not (since I thought all commands had to go through git-annex) but I like it nonetheless. - -Thanks again for the tips! -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_6_5fda455febf728b079f26fe42bf7bcab._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_6_5fda455febf728b079f26fe42bf7bcab._comment deleted file mode 100644 index 3f10e48ad..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_6_5fda455febf728b079f26fe42bf7bcab._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://caust1c.myopenid.com/" - nickname="asbraithwaite" - subject="comment 6" - date="2013-07-18T21:23:58Z" - content=""" -Disregard that. I was testing it with a particular file that didn't exactly play nice. - -Basically, to test this before production I used `dd bs=1024 count=100000 if=/dev/zero of=bigfile`. - -When I did a `git pull`, it showed the symlink as being valid. - -When I changed the command to `dd bs=1024 count=100000 if=/dev/urandom of=bigfile` then it showed the symlink as bad after pulling. - -Weird! -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_7_f1052ab997f1a2cccbabfd1533fc0a59._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_7_f1052ab997f1a2cccbabfd1533fc0a59._comment deleted file mode 100644 index deb25a9ce..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_7_f1052ab997f1a2cccbabfd1533fc0a59._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 7" - date="2013-07-18T21:48:06Z" - content=""" -If you wanted to auto-get files on git pull, you could trying putting git annex get into .git/hooks/post-merge (needs to be marked as executable). -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_8_07804647b6023436878756bd97a23f32._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_8_07804647b6023436878756bd97a23f32._comment deleted file mode 100644 index 4901a2d97..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_8_07804647b6023436878756bd97a23f32._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.140" - subject="comment 8" - date="2013-07-20T20:07:53Z" - content=""" -`dd bs=1024 count=100000 if=/dev/zero of=bigfile` obviously creates the same data each time, so if that same size empty file has previously been in a repository, and the content is still present there, the symlink will automatically point to it when it gets added. In other words, git-annex performs automatic deduplication of file contents, and so it was able to save you a download in this case. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_9_fdc883d3963de8072794f3189742e4e3._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_9_fdc883d3963de8072794f3189742e4e3._comment deleted file mode 100644 index 2287f6935..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_9_fdc883d3963de8072794f3189742e4e3._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="comment 9" - date="2014-01-02T17:25:50Z" - content=""" -I have now implemented a way to mark a remote as readonly. This prevents git-annex from pushing anything to the remote, or modifying it in other ways. - -It seems that in your use case, you might want to avoid git-annex sync pushing the git-annex branch, but still push a branch like master. So far, it's up to you to decide which branches to manually push; readonly disables all pushing. -"""]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync_-m__96__.mdwn b/doc/todo/wishlist__58_____96__git_annex_sync_-m__96__.mdwn deleted file mode 100644 index c83d4db5c..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync_-m__96__.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -Similar to how - - git commit -m 'foo' - -works, if I run - - git annex sync -m 'my hovercraft is full of eels' - -git annex should use that commit message instead of the default ones. That way, I could use [[sync]] directly and not be forced to commit prior to syncing just to make sure I have a useful commit message. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit.mdwn b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit.mdwn deleted file mode 100644 index 381626724..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -I would like to have way, ideally a per-repo-cloud setting which syncs around automatically, to not have `git annex sync` autocommit staged additions. - -I often have quite complex additions with a mix of `git add` and `git annex add` in various stages of completion; running `git annex sync` regularly to see what state the other repos are in should not autocommit if possible. - -Richard - -> [[done]]; extended the annex.autocommit that previously only controlled the -> assistant to also control `git annex sync`. --[[Joey]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_1_fff7cdff9e4bc988139152a799b65c99._comment b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_1_fff7cdff9e4bc988139152a799b65c99._comment deleted file mode 100644 index 1e455c486..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_1_fff7cdff9e4bc988139152a799b65c99._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="92.227.51.179" - subject="comment 1" - date="2014-05-13T20:23:11Z" - content=""" -This could be particularly useful for direct-mode repositories. -"""]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_2_b8dd92d7710a9d194312058e53c38d21._comment b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_2_b8dd92d7710a9d194312058e53c38d21._comment deleted file mode 100644 index cc6cd727b..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_2_b8dd92d7710a9d194312058e53c38d21._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="92.227.51.179" - subject="comment 2" - date="2014-05-13T20:27:38Z" - content=""" -I filed a bug today, which boils down to a related issue. - -http://git-annex.branchable.com/bugs/git_annex_list__47__whereis_and_uncommited_local_changes/ -"""]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_3_206e319f6d7c6b0d1f05af2475a8b335._comment b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_3_206e319f6d7c6b0d1f05af2475a8b335._comment deleted file mode 100644 index 8e2a57e14..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_3_206e319f6d7c6b0d1f05af2475a8b335._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 3" - date="2014-05-16T19:02:08Z" - content=""" -Well, you could: git fetch --all; git annex merge; git push origin -"""]] diff --git a/doc/todo/wishlist__58___add_--symlink_option_to_import.mdwn b/doc/todo/wishlist__58___add_--symlink_option_to_import.mdwn deleted file mode 100644 index c6c5e66a4..000000000 --- a/doc/todo/wishlist__58___add_--symlink_option_to_import.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -Make 'git annex import' for each imported file leave a symlink behind. One may consider this a bit nasty as this introduces symlinks out of the annex. There are also some things careful to consider, link to the annexed symlinks or into the .git/annex/objects store? the first breaks views, the second relies on implementation details. Shall these be absolute (i'd say yes) or relative (won't harm) links etc. But after all it gives a easier migration and possibly even some new usage to manage files outside of the annex. A sister-command for 'export' comes in mind, drop a symlink anywhere. Anyways, when you feel this is a good idea, keep it, otherwise just delete this idea. Thanks ;) - -> Closing as I don't think this is a good idea. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___add_--symlink_option_to_import/comment_1_d5d853142d401b95577567e3eb43495e._comment b/doc/todo/wishlist__58___add_--symlink_option_to_import/comment_1_d5d853142d401b95577567e3eb43495e._comment deleted file mode 100644 index 62d4264cb..000000000 --- a/doc/todo/wishlist__58___add_--symlink_option_to_import/comment_1_d5d853142d401b95577567e3eb43495e._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-15T18:53:47Z" - content=""" -Well, it's easy enough to make symlinks to content in a git-annex repository yourself if you want to. I don't see why this belongs in `git annex import`, which is too complicated already. -"""]] diff --git a/doc/todo/wishlist__58___add_repository_name_to_commit_messages.mdwn b/doc/todo/wishlist__58___add_repository_name_to_commit_messages.mdwn deleted file mode 100644 index 64388d517..000000000 --- a/doc/todo/wishlist__58___add_repository_name_to_commit_messages.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -The commit messages made by git-annex are quite spartan, especially in direct mode where one cannot enter its own commit messages. This means that all that the messages say is "branch created", "git-annex automatic sync", "update", "merging" or little more. - -It would be nice if git-annex could add at least the name of the repository/remote to the commit message. This would make the log a lot more clear, especially when dealing with problems or bugs. - -> The repository name is included now. Also, `git annex sync` can be passed -> --message. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp.mdwn b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp.mdwn deleted file mode 100644 index d53a6117d..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -It could be useful for Linux users and package maintainers to have systemd .service file samples to launch the assistant and the webapp. - -For multi-user systems, we could have a git-annex-webapp@username.service . - -See [systemd documentation](http://www.freedesktop.org/software/systemd/man/systemd.service.html) for informations about those files. -See [archlinux wiki](https://wiki.archlinux.org/index.php/Systemd/Services) for .service examples. - -> [[done]] by Euxane. Thanks! --[[Joey]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_1_b89e90f9a70748c95aaf81740a40b76e._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_1_b89e90f9a70748c95aaf81740a40b76e._comment deleted file mode 100644 index 5e8c8a374..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_1_b89e90f9a70748c95aaf81740a40b76e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="64.134.31.139" - subject="comment 1" - date="2013-10-19T15:33:18Z" - content=""" -Wouldn't this involve running it as root or a dedicated user? Neither is ideal. git-annex already uses .desktop files to auto-start when the user who is using it logs in. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_2_d64361380cb18b98ddb43ada1c9f540a._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_2_d64361380cb18b98ddb43ada1c9f540a._comment deleted file mode 100644 index 5dfeedf37..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_2_d64361380cb18b98ddb43ada1c9f540a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmVE2R20dyfPQIzdi6urVUUAXtD6eeBsr0" - nickname="Benoît" - subject="comment 2" - date="2013-10-19T15:43:36Z" - content=""" - Not necessarily. I have a systemd instance handling my userland services. See [archlinux wiki systemd/User](https://wiki.archlinux.org/index.php/Systemd/User). -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_3_f465134958d858a8be21f252abd78aae._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_3_f465134958d858a8be21f252abd78aae._comment deleted file mode 100644 index f2cadb8b0..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_3_f465134958d858a8be21f252abd78aae._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s" - nickname="Matthias" - subject="User doesn't have to be logged in" - date="2014-11-26T11:29:10Z" - content=""" -my git-annex backend systems don't even have a GUI , much less a logged-in user on them. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_4_268b35928a7a192644d32b6c1d12ecc4._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_4_268b35928a7a192644d32b6c1d12ecc4._comment deleted file mode 100644 index 552b6c189..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_4_268b35928a7a192644d32b6c1d12ecc4._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2014-12-01T22:19:51Z" - content=""" -I don't know what the plans are exactly for the user-mode systemd. - -It seems to me that, if it eventually becomes the session manager for the -desktop, then it will probably grow a generator to handle XDG autostart -.desktop files, and generate systemd services for them. Or, those XDG -autostart files will become deprecated, and programs will ship user-mode -service files. - -In the first case, git-annex doesn't need to include a systemd file, and in -the second case it should. So best it seems to wait and see, or hear from -someone with more information. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_5_94993f36d5644e4181e411e6b4582a43._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_5_94993f36d5644e4181e411e6b4582a43._comment deleted file mode 100644 index 971b449a6..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_5_94993f36d5644e4181e411e6b4582a43._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="Euxane" - avatar="http://cdn.libravatar.org/avatar/e6f48ec6bdf54a71119bcff72e29693f" - subject="comment 5" - date="2016-11-07T11:07:33Z" - content=""" -Syncthing's documentation explains in a nutshell the purpose of system and user services [here](https://docs.syncthing.net/users/autostart.html#using-systemd), and has also some examples of easily adaptable systemd config files for each [here](https://github.com/syncthing/syncthing/tree/master/etc/linux-systemd). - -This provides a common way of managing background services (starting order, auto-restart, …) that I personally prefer over Windows-ish tray-apps. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_6_759185007f20c01fa0f19836e1c3ebbc._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_6_759185007f20c01fa0f19836e1c3ebbc._comment deleted file mode 100644 index 88a6d5723..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_6_759185007f20c01fa0f19836e1c3ebbc._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-11-07T14:35:42Z" - content=""" -git-annex uses standard desktop autostart files to make the assistant -be run at login. They are included in the git-annex package. -Since that works perfectly fine on all linux desktop environments, -I have not bothered with systemd user services for it, -which after all will only work on systemd systems. - -If you want to write some and add a page to -<https://git-annex.branchable.com/tips/> about it, that would be fine. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_7_4515caef5ff53f60c11f2390a98015ef._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_7_4515caef5ff53f60c11f2390a98015ef._comment deleted file mode 100644 index 6f99416f4..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_7_4515caef5ff53f60c11f2390a98015ef._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Euxane" - avatar="http://cdn.libravatar.org/avatar/e6f48ec6bdf54a71119bcff72e29693f" - subject="comment 7" - date="2016-11-08T10:12:05Z" - content=""" -Page added [here](http://git-annex.branchable.com/tips/Systemd_unit/) -"""]] diff --git a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry.mdwn b/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry.mdwn deleted file mode 100644 index 258b82f6a..000000000 --- a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -I keep a database file in git-annex so it stays synced across several machines. My wrapper when accessing it is basically - - git annex sync --content - git annex unlock $database - [access database] - git annex add $database - git annex sync --content - -This works fine except it creates an entry in the log for the database file even if that stays unchanged. I would like an option that just returns to the state before `git annex unlock` if the file has not been changed. Maybe `git annex add --restore-unchanged`? - -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment b/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment deleted file mode 100644 index 3c6df0477..000000000 --- a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment +++ /dev/null @@ -1,33 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-10-12T17:17:12Z" - content=""" -I want to think a little bit about why the location log is updated in this -case before thinking about adding an option. It might make sense to just -not update the location log when it already says the file is present and -only the timestamp is being changed. - -I can think of 2 reasons not to do it: - -1. If it has to query the current state of the log, that might slow down - `git annex add` in the common case, just for this less common case. - - But, updating the log necessarily involves reading it in and outputting - an updated one, so that could probably be finessed. - - (Or, git annex add makes a separate pass to add unlocked files anyway, - so it could only do the query in that case.) - -2. There might be good reasons to want to update the timestamp in the log, - since it's just verified that the content is still present. Maybe. - - But then, fsck doesn't update the timestamps when it does the same kind - of verification. And, the only thing that updates a given repo's entry - in the log is that repo, or another repo that is sending or dropping - content from that repo. - - There don't seem to be any reasons of - distributed consistency to need to worry about updating the timestamp - just to reflect current facts. -"""]] diff --git a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_2_3a3d793b32b8440a8213b38bc83ea94a._comment b/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_2_3a3d793b32b8440a8213b38bc83ea94a._comment deleted file mode 100644 index aeb98f06e..000000000 --- a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_2_3a3d793b32b8440a8213b38bc83ea94a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-10-12T17:37:59Z" - content=""" -Ok, I found a way to implement it with no added overhead in the common -case! -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes.mdwn b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes.mdwn deleted file mode 100644 index b64eb45cc..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -It would be nice to have mimetype support on the `annex.largefiles` configuration directive. F.e. `git config annex.largefiles "not mimetype=text/plain"` - -> [[done]]; Implemented support for mimetype=text/plain or even -> mimetype=text/* -> -> Decided not to add external command test support, at least not for now. -> --[[Joey]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment deleted file mode 100644 index b06008475..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlhE8Xar6m4x3JSILXdm-Y5KhwHTH5qzKQ" - nickname="bruno" - subject="+1" - date="2013-10-14T14:43:11Z" - content=""" -Big +1 for this feature: this would really help configuring annex.largefiles -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_2_975edca7ec87158216d9e106903dfb48._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_2_975edca7ec87158216d9e106903dfb48._comment deleted file mode 100644 index ba88bfb7c..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_2_975edca7ec87158216d9e106903dfb48._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="78.48.163.229" - subject="comment 2" - date="2014-08-02T14:29:26Z" - content=""" -This could be achieved in a generic way by allowing filter binaries in expressions, which are run on the filename and return 0 or 1. -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment deleted file mode 100644 index b2bcd87eb..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 3" - date="2014-08-12T18:58:49Z" - content=""" -I think that to support this, the annex.largefiles preferred content expression would need to be supplimented with checks not available in the normal preferred content language. - -In general, it's important that preferred content expressions be able to be evaluated without having the file content locally available, and it needs to be possible for a repository to evaluate the preferred content of a sibling repository and know if its sibling wants a file. These things would be defeated by any mime-based expressions. So such expressions should only be available in annex.largefiles and not in other preferred content expressions. - -Calling out to `file` or some other external program could work. Although speed can be important. If the assistant is seeing a file frequently change, it's not ideal for it to be repeatedly running `file` on it. There does not seem to be a pure haskell MIME type checking library available at present. -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_4_d06a7c7f1a4fe78af548e2af2fbe8e2b._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_4_d06a7c7f1a4fe78af548e2af2fbe8e2b._comment deleted file mode 100644 index c379c735f..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_4_d06a7c7f1a4fe78af548e2af2fbe8e2b._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-02-03T19:08:38Z" - content=""" -Update: There are now separate parsers for preferred content and -annex.largefiles expressions, so this could be put in only the -annex.largefiles parser. - -I kind of like the idea of letting an external program be run -to test if the file is large. Of course, it would be up to the user to -make the external program fast enough. - -The expression could be something like "checkprogram=foo". Since -expressions have simple word-based tokenization, no parameters -would be able to be passed to the program (except the file to check). - -For getting mime type, the best way seems to be to use -<http://hackage.haskell.org/package/magic>. Using `magicOpen [MagicMimeType]` -I got it to probe mime types for files. - -Since libmagic won't be available everywhere, it would have to be a build flag, -and if a git-annex not built with support for it is fed an expression with -"magic=", it would have to error out when parsing the expression. - -Of course, these options are not mutually exclusive.. -"""]] diff --git a/doc/todo/wishlist__58___do_round_robin_downloading_of_data.mdwn b/doc/todo/wishlist__58___do_round_robin_downloading_of_data.mdwn deleted file mode 100644 index 00777faa2..000000000 --- a/doc/todo/wishlist__58___do_round_robin_downloading_of_data.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -Given that git/config will have information on remotes and maybe costs, it might be a good idea to do a simple round robin selection of remotes to download files where the costs are the same. - -This of course assumes that we like the idea of "parallel" launching and running of curl/rsync processes... - -This wish item is probably only useful for the paranoid people who store more than 1 copy of their data. - -See [[get_round_robin]] --[[Joey]] - -> [[done]], at least for `git annex get -JN` when two remotes have the same -> cost.. diff --git a/doc/todo/wishlist__58___do_round_robin_downloading_of_data/comment_1_460335b0e59ad03871c524f1fe812357._comment b/doc/todo/wishlist__58___do_round_robin_downloading_of_data/comment_1_460335b0e59ad03871c524f1fe812357._comment deleted file mode 100644 index 6a5fd3d53..000000000 --- a/doc/todo/wishlist__58___do_round_robin_downloading_of_data/comment_1_460335b0e59ad03871c524f1fe812357._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-04-03T16:39:35Z" - content=""" -I dunno about parrallel downloads -- eek! -- but there is at least room for improvement of what \"git annex get\" does when there are multiple remotes that have a file, and the one it decides to use is not available, or very slow, or whatever. -"""]] diff --git a/doc/todo/wishlist__58___git_annex_diff.mdwn b/doc/todo/wishlist__58___git_annex_diff.mdwn deleted file mode 100644 index 3af7bef6a..000000000 --- a/doc/todo/wishlist__58___git_annex_diff.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -git diff is not very helpful for annexed files. - -How about a git annex diff command that allows to compare two versions of an annexed file? - -Should be relatively simple, only there would have to be a way to deal with the situation where not both versions are present in the repository. Either abort with a message showing the command you need to run to get the missing version(s). Or even interactively volunteer to get it automatically, asking the user for confirmation. - -Of course you wouldn't want to diff two large files, but with git annex assistant, all files are annexed by default (right?), so this would be useful. - -There might already be a way to easily diff two versions of an annexed file which I'm missing -- in that case please point me to it! :) - -> [[done]]; rather than adding a `git annex diff`, I made git-annex be able to be used as a git diff driver command, -> which in turn can run some third-party external diff driver that does -> some smart handling of binary files. diff --git a/doc/todo/wishlist__58___git_annex_diff/comment_1_16ccf2e1036d9e1a913db81988731b5a._comment b/doc/todo/wishlist__58___git_annex_diff/comment_1_16ccf2e1036d9e1a913db81988731b5a._comment deleted file mode 100644 index 86772e2fd..000000000 --- a/doc/todo/wishlist__58___git_annex_diff/comment_1_16ccf2e1036d9e1a913db81988731b5a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.154" - subject="comment 1" - date="2014-03-18T20:00:16Z" - content=""" -`git diff` is quite flexible; it can use external diff drivers to perform the diff. Someone could write a diff driver that knows about git-annex symlinks, and shows some kind of diff of the file contents (since the files are probably binary, this gets into how to display a diff of different file types..) -"""]] diff --git a/doc/todo/wishlist__58___git_annex_diff/comment_2_2e8324f47b66dce385263e258e94da16._comment b/doc/todo/wishlist__58___git_annex_diff/comment_2_2e8324f47b66dce385263e258e94da16._comment deleted file mode 100644 index 83501b791..000000000 --- a/doc/todo/wishlist__58___git_annex_diff/comment_2_2e8324f47b66dce385263e258e94da16._comment +++ /dev/null @@ -1,32 +0,0 @@ -[[!comment format=mdwn - username="Bram" - ip="81.20.68.186" - subject="Diff of unlocked file" - date="2014-10-14T10:11:04Z" - content=""" -I wrote a little shell script that implements part of this request. It shows the diff between an unlocked file and its locked version (i.e. the current edits that have not yet been annexed). -This only works in non-direct mode, and obviously with 'diffable' content only. - -Usage is simple, the only parameter it requires is the unlocked filename. - - #!/bin/bash - - DIFF=\"diff\" - FILE=\"$1\" - KEY=$(git annex lookupkey \"$FILE\") - - GITPATH=\"$(git rev-parse --show-toplevel)/.git\" - ANNEXPATH=$GITPATH/annex/objects/$(git annex examinekey --format='${hashdirmixed}${key}/${key}' \"$KEY\") - - if [ -L \"$FILE\" ]; then - echo \"$FILE is not unlocked.\" > /dev/stderr - else - if [ -r \"$ANNEXPATH\" ]; then - $DIFF \"$ANNEXPATH\" \"$FILE\" - else - echo \"Cannot find $ANNEXPATH\" > /dev/stderr - exit 1 - fi - exit 1 - fi -"""]] diff --git a/doc/todo/wishlist__58___git_annex_info_._also_return_numcopies_setting.mdwn b/doc/todo/wishlist__58___git_annex_info_._also_return_numcopies_setting.mdwn deleted file mode 100644 index ac29c169f..000000000 --- a/doc/todo/wishlist__58___git_annex_info_._also_return_numcopies_setting.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -The stats produced by `git annex info .` are nice but I often find myself separately looking up the actual numcopies set value. Can this also be included in the report please? - -> There is not necessarily one single numcopies setting; gitattributes -> can configure different numcopies for different files. -> -> The numcopies stats in the report are reported as plus or -> minus relative to the numcopies setting. Using a relative number like -> that, it can eliminate the complexity of which files have which -> numcompies setting. - -<pre> -numcopies stats: - numcopies +0: 27 - numcopies +1: 43 - numcopies +2: 1 -</pre> - -> What could be added is a summary of the absolute number of copies -> that exist of files, without taking the numcopies configuration -> into account. - -<pre> -absolute number of copies: - 1 copy: 47 - 2 copies: 23 - 3 copies: 1 -</pre> - -> It turns out you can already get this display though! -> Just use `git annex info . --numcopies=0`. - -<pre> -numcopies stats: - numcopies +1: 47 - numcopies +2: 23 - numcopies +3: 1 -</pre> - -> So, in this mode, it's showing the number of copies that exist of files, -> relative to numcopies, which is forced to be 0. So, there are 47 files -> with 1 copy, 23 with 2 copies, and 1 with 3 copies. -> -> I think I've convinced myself no changes need to be made! [[done]] -> --[[Joey]] diff --git a/doc/todo/wishlist__58___git_annex_info_UUID.mdwn b/doc/todo/wishlist__58___git_annex_info_UUID.mdwn deleted file mode 100644 index 5b9633e18..000000000 --- a/doc/todo/wishlist__58___git_annex_info_UUID.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -All repos contain some level of information about all other tracked repositories. -It would be nice if I could see that info, preferably with a timestamp telling me when the last sync happened. - -`git annex info UUID/name` would be suggestion. - - -Thanks, -Richard - -> I left out the stuff that `vicfg` displays. But otherwise -> everything mentioned on this page is [[done]]. --[[Joey]] diff --git a/doc/todo/wishlist__58___git_annex_info_UUID/comment_1_d0d40bfdafed47e9e8ef2f4cd5c8576f._comment b/doc/todo/wishlist__58___git_annex_info_UUID/comment_1_d0d40bfdafed47e9e8ef2f4cd5c8576f._comment deleted file mode 100644 index ab94b7dea..000000000 --- a/doc/todo/wishlist__58___git_annex_info_UUID/comment_1_d0d40bfdafed47e9e8ef2f4cd5c8576f._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="comment 1" - date="2014-01-02T02:16:10Z" - content=""" -git-annex vicfg shows everything (except location tracking info and some remote.log stuff that it would be hard to present in any useful way). - -It would be good to make `git annex info` segment its list of repos by group. The only other information is location tracking info and scheduling, which I think vicfg gives a good overview of. -"""]] diff --git a/doc/todo/wishlist__58___git_annex_info_UUID/comment_2._comment b/doc/todo/wishlist__58___git_annex_info_UUID/comment_2._comment deleted file mode 100644 index 271c88798..000000000 --- a/doc/todo/wishlist__58___git_annex_info_UUID/comment_2._comment +++ /dev/null @@ -1,8 +0,0 @@ -One piece of information that's sometimes useful, but not always, is to get a count of keys present in another remote plus the size of the remote. - -Thus, I could verify that some repos are empty, archive repos have every single file, etc etc. - -I still think that info is best suited for `git annex info name/UUID` as it's more volatile than what `git annex vicfg` displays. - - -Richard diff --git a/doc/todo/wishlist__58___make_git_annex_reinject_work_in_direct_mode.mdwn b/doc/todo/wishlist__58___make_git_annex_reinject_work_in_direct_mode.mdwn deleted file mode 100644 index ffdee8840..000000000 --- a/doc/todo/wishlist__58___make_git_annex_reinject_work_in_direct_mode.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -### Please describe the problem. - -`git annex reinject` refuses to work while in direct mode. - -When in direct mode git annex reinject could simply perform `rm $symlink; mv $file_copy .; git annex add $file`. I prefer having git annex doing that so I am sure I am not messing up (mistakenly adding new files for instance) and everything is properly managed. - -### What version of git-annex are you using? On what operating system? - -git-annex 4.20130516.1 - -~~~~ -$ lsb_release -a -No LSB modules are available. -Distributor ID: Ubuntu -Description: Ubuntu 12.04.2 LTS -Release: 12.04 -Codename: precise -~~~~ - -> [[fixed|done]]. Why did I take so long to do this, it was a trivial 1 -> word change! --[[Joey]] diff --git a/doc/todo/wishlist__58___more_info_in_commit_messages_in_general.mdwn b/doc/todo/wishlist__58___more_info_in_commit_messages_in_general.mdwn deleted file mode 100644 index b5cf88bf8..000000000 --- a/doc/todo/wishlist__58___more_info_in_commit_messages_in_general.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -This is probably an extension of [[wishlist: more info in the standard commit message of `sync`]]: - -It would also help debugging if the default commit messages listed, e.g., the name of all the files modified by that commit (or merge). - -> No, it would not help debugging to put redundant info in commit -> messages. It will only make your repository take up more disk space. -> git log --stat will already show you the files changes by -> any commit. [[wontfix|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___swift_backend.mdwn b/doc/todo/wishlist__58___swift_backend.mdwn deleted file mode 100644 index 6c1cef52f..000000000 --- a/doc/todo/wishlist__58___swift_backend.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -[swift](http://swift.openstack.org/) is the object storage of Openstack. Think S3, but fully open source. As it's backed by rackspace.com, NASA, Dell and several other major players, adoption rates will explode. - -I can provide a test account soonish if need be, else rackspace.com if offering swift storage. Their API gateway lives at https://auth.api.rackspacecloud.com/v1.0 - -Richard - -> Swift is supported by -> <https://github.com/DanielDent/git-annex-remote-rclone> -> -> While I am not opposed to adding support for swift directly to git-annex, -> if a haskell library supporting it should appear, I think that's good -> enough so am calling this [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._comment b/doc/todo/wishlist__58___swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._comment deleted file mode 100644 index 98a998c1c..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" - nickname="Jimmy" - subject="comment 1" - date="2011-05-14T10:04:36Z" - content=""" -I don't suppose this SWIFT api is compatible with the eucalytpus walrus api ? -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._comment b/doc/todo/wishlist__58___swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._comment deleted file mode 100644 index 97863b095..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._comment +++ /dev/null @@ -1,8 +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="2011-05-14T15:00:51Z" - content=""" -It does offer a S3 compability layer, but that is de facto non-functioning as of right now. -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_3_bf8625b909c3a7321cae40e6f145e874._comment b/doc/todo/wishlist__58___swift_backend/comment_3_bf8625b909c3a7321cae40e6f145e874._comment deleted file mode 100644 index 90af10c41..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_3_bf8625b909c3a7321cae40e6f145e874._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://ertai.myopenid.com/" - nickname="npouillard" - subject="+1" - date="2012-09-18T08:52:21Z" - content=""" -OVH (french IT company) is migrating its could storage infrastructure to swift/openstack and the next few weeks. -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_4_4d97d12ddd99834788e94648c8eebef9._comment b/doc/todo/wishlist__58___swift_backend/comment_4_4d97d12ddd99834788e94648c8eebef9._comment deleted file mode 100644 index 21fa52aaf..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_4_4d97d12ddd99834788e94648c8eebef9._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm5Z8wzidsumLYQnHdrVxpCx8vsd9llSlg" - nickname="Emanuele" - subject="comment 4" - date="2013-11-22T15:52:42Z" - content=""" -OVH is offering free accounts with 25GB of storage on their hubiC service: https://hubic.com/en/ - -The API documentation (based on OAuth2 and OpenStack Swift) is available at https://api.hubic.com/ -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_5_1568f726f91d4589aef7ca9fcc3c957d._comment b/doc/todo/wishlist__58___swift_backend/comment_5_1568f726f91d4589aef7ca9fcc3c957d._comment deleted file mode 100644 index 1f0ff9f63..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_5_1568f726f91d4589aef7ca9fcc3c957d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://schnouki.net/" - nickname="Schnouki" - subject="comment 5" - date="2014-02-11T13:38:53Z" - content=""" -FYI, I just published a [special remote for hubiC](https://github.com/Schnouki/git-annex-remote-hubic) that uses the OAuth API for authentication and the SWIFT API for data transfers. Parts of it are specific for hubiC (mostly auth.py), but it should be possible to adapt it to other SWIFT providers as well. -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones.mdwn b/doc/todo/wishlist__58___use_hardlinks_for_local_clones.mdwn deleted file mode 100644 index 4b0694422..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -as far as I know, if you `git clone` locally a git-annex enabled repository, it will not have all the files available. you would need to use `git annex get` and all files would be copied over, wasting a significant amount of space. - -`git-clone` has this `--local` flags which hardlinks objects in `.git/objects`, but also, maybe more interestingly, has a `--shared` option to simply tell git to look in another repo for objects. it seems to me git-annex could leverage those functionalities to avoid file duplication when using local repositories. - -this would be especially useful for [ikiwiki](http://ikiwiki.info/forum/ikiwiki_and_big_files). - -This is a [[wishlist]], but I would also welcome implementation pointers to do this myself, thanks! --[[anarcat]] - -> [[dup|done]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_1_85064fafe472a5bd395d60ce8f7acb56._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_1_85064fafe472a5bd395d60ce8f7acb56._comment deleted file mode 100644 index 4ef5f8414..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_1_85064fafe472a5bd395d60ce8f7acb56._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.220" - subject="comment 1" - date="2013-09-25T17:14:28Z" - content=""" -git-annex uses cp --reflink=auto. So on a filesystem supporting COW file copies, like btrfs, `git annex get` will not use any disk space when getting from the same filesystem. - -I do not like the idea of using hardlinks, because changing the file in one repository would change it in the other, which may not be desired. - -[[union_mounting]] seems to cover this item pretty well, so I will close this as a duplicate. -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_2_ad51dced0c0146e1867830b93b520118._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_2_ad51dced0c0146e1867830b93b520118._comment deleted file mode 100644 index 8476b4220..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_2_ad51dced0c0146e1867830b93b520118._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlUGPPMvAP5Hu0NyNqeRMPC4pANeJNHZ0o" - nickname="Sylvain" - subject="why worry about modifications ?" - date="2014-11-02T17:46:57Z" - content=""" -I don't understand why you worry about having one remote modify the file locally which would get propagated to the other because of the hardlinks. When using checksumming, the repos would be pretty screwed if someone would do that anyways. - -In other words, hardlinking the SHA-checksummed files in .git/annex/objects/ across repos and/or between e.g. a directory remote and a repo would sound a pretty safe and nice optimization to me. I am like the OP, deduplication that does not require brtfs would be a great git annex feature. -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_3_650ded07dfb4c0c598f6ae649e45760b._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_3_650ded07dfb4c0c598f6ae649e45760b._comment deleted file mode 100644 index c2e5fa207..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_3_650ded07dfb4c0c598f6ae649e45760b._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkHTRzRZoBFEDl9XcTfVveW8yO7CTKMg-o" - nickname="Felix" - subject="use your own cp" - date="2015-02-04T14:16:14Z" - content=""" -As a workaround one could use another cp. Maybe something like this: - -Make an executable shell script \"cp\": - - #!/bin/sh - - p1=\"$1\" - shift - - if [ \"$p1\" = '--reflink=auto' ] ; then - p1='--link' - fi - - exec /bin/cp \"$p1\" \"$@\" - - -And put it into a directory which is found before the \"real\" cp: - - export PATH=/path/to/special/cp/:$PATH - - -This \"cp\" makes a hardlink if the '--reflink=auto' parameter is used (1st). - -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_4_e0be9631d7f017dbff5baaabbd0e2d5c._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_4_e0be9631d7f017dbff5baaabbd0e2d5c._comment deleted file mode 100644 index 69dc0a6ce..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_4_e0be9631d7f017dbff5baaabbd0e2d5c._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-02-04T20:03:19Z" - content=""" -No, please don't wrap your `cp`. Forcing git-annex to hard link -files like that can result in data loss, in a number of different -scenarios. And it's generally asking for a broken system. - -Since version 5.20140915, you can "git clone --shared" and -this will set up a clone of a repository in which git-annex will -use hardlinks, in a safe and reliable way. (Notably it marks the clone -as untrusted.) -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_5_90aacf46abdeab34ec8e402613da679d._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_5_90aacf46abdeab34ec8e402613da679d._comment deleted file mode 100644 index 0aa945f6b..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_5_90aacf46abdeab34ec8e402613da679d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="lealanko" - subject="comment 5" - date="2015-09-06T13:26:49Z" - content=""" -> you can \"git clone --shared\" and this will set up a clone of a repository in which git-annex will use hardlinks - -Copying files from the shared origin repository to the clone will create a hardlink, yes. But copying a file from the clone to the origin will still create a physical copy, even though the situation is quite comparable. Could hardlink support be added in this direction as well? -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_6_3971f77ef70c81e4bf94cd0cab1335ac._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_6_3971f77ef70c81e4bf94cd0cab1335ac._comment deleted file mode 100644 index 68794ce0d..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_6_3971f77ef70c81e4bf94cd0cab1335ac._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2015-09-09T18:41:02Z" - content=""" -@lealanko, that's a good point, but a old closed todo item is not the best -place to make such a request. I've opened a new todo item about that. -"""]] diff --git a/doc/todo/wishlist__58__alias_system.mdwn b/doc/todo/wishlist__58__alias_system.mdwn deleted file mode 100644 index 5982a941b..000000000 --- a/doc/todo/wishlist__58__alias_system.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -To implement things like my custom `git annex-push` without the dash, i.e. `git annex push`, an alias system for git-annex would be nice. - -> [[closing|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58__alias_system/comment_1_5afad4b92f9a449d4a82a94ad31feec2._comment b/doc/todo/wishlist__58__alias_system/comment_1_5afad4b92f9a449d4a82a94ad31feec2._comment deleted file mode 100644 index ea8f2bd30..000000000 --- a/doc/todo/wishlist__58__alias_system/comment_1_5afad4b92f9a449d4a82a94ad31feec2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.154" - subject="comment 1" - date="2014-03-18T19:38:19Z" - content=""" -Why not just use git's alias system? It can't make `git annex $foo` aliases, but `git $foo` is shorter anyway.. -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote.mdwn b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote.mdwn deleted file mode 100644 index fe32f7dd7..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -When adding a Remote server through the webapp, it set-up a specific SSH key for later sync. - -However, when the remote has been set-up manually, then later gets the assistant thrown at it, there doesn't appear to be a way to create and deploy such a key. This option could be offered in, e.g., the settings of the repo in the webapp. - -> I feel this is out of scope for the assistant. If the user is able to -> manually add a git remote at the command line, then they should be able -> to configure ssh keys too. I don't want to complicate the assistant with -> a lot of code that tries to deal with half-configured things the user -> manually set up. [[wontfix|done]] --[[Joey]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_1_13737dc99aa877b309f7ebe44ecbafee._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_1_13737dc99aa877b309f7ebe44ecbafee._comment deleted file mode 100644 index d8e3f9337..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_1_13737dc99aa877b309f7ebe44ecbafee._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="comment 1" - date="2014-01-22T13:08:21Z" - content=""" -Hum, fair enough. The webapp might not be the best target. However, there might already be some logic to deploy the key, only not exposed in any UI (web or CLI). - -However, I was under the impression that the key thath git-annex installs remotely is also limited to running git-annex-related tasks (using the command option; I cannot find any example in my configurations at the moment), rather than providing a generic login shell which happens to be used for git-annex. - -The command to run on the remote server did not seem to be trivial (this is what I'm currently bumping against), and I guess there already are a few functions which create and install the authorized_files entry. Maybe providing, e.g., a - - git-annex installkey REMOTE - -command, automating only this key-setup step for the user, would be good? -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_2_06230669218541ac392d674bedd43176._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_2_06230669218541ac392d674bedd43176._comment deleted file mode 100644 index 79ebb5e7c..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_2_06230669218541ac392d674bedd43176._comment +++ /dev/null @@ -1,43 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="Manual solution" - date="2014-06-14T13:59:38Z" - content=""" -My problem stems from the fact that I manually git clone the git-annex repo, which prevents the assistant from creating the setup to use passwordless keys. I just reverse-engineered a working setup to work up what I was missing. I jot it down here for reference, but I guess the bottomline is that if you want to use the assistant with a repo, do it from the start. - -I assume that the client has a clone of the git(-annex) repo of the server. - - client$ git clone server:annex - -Our goal is to let git-annex on the client know that there is a specific key to use when connecting to server that will let it access the git-annex-shell (without a password). We first create the key. - - client:~$ ssh-keygen -t rsa -f ~/.ssh/git-annex/key.git-annex-server-user_annex - [enter an empty passphrase] - -We can then create a virtual SSH host on the client that will use this key to connect to the server, in client:~/.ssh/config: - - # Added manually for git-annex - Host git-annex-server-user_annex - Hostname server - Port 22 - IdentityFile ~/.ssh/git-annex/key.git-annex-server-user_annex - IdentitiesOnly yes - StrictHostKeyChecking yes - -(git-annex seems to use .2F (%2F) to encode path separators in the filenames.) - -The server then needs to know to let the key in, but only for git-annex in the specific folder. This is done in server:.ssh/authorized_keys: - - command=\"GIT_ANNEX_SHELL_DIRECTORY='annex' ~/.ssh/git-annex-shell\",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAA... user@client - -The bit starting with ssh-rsa is the public key created in client:.ssh/git-annex/key.git-annex-server-user_annex.pub at the same time as the private key. - -Finally, all that remains is to change the remote in the client clone to use the virtual SSH host. - - client:~/annex $ git remote set-url origin ssh://user@git-annex-server-user_annex/~/annex - client:~/annex $ git remote set-url origin --push ssh://user@git-annex-server-user_annex/~/annex - -If everything worked, a sync from the client should now work without asking for a password, and starting the assistant will not either. - -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_3_002afd775b82a0ced609c8305803a6c2._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_3_002afd775b82a0ced609c8305803a6c2._comment deleted file mode 100644 index 2515349a6..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_3_002afd775b82a0ced609c8305803a6c2._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="comment 3" - date="2014-06-14T14:15:55Z" - content=""" -After having done that on my first test repo, git-annex could sync, but failed to get the files. - - client:~/annex$ git annex get file - get file (not available) - Try making some of these repositories available: - 12345678-90ab-cdef-1234567890abcdef1 -- user@server:~/annex [origin] - - (Note that these git remotes have annex-ignore set: origin) - failed - git-annex: get: 1 failed - -The note helps: the problem is with the origin remote having annex-ignore set. git-annex therefore ignores it. This is easily fixed by just setting the flag to false. - - client:~/annex$ git config remote.origin.annex-ignore false - -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_4_9e8fdc41fdefcb8be0d6bae7cd4a04a9._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_4_9e8fdc41fdefcb8be0d6bae7cd4a04a9._comment deleted file mode 100644 index 06d16239a..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_4_9e8fdc41fdefcb8be0d6bae7cd4a04a9._comment +++ /dev/null @@ -1,59 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="comment 4" - date="2014-07-09T01:09:33Z" - content=""" -And the ultimate, copy/pastable one, using shell variables: - - export GASERVER=server - export GAUSER=user - export GAPATH=/path - -For the new client (using bash): - - export GASANEPATH=${GAPATH//\//.2F} - export GASSHHOSTNAME=${GASERVER}-${GAUSER}_${GASANEPATH} - ssh-keygen -t rsa -f ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME - cat << EOF >> ~/.ssh/config - # Added manually for git-annex - Host git-annex-$GASSHHOSTNAME - Hostname $GASERVER - IdentityFile ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME - IdentitiesOnly yes - StrictHostKeyChecking yes - EOF - ssh-copy-id -i ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME $GAUSER@$GASERVER - git remote add ${GASERVER/.*/} ssh://${GAUSER}@git-annex-${GASSHHOSTNAME}${GAPATH} - git config remote.${GASERVER/.*/}.annex-ignore false - -After the `ssh-copy-id` stage, the key can be used to get a full session. This -needs to be limited on the server, by prepending the following to the newly -added key in `.ssh/authorized_keys`, replacing `GAPATH` by the value of `$GAPATH`: - - command=\"GIT_ANNEX_SHELL_DIRECTORY='GAPATH' ~/.ssh/git-annex-shell\",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty - -From the client, one can make sure this has been limite properly by trying to log in with the key: - - ssh -i ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME $GAUSER@$GASERVER -o IdentitiesOnly=yes - -It should reply with the `git-annex-shell` helper complaing: - - git-annex-shell: bad parameters - - Usage: git-annex-shell [-c] command [parameters ...] [option ...] - - Plumbing commands: - - commit DIRECTORY commits any staged changes to the git-annex branch - configlist DIRECTORY outputs relevant git configuration - dropkey DIRECTORY KEY ... drops annexed content for specified keys - gcryptsetup DIRECTORY VALUE sets up gcrypt repository - inannex DIRECTORY KEY ... checks if keys are present in the annex - notifychanges DIRECTORY sends notification when git refs are changed - recvkey DIRECTORY KEY runs rsync in server mode to receive content - sendkey DIRECTORY KEY runs rsync in server mode to send content - transferinfo DIRECTORY KEY updates sender on number of bytes of content received - -... and this should be all set. -"""]] diff --git a/doc/todo/xmpp_removal.mdwn b/doc/todo/xmpp_removal.mdwn deleted file mode 100644 index 373c16ca1..000000000 --- a/doc/todo/xmpp_removal.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -I'd like to eventually remove XMPP support from git-annex. --[[Joey]] - -The XMPP feature makes git-annex harder to build (needs a lot of C -libraries), and is increasingly rarely used. - -For over a year, git-annex-shell has been able to notify clients when a -change lands in a git repo on a ssh server. This notification is the main -thing XMPP support was used for. Even users without a ssh server of their -own don't need XMPP for this; the feature is supported by GitLab.com. - -The only other advantages to keeping XMPP support are: - -* Supports peer-to-peer git push over XMPP. Except, this hack has never - worked very reliably, and exposes the git repo to the XMPP server, - and needing an XMPP server is not a pure p2p solution anyway. -* Friend discovery and easy sharing of git repo to friends. - -It would be nice if there were a pure P2P replacement for XMPP, like -telehash. But, can't wait on that forever.. - -XMPP support is already disabled by default in some builds of git-annex, -notably the stack build. It's never worked on Windows. - -The [[no-xmpp]] branch is ready for merging. - -Next step is probably to default the flag to false by default, -except for in a few builds like the Debian package and standalone builds. - -> [[done]] diff --git a/doc/todo/xmpp_removal/comment_1_457f98a4354ad6c17dcfb5eeefb4b11e._comment b/doc/todo/xmpp_removal/comment_1_457f98a4354ad6c17dcfb5eeefb4b11e._comment deleted file mode 100644 index 6f67d3da8..000000000 --- a/doc/todo/xmpp_removal/comment_1_457f98a4354ad6c17dcfb5eeefb4b11e._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="dxld@02c834b220f9ffc0410d37263aa29d9373cc455b" - nickname="dxld" - subject="Fully p2p alternative to XMPP" - date="2015-10-01T17:22:44Z" - content=""" -It looks like no one else has suggested this yet so I guess I'll have to: [Tox](https://tox.chat/) - -Tox is pretty easy to build on all platforms (GNU/Linux, Mac and WinDOS). All the protocol relevant bits are implemented as a single C library (libtoxcore). It supports bulk file transfers and handles all the NAT hole punching nastiness internally AFAIK. - -Thoughts? - -"""]] diff --git a/doc/todo/xmpp_removal/comment_2_1c92cde199612bbd765c818e7b64f944._comment b/doc/todo/xmpp_removal/comment_2_1c92cde199612bbd765c818e7b64f944._comment deleted file mode 100644 index f13386a7f..000000000 --- a/doc/todo/xmpp_removal/comment_2_1c92cde199612bbd765c818e7b64f944._comment +++ /dev/null @@ -1,46 +0,0 @@ -[[!comment format=mdwn - username="Gastlag" - subject="Is xmpp the problem ?" - date="2015-10-30T10:42:06Z" - content=""" -Hello, - -I was wondering why assistant \"is increasingly rarely used\" ? -if you look the different item of the survey http://git-annex-survey.branchable.com/polls/2015/, yes 53% of people said \"I use the assistant, but without XMPP\" - -And \"missing ports\" : - - - \"I'm good -- git-annex runs on my OSes of choice! (43%)\" - - \"Windows (13%)\" - - Android (6%) - -But if you look other anwsers you see - - - \"using with\" : - - by myself (59%) - - by myself so far but I hope to get others using my repository (28%) - -And : - - - \"Pick the operating system which you use git-annex on the most.\" : - - \"Linux (78%)\" - - \"OSX (13%)\" - - -Further more \"blocking problems\" : - - - too hard to install (4%) - - too hard to use (7%) - - not good enough documentation (16%) - - The only use for the assistant would be in combination with a good, native, fully automagic Android version which includes some sort of native UI (16%) - - I use the command line, and **find it difficult to show others** how to use the git-annex assistant (12%) - - The lack of selective file sync (ie, git annex get and git annex drop) is what prevents me from using the Assistant (5%) - -And \"focus\" : - - - make it easier for nontechnical users (25%) - -I think remove xmpp is a bad idea because as you say it's enable \"Friend discovery and easy sharing of git repo to friends.\" and there is already a lot of people who use xmpp and XMPP address are user friendly because close to email adress. And the main problem seems to be that git-annex assistant still too hard to use and not usable on the platform where users are : windows. - -The main problem is that git-annex is still not ready for users. It have too reach other people than \"hardcore linux users\" to be a social tool and remove xmpp may not be the good solution. -"""]] diff --git a/doc/todo/xmpp_removal/comment_3_661be364029ce45db7d6a111b9d65ee7._comment b/doc/todo/xmpp_removal/comment_3_661be364029ce45db7d6a111b9d65ee7._comment deleted file mode 100644 index f17a19869..000000000 --- a/doc/todo/xmpp_removal/comment_3_661be364029ce45db7d6a111b9d65ee7._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="https://id.koumbit.net/anarcat" - subject="re tox" - date="2015-10-30T15:37:09Z" - content=""" -i am not sure the proper replacement for XMPP is tox. First off, Debian privacy folks have [expressed concerns about the actual security of Tox](http://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/Week-of-Mon-20150928/000046.html), which is not a big requirement here, but nevertheless is a question worth adressing. [Pond](https://pond.imperialviolet.org/) and [Ricochet](http://ricochet.im/) are interesting alternatives that are being packaged in Debian (the latter which just entered unstable). - -Furthermore, it seems that XMPP is really a \"patch\", a workaround for NAT issues and, in general, how to share git-annex repositories with users in arbitrary locations. This problem space is more similar to [[todo/Bittorrent-like_features/#index1h1]] than XMPP. Using tox libraries may enable git-annex to share git metadata around, but would it allow git-annex to download actual files from other users through tox? How stable is tox? Last I checked, [tox core don't actually want to make any releases](https://github.com/irungentoo/toxcore/issues/1353), which makes it a much less attractive option because the API can change all the time... - -I have nevertheless added the three tools to [[todo/Bittorrent-like_features/]]. - -Anyways, it seems that XMPP is rarely used and could be removed if it makes maintenance easier: i have never found a good use case for it, personnally: you can usually find a space for a private git repo fairly easily... the problem is sharing the big files! --[[anarcat]] -"""]] |