rename files containing :

This is mostly to let the repo check out on windows w/o using cygwin's git.

But, bash completion is also crap with : , so ..

4 files changed, 42 insertions, 0 deletions

diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment
new file mode 100644
index 000000000..73d4cba5f
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_1_c355878ac49bbb23a4cf82fe685da9ee._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 1"
+ date="2014-07-21T17:28:53Z"
+ content="""
+`find --maxdepth` is a nice optimisation because it can short-circuit when it gets deep in the tree. However, `git annex find` is built on top of `git ls-files --cached`, which has no equivilant way to short-circuit. I am not sure if the format of the index makes it practical for it to get a --maxdepth option (it may need to traverse the whole index, or might be able to short-circuit).
+
+I don't see any point in adding a --matdepth to git-annex if it doesn't actually make it any faster, so getting such a thing into `git ls-files` would be the first step. So, suggest filing a feature request on git.
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment
new file mode 100644
index 000000000..944f36088
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_2_da30a066c4de465fe172ad01057e2380._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlScsufvQF7s8TVTwPd-h_QiP5Hn_i-hrs"
+ nickname="Jason"
+ subject="comment 2"
+ date="2014-07-21T18:37:19Z"
+ content="""
+I see your point, `git ls-files` may still have to walk the whole tree, precluding a speed advantage.
+But I guess the point of what I was saying was more that a way summarize from a high level what is here and what is not would be nice.
+I certainly understand if this is not something you see as worthwhile, but if someone were inclined to write a patch (if ever I find the time) that would add a `--maxdepth` option that would merely summarize the results of `git annex find` would it be something you would be inclined to include in the main repo (providing, of course, that you find the behavior sensible)?
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment
new file mode 100644
index 000000000..8da436e09
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_3_f3eadd6241f5cc2886515b2826dc5cf9._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="108.236.230.124"
+ subject="comment 3"
+ date="2014-07-21T18:40:00Z"
+ content="""
+I think that --maxdepth has a well-defined meaning and this summary option would need to be named something else.
+
+I don't object to the idea of implementing it. However, I don't know that it would be very easy to implement either.
+"""]]
diff --git a/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment
new file mode 100644
index 000000000..6025101e2
--- /dev/null
+++ b/doc/todo/wishlist__58___--maxdepth_option_for_git_annex_find/comment_4_c766c1465407324fc933db78be325b33._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlScsufvQF7s8TVTwPd-h_QiP5Hn_i-hrs"
+ nickname="Jason"
+ subject="good point"
+ date="2014-07-21T19:22:30Z"
+ content="""
+You make another good point `--maxdepth` is vague in this context...
+I guess if we were to decide to come up with a summary option, it will have be named something else, like `--summary-depth`, where the default would be to represent all files of whatever depth, and specifying the option would take the output that would otherwise get from `git annex find <opts>`, truncate the paths to a certain depth, and then make a set thereof (to remove the many dups), that way any directory that had any files that would have been output by `git annex find <opts>`, that would also be at or above a certain depth, would be listed.
+
+I think if I get a chance I'll try to implement something like this.
+
+"""]]