moved all wishlist stuff out of the forum; and closed a bunch of themmoved

all wishlist stuff out of the forum; and closed a bunch of themmoved all
wishlist stuff out of the forum; and closed a bunch of themmoved all
wishlist stuff out of the forum; and closed a bunch of themmoved all
wishlist stuff out of the forum; and closed a bunch of themmoved all
wishlist stuff out of the forum; and closed a bunch of themmoved all
wishlist stuff out of the forum; and closed a bunch of themmoved all
wishlist stuff out of the forum; and closed a bunch of themmoved all
wishlist stuff out of the forum; and closed a bunch of them

doc/todo/wishlist:_GnuPG_options.mdwn

@@ -0,0 +1,14 @@
+[Maybe I should have extented [[this thread|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/]], but I thought I'd make my own since it's perhaps too old.]
+
+I second Justin and [[his idea|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/#comment-e120f8ede0d4cffce17cbf84564211c1]] of having per-remote GnuPG options. I'd even go one step further, and propose the option in the <tt>.gitattributes</tt> file. Indeed by default GnuPG compresses the data before encryption, which doesn't make a lot of sense for git-annex (in my use-case at least); My work-around to save this waste of CPU cycles was to customize my <tt>gpg.conf</tt>, but it's somewhat dirty since I do want to use compression in general.
+
+Here is how I envision the <tt>.git/config</tt>:
+<pre>    <code>[annex]
+        gnupg-options = --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo none
+</code></pre>
+
+And compression could be enabled on say, text files, with a suitable wildcard in the <tt>.gitattributes</tt> file.
+<pre>    <code>*.txt annex.gnupg-options="--s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo zlib"
+</code></pre>
+
+This is something I could probably hack on if you think it'd be a worthwhile option ;-)

doc/todo/wishlist:_GnuPG_options/comment_1_6662e8a71ce20acc62147ef41ecffa50._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-09T01:54:30Z"
+ content="""
+I'd be happy to apply a patch implementing annex.gnupg-options and/or per-remote remote.annex-gnupg-options, and I don't think it would be very hard to do.
+
+The gitattributes thing would be harder to do efficiently, and seems overkill.
+
+
+"""]]

doc/todo/wishlist:_command_options_changes.mdwn

@@ -0,0 +1,17 @@
+Some suggestions for changes to command options:
+
+  * --verbose:
+    * add alternate: -v
+
+  * --from:
+    * replace with: -s $SOURCE || --source=$SOURCE
+
+  * --to:
+    * replace with: -d $DESTINATION || --destination=$DESTINATION
+
+  * --force:
+    * add alternate: -F
+      * "-f" was removed in v0.20110417
+      * since it forces unsafe operations, should be capitalized to reduce chance of accidental usage.
+
+[[done]], see comments

doc/todo/wishlist:_command_options_changes/comment_1_bfba72a696789bf21b2435dea15f967a._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-04-17T23:46:37Z"
+ content="""
+--to and --from seem to have different semantics than --source and --destination. Subtle, but still different.
+
+That being said, I am not sure --from and --to are needed at all. Calling the local repo . and all remotes by their name, they are arguably redundant and removing them would make the syntax a lot prettier; mv and cp don't need them, either.
+
+I am not sure changing syntax at this point is considered good style though personally, I wouldn't mind adapting and would actually prefer it over using --to and --from.
+
+-v and -q would be nice.
+
+
+Richard
+"""]]

doc/todo/wishlist:_command_options_changes/comment_2_f6a637c78c989382e3c22d41b7fb4cc2._comment

@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-19T20:13:10Z"
+ content="""
+Let's see..
+
+* -v is already an alias for --verbose
+
+* I don't find --source and --destination as easy to type or as clear as --from or --to.
+
+* -F is fast, so it cannot be used for --force. And I have no desire to make it easy to mistype a short option and enable --force; it can lose data. 
+
+@richard while it would be possible to support some syntax like \"git annex copy . remote\"; what is it supposed to do if there are local files named foo and bar, and a remotes named foo and bar? Does \"git annex copy foo bar\" copy file foo to remote bar, or file bar from remote foo? I chose to use --from/--to to specify remotes independant of files to avoid such
+ambiguity, which plain old `cp` doesn't have since it's operating entirely on filesystem objects, not both filesystem objects and abstract remotes.
+
+Seems like nothing to do here. [[done]] --[[Joey]]
+"""]]

doc/todo/wishlist:_command_options_changes/comment_3_bf1114533d2895804e531e76eb6b8095._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 3"
+ date="2011-04-20T21:28:06Z"
+ content="""
+Good point. scp fixes this by using a colon, but as colons aren't needed in git-annex remotes' names... -- RichiH
+"""]]

doc/todo/wishlist:_define_remotes_that_must_have_all_files.mdwn

@@ -0,0 +1,18 @@
+I would like to be able to name a few remotes that must retain *all* annexed
+files.  `git-annex fsck` should warn me if any files are missing from those
+remotes, even if `annex.numcopies` has been satisfied by other remotes.
+
+I imagine this could also be useful for bup remotes, but I haven't actually
+looked at those yet.
+
+Based on existing output, this is what a warning message could look like:
+
+	fsck FILE
+		3 of 3 trustworthy copies of FILE exist.
+		FILE is, however, still missing from these required remotes:
+			UUID -- Backup Drive 1
+			UUID -- Backup Drive 2
+		Back it up with git-annex copy.
+	Warning
+
+What do you think?

doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_1_cceccc1a1730ac688d712b81a44e31c3._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-04-23T16:27:13Z"
+ content="""
+Seems to have a scalability problem, what happens when such a repository becomes full?
+
+Another way to accomplish I think the same thing is to pick the repositories that you would include in such a set, and make all other repositories untrusted. And set numcopies as desired. Then git-annex will never remove files from the set of non-untrusted repositories, and fsck will warn if a file is present on only an untrusted repository.
+"""]]

doc/todo/wishlist:_define_remotes_that_must_have_all_files/comment_2_eec848fcf3979c03cbff2b7407c75a7a._comment

@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="gernot"
+ ip="87.79.209.169"
+ subject="comment 2"
+ date="2011-04-24T11:20:05Z"
+ content="""
+Right, I have thought about untrusting all but a few remotes to achieve
+something similar before and I'm sure it would kind of work. It would be more
+of an ugly workaround, however, because I would have to untrust remotes that
+are, in reality, at least semi-trusted. That's why an extra option/attribute
+for that kind of purpose/remote would be nice.
+
+Obviously I didn't see the scalability problem though. Good Point. Maybe I can
+achieve the same thing by writing a log parsing script for myself?
+
+"""]]

doc/todo/wishlist:_do_round_robin_downloading_of_data.mdwn

@@ -0,0 +1,5 @@
+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.

doc/todo/wishlist:_do_round_robin_downloading_of_data/comment_1_460335b0e59ad03871c524f1fe812357._comment

@@ -0,0 +1,8 @@
+[[!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.
+"""]]

doc/todo/wishlist:_git-annex_replicate.mdwn

@@ -0,0 +1,12 @@
+I'd like to be able to do something like the following:
+
+ * Create encrypted git-annex remotes on a couple of semi-trusted machines - ones that have good connectivity, but non-redundant hardware
+ * set numcopies=3
+ * run `git-annex replicate` and have git-annex run the appropriate copy commands to make sure every file is on at least 3 machines
+
+There would also likely be a `git annex rebalance` command which could be used if remotes were added or removed.  If possible, it should copy files between servers directly, rather than proxy through a potentially slow client.
+
+There might be the need to have a 'replication_priority' option for each remote that configures which machines would be preferred.  That way you could set your local server to a high priority to ensure that it is always 1 of the 3 machines used and files are distributed across 2 of the remaining remotes.  Other than priority, other options that might help:
+
+ * maxspace - A self imposed quota per remote machine.  git-annex replicate should try to replicate files first to machines with more free space. maxspace would change the free space calculation to be `min(actual_free_space, maxspace - space_used_by_git_annex)
+ * bandwidth - when replication files, copies should be done between machines with the highest available bandwidth. ( I think this option could be useful for git-annex get in general)

doc/todo/wishlist:_git-annex_replicate/comment_1_9926132ec6052760cdf28518a24e2358._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-04-22T18:27:00Z"
+ content="""
+While having remotes redistribute introduces some obvious security concerns, I might use it.
+
+As remotes support a cost factor already, you can basically implement bandwidth through that.
+"""]]

doc/todo/wishlist:_git-annex_replicate/comment_2_c43932f4194aba8fb2470b18e0817599._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-23T16:22:07Z"
+ content="""
+Besides the cost values, annex.diskreserve was recently added. (But is not available for special remotes.)
+
+I have held off on adding high-level management stuff like this to git-annex, as it's hard to make it generic enough to cover use cases.
+
+A low-level way to accomplish this would be to have a way for `git annex get` and/or `copy` to skip files when `numcopies` is already satisfied. Then cron jobs could be used.
+"""]]

doc/todo/wishlist:_git-annex_replicate/comment_3_c13f4f9c3d5884fc6255fd04feadc2b1._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 3"
+ date="2011-04-23T17:54:42Z"
+ content="""
+Hmm, so it seems there is almost a way to do this already.
+
+I think the one thing that isn't currently possible is to have 'plain' ssh remotes.. basically something just like the directory remote, but able to take a ssh user@host/path url.  something like sshfs could be used to fake this, but for things like fsck you would want to do the sha1 calculations on the remote host.
+"""]]

doc/todo/wishlist:_git-annex_replicate/comment_4_63f24abf086d644dced8b01e1a9948c9._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 4"
+ date="2011-09-19T18:54:46Z"
+ content="""
+git annex get/copy/drop all now support a --auto flag, which makes them only act on files that have not enough or too many copies. This allows for some crude replication; it doesn't take into account which repositories should be filled up more (beyond honoring annex.diskreserve), nor does it try to optimally use bandwidth (beyond honoring configured annex-cost). You have to run it in every repository that you want to participate in the replication, too. But it's probably a Good Enough solution. See [[walkthrough/automatically_managing_content]].
+"""]]

doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults.mdwn

@@ -0,0 +1,17 @@
+I am running centralized git-annex exclusively.
+
+Similar to
+
+    git annex get
+
+I'd like to have a
+
+    git annex put
+
+which would put all files on the default remote(s).
+
+My main reason for not wanting to use copy --to is that I need to specify the remote's name in this case which makes writing a wrapper unnecessarily hard. Also, this would allow
+
+    mr push
+
+to do the right thing all by itself.

doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_1_d5413c8acce308505e4e2bec82fb1261._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-04-04T18:13:46Z"
+ content="""
+This begs the question: What is the default remote? It's probably *not* the same repository that git's master branch is tracking (ie, origin/master). It seems there would have to be an annex.defaultremote setting.
+
+BTW, mr can easily be configured on a per-repo basis so that \"mr push\" copies to somewhere: `push = git push; git annex push wherever`
+"""]]

doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_2_0aa227c85d34dfff4e94febca44abea8._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2011-04-04T20:45:30Z"
+ content="""
+In my case, the remotes are the same, but adding a new option could make sense.
+
+And while I can tell mr what to do explicitly, I would prefer if it did the right thing all by itself. Having to change configs in two separate places is less than ideal.
+
+I am not sure what you mean by `git annex push` as that does not exist. Did you mean copy?
+"""]]

doc/todo/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 1"
+ date="2011-04-04T10:28:01Z"
+ content="""
+Going one step further, a --min-copy could put all files so that numcopies is satisfied. --all could push to all available ones.
+
+To take everything another step further, if it was possible to group remotes, one could act on the groups. \"all\" would be an obvious choice for a group that always exists, everything else would be set up by the user.
+"""]]

doc/todo/wishlist:_git_annex_status.mdwn

@@ -0,0 +1,21 @@
+Ideally, it would look similar to this. And yes, I put "put" in there ;)
+
+    non-annex % git annex status
+    git annex status: error: not a git annex repository
+    annex % git annex status
+    annex object storage version: A
+    annex backend engine: {WORM,SHA512,...}
+    Estimated local annex size: B MiB
+    Estimated total annex size: C MiB
+    Files without file size information in local annex: D
+    Files without file size information in total annex: E
+    Last fsck: datetime
+    Last git pull: datetime - $annex_name
+    Last git push: datetime - $annex_name
+    Last git annex get: datetime - $annex_name
+    Last git annex put: datetime - $annex_name
+    annex %
+
+Datetime could be ISO's YYYY-MM-DDThh:mm:ss or, personal preference, YYYY-MM-DD--hh-mm-ss. I prefer the latter as it's DNS-, tag- and filename-safe which is why I am using it for everything. In a perfect world, ISO would standardize YYYY-MM-DD-T-hh-mm-ss-Z[-SSSSSSSS][--$timezone], but meh.
+
+[[done]]

doc/todo/wishlist:_git_annex_status/comment_1_994bfd12c5d82e08040d6116915c5090._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2011-04-08T07:23:08Z"
+ content="""
++1 for this feature, I've been longing for something like this other than rolling my own perl/shell scripts to parse the outputs of \"git annex whereis .\" to see how many files are on my machine or not.
+"""]]

doc/todo/wishlist:_git_annex_status/comment_2_c2b0ce025805b774dc77ce264a222824._comment

@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="format, respect working directory"
+ date="2011-04-26T12:31:02Z"
+ content="""
+we could include the information about the current directory as well, if the command is not issued in the local git root directory. to avoid large numbers of similar lines, that could look like this:
+
+    Estimated annex size: B MiB (of C MiB; [B/C]%)
+    Estimated annex size in $PWD: B' MiB (of C' MiB; [B'/C']%)
+
+with the percentages being replaced with \"complete\" if really all files are present (and not just many enough for the value to be rounded to 100%).
+"""]]

doc/todo/wishlist:_git_annex_status/comment_3_d1fd70c67243971c96d59e1ffb7ef6e7._comment

@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-05-17T01:15:10Z"
+ content="""
+What a good idea!
+
+150 lines of haskell later, I have this:
+
+<pre>
+# git annex status
+supported backends: WORM SHA1 SHA256 SHA512 SHA224 SHA384 SHA1E SHA256E SHA512E SHA224E SHA384E URL
+supported remote types: git S3 bup directory rsync hook
+local annex keys: 32
+local annex size: 58 megabytes
+total annex keys: 38158
+total annex size: 6 terabytes (but 1632 keys have unknown size)
+backend usage: 
+	SHA1: 1789
+	WORM: 36369
+</pre>
+"""]]

doc/todo/wishlist:_git_annex_status/comment_4_9aeeb83d202dc8fb33ff364b0705ad94._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="status of other remotes?"
+ date="2011-06-15T08:39:24Z"
+ content="""
+using the location tracking information, it should be possible to show the status of other remotes as well. what about supporting `--from=...` or `--all`? (thus, among other things, one could determine if a remote has a complete checkout.)
+"""]]

doc/todo/wishlist:_git_backend_for_git-annex.mdwn

@@ -0,0 +1,9 @@
+Preamble: Obviously, the core feature of git-annex is the ability to keep a subset of files in a local repo. The main trade-off is that you don't get version tracking.
+
+Use case: On my laptop, I might not have enough disk space to store everything. Not so for my main box nor my backup server. And I would _really_ like to have proper version tracking for many of my files. Thus...
+
+Wish: ...why not use git as a version backend? That way, I could just push all my stuff to the central instance(s) and have the best of both worlds. Depending on what backend is used in the local repos, it might make sense to define a list of supported client backends with pre-computed keys.
+
+-- RichiH
+
+[[done]] (bup)

doc/todo/wishlist:_git_backend_for_git-annex/comment_1_04319051fedc583e6c326bb21fcce5a5._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-03-28T16:01:30Z"
+ content="""
+Indeed, see [[todo/add_a_git_backend]], where you and I have already discussed this idea. :)
+
+With the new support for special remotes, which will be used by S3, it would be possible to make such a git repo, using bup, be a special remote. I think it would be pretty easy to implement now. Not a priority for me though.
+"""]]

doc/todo/wishlist:_git_backend_for_git-annex/comment_2_7f529f19a47e10b571f65ab382e97fd5._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 2"
+ date="2011-03-28T17:47:38Z"
+ content="""
+On the plus side, the past me wanted exactly what I had in mind.
+
+On the meh side, I really forgot about this conversation :/
+
+When you say this todo is not a priority, does that mean there's no ETA at all and that it will most likely sleep for a long time? Or the almost usual \"what the heck, I will just wizard it up in two lines of haskell\"?
+
+-- RichiH
+"""]]

doc/todo/wishlist:_git_backend_for_git-annex/comment_3_a077bbad3e4b07cce019eb55a45330e7._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-03-28T20:05:13Z"
+ content="""
+Probably more like 150 lines of haskell. Maybe just 50 lines if the bup repository is required to be on the same computer as the git-annex repository.
+
+Since I do have some repositories where I'd appreciate this level of assurance that data not be lost, it's mostly a matter of me finding a free day.
+"""]]

doc/todo/wishlist:_git_backend_for_git-annex/comment_4_ecca429e12d734b509c671166a676c9d._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
+ nickname="Richard"
+ subject="comment 4"
+ date="2011-03-28T20:45:35Z"
+ content="""
+Personally, I would not mind a requirement to keep a local bup repo. I wouldn't want my data to to unncessarily complex setups, anyway. -- RichiH
+"""]]

doc/todo/wishlist:_git_backend_for_git-annex/comment_5_3459f0b41d818c23c8fb33edb89df634._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2011-04-08T20:59:37Z"
+ content="""
+My estimates were pretty close -- the new bup special remote type took 133 lines of code, and 2 hours to write. A testament to the flexibility of the special remote infrastructure. :)
+"""]]

doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one.mdwn

@@ -0,0 +1,3 @@
+I just added a CIA bot to #vcs-home and tracking commits immediately would be nice. -- RichiH
+
+[[done]]

doc/todo/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one/comment_1_3480b0ec629ef29a151408d869186bf8._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-09-19T18:57:52Z"
+ content="""
+JFTR, pushing now happens automatically from branchable.
+"""]]

doc/todo/wishlist:_simpler_gpg_usage.mdwn

@@ -0,0 +1,12 @@
+This is my current understanding on how one must use gpg with git-annex:
+
+ * Generate(or copy around) a gpg key on every machine that needs to access the encrypted remote.
+ * git annex initremote myremote encryption=KEY for each key that you generated
+
+What I'm trying to figure out is if I can generate a no-passphrase gpg key and commit it to the repository, and have git-annex use that. That way any new clones of the annex automatically have access to any encrypted remotes, without having to do any key management.
+
+I think I can generate a no-passphrase key, but then I still have to manually copy it around to each machine.
+
+I'm not a huge gpg user so part of this is me wanting to avoid having to manage and keeping track of the keys.  This would probably be a non-issue if I used gpg on more machines and was more comfortable with it.
+
+[[done]]

doc/todo/wishlist:_simpler_gpg_usage/comment_1_6923fa6ebc0bbe7d93edb1d01d7c46c5._comment

@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2012-04-29T01:41:57Z"
+ content="""
+Thinking about this more, I think minimally git-annex could support a
+
+    remote.<name>.gpg-options
+
+or
+
+    remote.<name>.gpg-keyring
+
+for options to be passed to gpg.  I'm not sure how automatically setting it to $ANNEX_ROOT/.gnupg/.. would work.
+
+
+I need to read the encryption code to fully understand it, but I also wonder if there is not also a way to just bypass gpg entirely and store the remote-encryption keys locally in plain text.
+"""]]

doc/todo/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2012-04-29T02:39:20Z"
+ content="""
+The encryption uses a symmetric cipher that is stored in the git repository already. It's just stored encrypted to the various gpg keys that have been configured to use it. It would certianly be possible to store the symmetric cipher unencrypted in the git repo. 
+
+I don't see your idea of gpg-options saving any work. It would still require you to do key distribution and run commands in each repo to set it up.
+"""]]

doc/todo/wishlist:_simpler_gpg_usage/comment_3_012f340c8c572fe598fc860c1046dabd._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2012-04-29T02:41:38Z"
+ content="""
+BTW re your Tweet.. I was so happy to be able to use 'c i a' in Crypto.hs. :)
+"""]]

doc/todo/wishlist:_simpler_gpg_usage/comment_4_e0c2a13217b795964f3b630c001661ef._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 4"
+ date="2012-04-29T03:09:03Z"
+ content="""
+I got a good laugh out of it :-)
+
+Storing the key unencrypted would make things easier..  I think at least for my use-cases I don't require another layer of protection on top of the ssh keys that provide access to the encrypted remotes themselves.
+"""]]

doc/todo/wishlist:_simpler_gpg_usage/comment_5_9668b58eb71901e1db8da7db38e068ca._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 5"
+ date="2012-04-29T18:04:13Z"
+ content="""
+encryption=shared is now supported
+"""]]

doc/todo/wishlist:_special_remote_for_sftp_or_rsync.mdwn

@@ -0,0 +1,28 @@
+i think it would be useful to have a fourth kind of [[special_remotes]]
+that connects to a dumb storage using sftp or rsync. this can be emulated
+by using sshfs, but that means lots of round-trips through the system and
+is limited to platforms where sshfs is available.
+
+typical use cases are backups to storate shared between a group of people
+where each user only has limited access (sftp or rsync), when using
+[[special_remotes/bup]] is not an option.
+
+an alternative to implementing yet another special remote would be to have
+some kind of plugin system by which external programs can provide an
+interface to key-value stores (i'd implement the sftp backend myself, but
+haven't learned haskell yet).
+
+> Ask and ye [[shall receive|special_remotes/rsync]].
+> 
+> Sometimes I almost think that a generic configurable special remote that
+> just uses configured shell commands would be useful.. But there's really
+> no comparison with sitting down and writing code tuned to work with
+> a given transport like rsync, when it comes to reliability and taking
+> advantage of its abilities (like resuming). --[[Joey]]
+
+>> big thanks, and bonus points for identical formats, so converting from
+>> directory to rsync is just a matter of changing ``type`` from ``directory``
+>> to ``rsync`` in ``.git-annex/remote.log`` and replacing the directory info
+>> with ``annex-rsyncurl = <host>:<dir>`` in ``.git/config``. --[[chrysn]]
+
+[[done]]

doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_1_6f07d9cc92cf8b4927b3a7d1820c9140._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 1"
+ date="2011-04-28T07:47:38Z"
+ content="""
++1 for a generic user configurable backend that a user can put shell commands in, which has a disclaimer such that if a user hangs themselves with misconfiguration then its their own fault :P
+
+I would love to be able to quickly plugin an irods/sector set of put/get/delete/stat(get info) commands into git-annex to access my private clouds which aren't s3 compatible.
+"""]]

doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_2_84e4414c88ae91c048564a2cdc2d3250._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 2"
+ date="2011-04-28T21:22:03Z"
+ content="""
+Ask and ye shalle receive with an Abbot on top: [[special_remotes/hook]]
+"""]]

doc/todo/wishlist:_special_remote_for_sftp_or_rsync/comment_3_79de7ac44e3c0f0f5691a56d3fb88897._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 3"
+ date="2011-04-29T10:43:31Z"
+ content="""
+Cool!, I just tried adding tahoe-lafs as a remote, and it wasn't too hard.
+"""]]

doc/todo/wishlist:_traffic_accounting_for_git-annex.mdwn

@@ -0,0 +1,3 @@
+As git annex keeps logs about file transfers anyway, it should be relatively easy to add traffic accounting to a repo. That would allow me to monitor how much traffic a given repo generates. As I might end up hosting git-annex repos for a few personal friends, I need/want a way to track the heavy hitters. -- RichiH
+
+PS: If you ever plan to host git-annex similar branchable, this would probably be of interest to you, as well :)

doc/todo/wishlist:alias_system.mdwn

@@ -0,0 +1 @@
+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.