this bug report/rant section has gotten way past diminishing returns, so I am deleting it

Sorry, but I have no interest in arguing about false equivilances such as
comment 23.

23 files changed, 0 insertions, 406 deletions

diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment
deleted file mode 100644
index b95b3ed68..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_10_2c8e8a4f35b392b1cb4dc8104786312d._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="JerSou"
- ip="82.228.88.32"
- subject="comment 10"
- date="2014-09-25T19:27:43Z"
- content="""
-I thought a workaround (but I don't think ultimately use) :
-
->    \# for each git repo :
-
->    mv .git .gitToAnnex
-
->    ln -s .gitToAnnex .git
-
->    echo .gitToAnnex >> .gitignore
-
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_11_b0bd8c98b5a4d67f66f8d64665569490._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_11_b0bd8c98b5a4d67f66f8d64665569490._comment
deleted file mode 100644
index d5cfd7416..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_11_b0bd8c98b5a4d67f66f8d64665569490._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="diafygi"
- subject="comment 11"
- date="2014-11-17T00:54:08Z"
- content="""
-FYI, comment #10's solution doesn't work. Apparently, git-annex also ignores any `.*` directory or file (can't find documentation on this?).
-
-Unfortunately, this a dealbreaker for me. I wanted to use git-annex in my office to sync my work folder (which includes a several git repos) across three computers.
-
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_12_1a0337d1df87898db3d3dadc911bdb38._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_12_1a0337d1df87898db3d3dadc911bdb38._comment
deleted file mode 100644
index 46ab89f21..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_12_1a0337d1df87898db3d3dadc911bdb38._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlkMeBGmu0UM0O8RPxCfmlT2taReMsflWY"
- nickname="Markus"
- subject="comment 12"
- date="2015-01-09T02:09:54Z"
- content="""
-Just adding my voice to the choir: My use case is very similar to Abdó's and git-annex not handling nested git repos is what stopped me from taking it into use sometime ago when I tried it. To me submodules would seem like a good way to handle this, but others here clearly understand git better than I do so I don't have much to add.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_13_4aad55df0c48767e7a0156ad3b38be7b._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_13_4aad55df0c48767e7a0156ad3b38be7b._comment
deleted file mode 100644
index 4877fc5eb..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_13_4aad55df0c48767e7a0156ad3b38be7b._comment
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawlXt6nnNs-3uw61EGYtxr_AVhJqXybwLR8"
- nickname="Bruno"
- subject="Why this limitation ?"
- date="2015-03-25T22:32:46Z"
- content="""
-I do not understand this limitation ! Why the git-annex exclude the **.git** directory. If the .git is not int the root annex, what the problem ?
-
-Effectively, for me, this limitation is a big problem for archive my working directory (it's contain a some .git folders)
-
-more, is there a command to showing the files not in the annex after executing \"git annex add .\" exist ?
-
-Because it's dangerous to believe that the data is in backup, but in the reality they have not saved
-
-It's a pity, that powerful archiver tool is limited by himself, it lacks some features to be perfectly.
-
-This does not affect your excelent work !
-
-Regards
-
-BA
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_14_44a912174bfbe128ae40bef2a5b351c7._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_14_44a912174bfbe128ae40bef2a5b351c7._comment
deleted file mode 100644
index 3b3dafbbf..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_14_44a912174bfbe128ae40bef2a5b351c7._comment
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 14"""
- date="2015-03-26T14:43:11Z"
- content="""
-@Abdó, @Markus, you suggested using submodules. git-annex recently added
-support for submodules, in version 5.20150317. May still be a little
-rough.
-
-@diafygi, `git annex add .` defaults to not adding dotfiles. This is
-documented, and there is a --include-dotfiles switch, or you can explicitly
-list the dotfiles you want to add.
-
-@Bruno, most of your questions are answered by the thread which appears
-before them.
-
-(I think this bug report may be reaching the end of its usefulness, since
-people seem to want to use it to pile on about a bunch of unrelated topics.
-Please keep this on topic.)
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_15_3a82ba46d172972c046f7e4238d9d109._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_15_3a82ba46d172972c046f7e4238d9d109._comment
deleted file mode 100644
index 770cf54eb..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_15_3a82ba46d172972c046f7e4238d9d109._comment
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!comment format=mdwn
- username="badele"
- subject="It's dangerous ignore a folder with same level folder of  a .git directory"
- date="2015-03-27T22:16:13Z"
- content="""
-Hi,
-
-I agree to avoid synchronize directories git, but it's not normal ignore the others directories in the same level of the .git directory. For my case, the .git is the garbage of the old project
-
-It would be nice to show a warning message when the files is ignored. Because it's dangerous, the user dont know if the files isn't archived !
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_16_befb4f82ba2d812766b57cec475b52b5._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_16_befb4f82ba2d812766b57cec475b52b5._comment
deleted file mode 100644
index cfda4f65d..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_16_befb4f82ba2d812766b57cec475b52b5._comment
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 16"""
- date="2015-03-27T22:53:46Z"
- content="""
-@badele, well, it doesn't ignore such a directory.
-
-<pre>
-joey@darkstar:~/tmp/gitrepo>ls -ld subrepo/.git
-drwxr-xr-x 7 joey joey 4096 Mar 27 18:52 subrepo/.git/
-joey@darkstar:~/tmp/gitrepo>mkdir subrepo/dir
-joey@darkstar:~/tmp/gitrepo>touch subrepo/dir/foo
-joey@darkstar:~/tmp/gitrepo>git annex add subrepo/dir/foo
-add subrepo/dir/foo ok
-(recording state in git...)
-</pre>
-
-git and git-annex have the same behavior here..
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_17_0511e8fa74ec3244879a8e5dc05472b3._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_17_0511e8fa74ec3244879a8e5dc05472b3._comment
deleted file mode 100644
index a358c3212..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_17_0511e8fa74ec3244879a8e5dc05472b3._comment
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!comment format=mdwn
- username="badele"
- subject="RE: It's dangerous ignore a folder with same level folder of a .git directory"
- date="2015-03-28T10:24:00Z"
- content="""
-Hi,
-
-Exemple of my project directories:
-
-    + /tmp/git-annex
-        + .git (git-annex git)
-        + project_folder_with_git_folder/.git (garbage git project)
-        + project_folder_with_git_folder/folder1
-            + file1
-        + project_folder_with_git_folder/folder2
-            + file2
-
-
-You can reproduce it
-
-    mkdir -p /tmp/git-annex && cd /tmp/git-annex
-    git init
-    git annex init test
-    cp -R project_folder_with_git_folder .
-    git annex add project_folder_with_git_folder
-    
-No files are added
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment
deleted file mode 100644
index 3cbee238c..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_18_bfc63bcae4724a5a437c3aee51822f7e._comment
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!comment format=mdwn
- username="annex.nrb@0b99c9078ef84fe229eb6f00841028a57dc07612"
- nickname="annex.nrb"
- subject="Should something else, not annex solve the ad hoc git use case?"
- date="2015-11-17T10:02:24Z"
- content="""
-Hi,
-
-I also struggle to be \"motivated by this use case\" here for Git-Annex.  As one who happens to be using git on files inside hiearchies I'd like to annex (without the gits).  Like many others it seems I am searching for a better solution for my ad hoc gits generated locally for myself (a quick way of push cloning to a remote and auto syncing).  For me Git-annex to ignore .git is enough.  I'd rather have the lower complexity 'does one job well' than introduce a separate work around to the git inside git issue. 
-
-http://git-annex.branchable.com/forum/Git_repos_in_git_annex__63__/?updated#comment-9fca5cf31ccfd3d78c78cb65f7672340
-
-http://git-annex.branchable.com/forum/Storing_git_repos_in_git-annex/
-
-I would see the pain coming from attemting to solve the user issue of git corruption: \"I put a git repo where it could get changed outside of git or by two gits concurrently\" and then it did and became a source of confusion.
-
-For me the ideal case is when annex is set up to ignore any .git hierarchy and does not attempt to handle location tracking of (for me ad hoc) git repos inside an annex tree.  As I understand it Annex has to anyway for git, but I would also generalise for other DCVS'.
-
-Sparkleshare may have hit the same 'issue' and talked about renaming the .gits internally for synchronisation.  I am interested to see if that separates sparkeleshare from the \"source of confusion\".
-
-I do use Dropbox where it does simply put its own version control of sorts on top of any git files, leaving the user free to sort out any sources of confusion.  In users eyes it millions of users level bug free, and any problem thus must be their own.
-
-For me, doing it like Dropbox, would not remove the \"source of confusion\", rather encourage it: and being git based, some users may conclude that Annex should handle it better.
-
-Then it would be a big ask of Annex to e.g. find gits and handle them as remotes of each other and auto sync; or lock access to the git bunch of files (a la Clearcase Multisite Master Replica) or detect and bifurcate before any conflict is hit or any other option that is not obvious or easy to me.
-
-It leads me to the view that ignoring .git files and hierarchies is the feature Annex should have.  We handle our ad-hoc gits inside annex tree use case separately.
-
-BR/ Nigel
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_19_02fdc2292389cec04a60a1027b43a088._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_19_02fdc2292389cec04a60a1027b43a088._comment
deleted file mode 100644
index 6f09d12a7..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_19_02fdc2292389cec04a60a1027b43a088._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
- nickname="timothyhobbs"
- subject="comment 19"
- date="2016-04-03T22:30:59Z"
- content="""
-I think that you have underestimated the severity of this problem, as well as failed to see that this is a problem mostly specific to git annex. For tracking changes to code, this usecase does not make much sense. But when using git annex as an advanced CAS filesystem, this limitation is absolutely fatal. I would like to use git annex as a de-duplicating CAS filesystem in order to optimize file transfers across computers and in order to preform de-duplication. Git annex is great for this use case, except for this one fatal flaw. If it is impossible for a \".git\" directory to exist within the git-annex CAS filesystem, then this filesystem is no longer capable of storing arbitrary content. It is impossible, for me to use git annex in a way that is similar to [OSTree](https://wiki.gnome.org/action/show/Projects/OSTree?action=show&redirect=OSTree) for example.
-
-Furthermore, you are wrong when you claim that using git annex to sychronize git repositories is silly. It is no more silly than using git annex to synchronize mercurial or subversion repositories. \"It could cause corruption!\" you say. But if git annex causes corruption, then it cannot be used for synchronization period, and that has nothing to do with git.
-
-I think that this limitation has been one of the few reasons why git annex has not been widely adopted for file synchronization.
-
-I know that you may not be motivated to solve this problem, but I am. As the author of [subuser](subuser.org) I would really like to be able to use git annex as a CAS filesystem similar to OSTree. I am highly motivated to solve this problem, but I do not yet know how. What would be acceptable to you if I were to make a pull request? Would an acceptable solution be to store a list of git repositories in .git/annex/folders-named.git that would map out where the .git folders were supposted to go, and then add those folders to the git by changing their names? AKA, git annex would add a folder named /foo/bar/.annexed-git-ab343ax/ instead of /foo/bar/.git/ and then it would add the line \"/foo/bar/.annexed-git-ab343ax/\" to \".git/annex/folders-named.git\". On checkout git annex could then rename /foo/bar/.annexed-git-ab343ax/ to /foo/bar/.git/ and all would be fine wouldn't it? Do you have any other ideas? Would you accept such a pull request?
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_1_7f54e24c8e721d69bdb1e5a4181641b8._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_1_7f54e24c8e721d69bdb1e5a4181641b8._comment
deleted file mode 100644
index 45eebe10f..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_1_7f54e24c8e721d69bdb1e5a4181641b8._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- nickname="joey"
- subject="comment 1"
- date="2013-05-13T17:36:31Z"
- content="""
-It's a fairly fundamental limitation of git that you cannot check `.git` directories into a git repository.
-
-For backups and sneakernet transfers, `git bundle` is easy to use..
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_20_85dcbf16407c15d4869288c951214aef._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_20_85dcbf16407c15d4869288c951214aef._comment
deleted file mode 100644
index d501298e1..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_20_85dcbf16407c15d4869288c951214aef._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
- nickname="timothyhobbs"
- subject="comment 20"
- date="2016-04-03T23:00:48Z"
- content="""
-It occures to me, that git also cannot store empty folders, which would be a second hurdle when wanting to annex arbitrary file trees. It seems that a similar solution would be at hand, to store paths to empty folders in \".git/annex/empty-folders\". 
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_21_9d3d59bcc6d0381d703308e3e983b341._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_21_9d3d59bcc6d0381d703308e3e983b341._comment
deleted file mode 100644
index e648ce595..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_21_9d3d59bcc6d0381d703308e3e983b341._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 21"""
- date="2016-04-04T19:18:50Z"
- content="""
-It *is* silly to use any version control system to synchronize
-the artifacts of another version control system. By doing so, you throw
-away a perfectly working version control system and have to deal with
-merge conflicts between version A and version B of the version control
-system artifacts. 
-
-Uness you have some magical solution to that merge conflict problem,
-there's no point in further discussion.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_22_5c15f550afc28c122a5050004ce913a1._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_22_5c15f550afc28c122a5050004ce913a1._comment
deleted file mode 100644
index 386ea5e2d..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_22_5c15f550afc28c122a5050004ce913a1._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
- nickname="timothyhobbs"
- subject="comment 22"
- date="2016-04-05T09:19:59Z"
- content="""
-You are right, that the merging picture doesn't work out if you have a \"single entity\" spread across multiple files. Whether that be a version control system like git or mercurial, or a package unpacked by a package manager. I do not plan on doing any merging. I want to esencially store the file trees of Docker images in git annex. What does it even mean to merge two Docker images? Would you expect that when merging an image based on a debian base image which has git installed, with one that has vim installed, that you would get an image with both git and vim? That would be cool, obviously, but I don't think that it is going to happen, and I don't need it to. OSTree doesn't have merging. You cannot merge two Docker images which happen to be based on the same base image...
-
-So while it is true, that tracking multifile entities in git-annex breaks merging, that doesn't make it silly.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_23_c674ce3dcacdaf158f05dab3954cacbc._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_23_c674ce3dcacdaf158f05dab3954cacbc._comment
deleted file mode 100644
index 32fddc008..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_23_c674ce3dcacdaf158f05dab3954cacbc._comment
+++ /dev/null
@@ -1,36 +0,0 @@
-[[!comment format=mdwn
- username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991"
- nickname="timothyhobbs"
- subject="comment 23"
- date="2016-04-06T10:14:30Z"
- content="""
-\"\"\"
-It is silly to use any version control system to synchronize anything but small plain text files. By doing so, you throw away a perfectly working version control system and have to deal with merge conflicts between version A and version B of the non-text files.
-
-Unless you have some magical solution to that merge conflict problem, there's no point in further discussion.
-\"\"\"
-
-Git doesn't know how to merge image files, but you can still track a jpeg using git. Git also doesn't know how to merge open office documents, but you can also track them using git. Indeed, you can even diff them, because first, git let you track them, and then, in true unix fashion, someone wrote a utility to solve the next unsolved problem.
-
-How are you feeling emotionally about this problem with git-annex? It seems to me that you set out to create a generic file synchronization tool. When you launched the kickstarter, you titled it: \"git-annex assistant: Like DropBox, but with your own cloud\" With the subtitle being \"Manage, share, and sync your large files with the power of git and the ease of use of a simple folder you drop files into.\". Do you now feel that this goal is unattainable because of the limitations of git-annex and git? That's OK, if you feel that your goal isn't attainable, but you should say so outright: \"I know I set out to sync arbitrary files, but it turns out that this method just doesn't work for that, so all of you users who come along with that impression from previous advertising, I'm afraid I have to disappoint you. Git-annex still works great for archiving data and media, and it's also good for tracking asset files in an existing git repository, but as a drop box clone its a no-go.\"
-
-Right now, the current presentation is really confusing. I came along, thinking that git annex is INTENDED to be able to synchronize arbitrary data, and then I find you writing in the bugs section, that anyone who wants to do that is silly.
-
-I know that it is hard for a free software developer to work on something alone. I too am a solitary free software developer, and at 25, I can truly say that I set out to follow in your footsteps. I knew of your frugal lifestyle at the beginning of my adult life, and I saw its benefits, that I would not have to compromise my ethics by way of need for money. I asked my parents for financial assistance, and received it. Now, for the past several years, I have tried to work on my own, on free software, my project being [subuser](subuser.org). I find this work style emotionally taxing in a way that I never imagined. For a short while, I worked for [Satoshi labs](http://satoshilabs.com/) on their open source Trezor hardware bitcoin wallet. While I was there, I enjoyed myself immensely. Whenever I ran into a technical problem, I'd just shout across my desk at my boss, and he would run over and we would solve it together. But, due to my English skills, management there started wanting me to fulfill more and more marketing tasks. So I left. Now, when I don't know how to solve some problem, I ruminate over it alone. I search for Google on end, and eventually open up reddit or hackernews, to distract myself from my feelings of failure. I want to write great free software, and improve the world, without ever having to compromise my restrictive ethical beliefs but its just not that easy.
-
-If you feel stressed or overwhelmed by maintaining a huge free software project alone, I can relate to that. If that stress and frustration means that you lash out at your users, I can understand. But I beg you to not let that feeling overshadow your work, and eliminate its value.
-
-I believe that git annex can be useful for the tasks you set out for it to perform. There are some problems:
-
- - it doesn't know how to track file permissions/attributes
- - it cannot track empty folders
- - it cannot track git repositories
-
-But I don't think that you should give up on trying to solve these problems. If you want, I can help you to solve them.
-
-But only if you don't think that I am silly for trying.
-
-----
-
-There is a dream of a post-scarcity society. A society in which free technology provides people what they need. A place where resources are not so scarce as to force people to be unkind of to engage in dishonest marketing. I believe in that dream. But if even we two, who are not driven by want or greed to be unkind to each other, fall to bickering. That saddens me greatly.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_2_6e91bc254f79ccf80d385ba7d35ffa9c._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_2_6e91bc254f79ccf80d385ba7d35ffa9c._comment
deleted file mode 100644
index c3be9b722..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_2_6e91bc254f79ccf80d385ba7d35ffa9c._comment
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c"
- nickname="Justin"
- subject="comment 2"
- date="2013-05-13T17:53:06Z"
- content="""
-Be that as it may, the whole reason git-annex exists is to work around fundamental limitations of git!
-
-The issue is that I don't want to treat a folder which I happen to have applied version control to differently than a folder which happens not to be version controlled (aside from committing to the version-controlled folder, of course!).  Both folders are in my git annex; I shouldn't have to worry about it.  (My whole \"documents\" folder is in git annex, and it contains many small git repositories.)
-
-I guess I could write a script to unbundle and re-bundle on command.  In fact, one could imagine integrating these scripts into git annex somehow.
-
-Is that something you'd consider taking upstream?
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_3_4cf34da6050dd96f94ffc3652aa39715._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_3_4cf34da6050dd96f94ffc3652aa39715._comment
deleted file mode 100644
index f7b07d3b6..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_3_4cf34da6050dd96f94ffc3652aa39715._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- nickname="joey"
- subject="comment 3"
- date="2013-05-13T18:08:36Z"
- content="""
-Well, git-annex is all about working around *1* limitation of git. There are several other limitations that it would be nice to have tools to deal with better, including storing metadata, and this one. I can't take everything on.
-
-I mostly worry about these limitations in the context of naive users using the git-annex assistant for file sync. I have heard that some people put their git repositories in dropbox.
-
-You don't sound at all naive, so I'll suggest another tool I wrote, mr <http://joeyh.name/code/mr>. With mr you can run a single command and operate on all repositories at or under a directory.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_4_cafcc24e98a89f10adaed5e09f75b659._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_4_cafcc24e98a89f10adaed5e09f75b659._comment
deleted file mode 100644
index 6b7c9f33b..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_4_cafcc24e98a89f10adaed5e09f75b659._comment
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
- nickname="Abdó"
- subject="comment 4"
- date="2013-05-28T19:21:57Z"
- content="""
-This \"git is afraid of .git\" issue is the main blocker for finally getting rid of unison. My use case is as follows. Among other things, I have a `~/work` directory infested with little projects versioned by git. I want to sync it between my 3 machines and a cloud server. My current setup involves star-shaped unison syncs to the server. That's not bad, but it has its problems:
- 
-  * unison keeps a file index for every pair of machines (laptop-server, office-server, etc). This means that I end up with 3 identical indexes on the server, indexing the same data. Every time I sync a pair, the server rechecks what has changed to update the corresponding index.
-  * also, every time I add a machine, or my disk explodes and I have to setup a new unison sync from scratch, the server has to reindex everything, which is slow.
-  * unison does not know about the entire history, only the current state of the replicas. This may lead to data loss if I delete something I shouldn't delete and propagate. Only in special cases, for instance when I delete everything in one replica, unison asks before throwing it all out the window.
-  * I sometimes want to sync laptop and desktop through the local network, instead of going through the server. Then I have to be very careful in which order I do the syncs + it adds a couple of new redundant indices.
-
-Now, git annex is not a sync tool. But as a side effect of its `git annex sync` feature, it happens to solve those issues in an elegant way, making it an extremely flexible sync tool, far superior to unison in many aspects!
-
-Still, my `~/work` directory is infested with little git repos, so I can't use git annex on `~/work`. Also, I treat my little git projects as things carrying their own history arround. Sometimes I move them, etc. I don't want to use mr in them, nor keep remotes for all my machines on all my little projects. That removes a lot of the flexibility I'd gain by moving to git annex.
-
-The thing is, I don't understand why this git limitation is fairly fundamental. I've been playing around nesting git repos. When I change the inner `.git` directory to `.bar`, the outer git swallows it all right, and after some playing around with commits and checkouts on the inner and outer repos, the internal repo survived the process. Also, I don't think versioning content inside `.git` may disorient git in any way. Every git call knows on which `.git` directory it operates, just go up through the path looking for the first `.git` dir which is NOT a part of the actual path. Is there anything else I am missing? Would it be feasible to patch git adding a config option that makes it treat `.git` dirs as regular dirs? I'd be willing to mess with git's source when I get the time to do it.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_5_118d61dea9ef0faa2960da6f2f62ec8b._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_5_118d61dea9ef0faa2960da6f2f62ec8b._comment
deleted file mode 100644
index 28299c372..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_5_118d61dea9ef0faa2960da6f2f62ec8b._comment
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- ip="2001:1928:1:9::1"
- subject="sources"
- date="2013-11-21T18:41:12Z"
- content="""
-I tried to find a canonical source for why (or if?) git ignores any \".git\" directory, and it turns out it also ignores .git *files*, according to [this stackoverflow thread](http://stackoverflow.com/questions/6839781/what-happens-when-you-run-git-add-git-in-a-git-repository). It's hardcoded in the source code and \"will likely not change\".
-
-I guess this should therefore be taken upstream, but I am not sure how this could justified there.
-
-I do think git-annex should support that. It's turning more and more as a \"generic backup solution\" or \"i want my files in the cloud\" kind of solution, which is awesome, but small things like this are making it harder to use... --[[anarcat]]
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_6_3978557c6e85608243e5b4eb698ac5a5._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_6_3978557c6e85608243e5b4eb698ac5a5._comment
deleted file mode 100644
index da52be691..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_6_3978557c6e85608243e5b4eb698ac5a5._comment
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
- nickname="Abdó"
- subject="comment 6"
- date="2013-11-21T20:04:22Z"
- content="""
-After I wrote my last post in this thread I did write a patch for git doing two things:
-
-* make git ignore .git only at the root of the working tree, but not '.git' files or directories nested deeper into the working tree. 
-* add config option to prevent git from converting directories containing .git into gitlinks. It turns out that git already has an internal setting for this, it only needed to be exposed in the config files!
-
-It kind of worked, but I've never used nor completed this, though (if I recall correctly, something had to be done regarding the default gitingores, which contains .git). I don't think upstream would accept these changes, though. It is a potentially risky change that does not gives them any benefit. Plus commiting a git repo inside an other is kind of crazy. I'm not convinced this is a good solution anymore.
-
-Being able to put a git repo inside an assistant-controled directory would be nice, though. Additionally, letting the outermost git repo recognize the internal git repo as a git repo, instead of moving files blindly, would also be nice, and probably more reasonable. And that leads to submodules...
-
-My particular problem is: I want to syncing a directory with lots of little git repos across several machines, without having to configure remotes for every single one of them (so no mr) and having someone take care of the files which are ignored by the little git repos, possibly as annexed files. Currently I just sync that folder containing the little git repos with unison.
-
-Now, instead of commiting git repos inside git repos, I'm more inclined to a potential solution using git-annex + submodules. Ideally I'd like something like this:
-
-1. A git-annex repo at ~/work
-2. All my little git repos inside ~/work are automatically recognized as submodules by git-annex
-3. The outermost git-annex takes care of the .gitignored files for the inner git repos
-4. git pull/push --recursive on the outermost annex repo pulls/pushes submodules (I think [something like this](https://github.com/jlehmann/git-submod-enhancements/wiki/Recursive-submodule-checkout) is written by  Jens Lehmann)
-5. The urls in .gitmodules are relative paths from the outermost annex working tree. Then a git fetch --recursive from the outermost annex can use an outermost remote + the submodule relative path. No need to manually configure remotes for every machine on every submodule!
-
-The problem with this approach, is that 2,4,5 are science-fiction for now, and probably 3 too. Realizing this would imply a lot of work, and commiting a lot of submodule stuff to upstream git. But probably stuff that makes sense and they would accept. Anyway, I'd like to know what Joey thinks about all this...
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_7_e6dfc41d2042402b40efb6f6139d5662._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_7_e6dfc41d2042402b40efb6f6139d5662._comment
deleted file mode 100644
index 374d193c0..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_7_e6dfc41d2042402b40efb6f6139d5662._comment
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.64"
- subject="comment 7"
- date="2013-11-22T16:50:31Z"
- content="""
-I appreciate the investigation.
-
-Now that there's a direct mode guard, it would be possible to have git-annex translate .git directories to some other name when adding files to git. This seems more likely than getting git changed.
-
-However, I am not convinced *at all* that it makes any sense to try to sync git repositories in this way. I realize that some people drop git checkouts into dropbox and use that, but it's a fundamentally unsound thing to do, and those people are just lucky if they manage to avoid running into problems doing that.
-
-If you have two clones of a repo, and a git repository is checked into both, and they become partitioned for a while and larger re-merge, then there can be conflicts in the files that make up the git repository. Which git-annex would auto-resolve, with the effect that the checked-in git repository would appear to be broken.
-
-Also, this feature would only be used by a small number of users, on the border between people who can use git the Correct Way, and people who don't use git other than with the assistant.
-
-It would make sense to make git-annex refuse to add files inside nested git repositories though.
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment
deleted file mode 100644
index df97625f7..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_8_33a84937c87dd2406bc090a0d2969683._comment
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawkkyBDsfOB7JZvPZ4a8F3rwv0wk6Nb9n48"
- nickname="Abdó"
- subject="comment 8"
- date="2013-11-22T18:44:35Z"
- content="""
-> I am not convinced at all that it makes any sense to try to sync git repositories in this way
-
-I agree this is not a good solution.
-
-
-> I realize that some people drop git checkouts into dropbox and use that, but it's a fundamentally unsound thing to do, and those people are just lucky if they manage to avoid running into problems doing that.
-
-Well, I don't use dropbox (nor annex assistant) but I sync a lot of git repos with unison. It is not luck, it is being careful not to create conflicts. I agree this is not ideal, and I'm looking for a better way to deal with this.
-
-
-> Also, this feature would only be used by a small number of users
-
-I'm not convinced of that. If done right, nested git repos inside annex could have value.
-
-Let's say you work with 40 git repos some private of yours, others tracking upstream, and you want to sync them across 4 machines (home, work, cloud server, backup). I imagine your preferred solution would be to configure the 4 machines as remotes on every git repo and use mr, am I right?
-
-This has its problems:
-
-1. The set of files you want in the project git repo may not be the same as the set of files you want synced across machines. For instance, I use a large software project that I compile from sources. I want to sync binaries across machines (it takes forever to compile!), but of course I don't want them commited into the project, not even as annexed files.
-2. Configuring remotes for every project is tedious. What if some remote changes url? what if I want to change the path of some of the git projects? Every time I add a new repo I need to configure all the 4 remotes. This can be scripted of course, but is not my ideal solution.
-
-What do you think about the submodules route I proposed? I don't like submodules very much, but in this case, I think it could become a good solution. In particular it would solve 1, 2 above and be able to merge conflicting changes on the nested repos.
-
-"""]]
diff --git a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_9_28bb02572d453db3b30824ec7604d91a._comment b/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_9_28bb02572d453db3b30824ec7604d91a._comment
deleted file mode 100644
index 36993859a..000000000
--- a/doc/bugs/Can__39__t_add_a_git_repo_to_git_annex__58_____34__Invalid_path_repo__47__.git__47__X__34___for_many_X/comment_9_28bb02572d453db3b30824ec7604d91a._comment
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!comment format=mdwn
- username="https://www.google.com/accounts/o8/id?id=AItOawk11IeWrsbRKPqxl0_Fp5B119mrzpMIkz8"
- nickname="Roland"
- subject="comment 9"
- date="2013-12-08T21:50:31Z"
- content="""
-Same use case here.  Hey, I even also use ~/work.
-
-I've burned my fingers on git repositories synched via Dropbox, so I share the reservations against it.  But in my case the trouble came from lack of caution when sharing the given Dropbox folders.  I'm not sure what the risks are when I'm in control of all the copies.  Synching between my own computers should not pose a problem, I know how to create branches for experimental stuff etc.
-
-I'd love to use git-annex is to maintain dispersed repositories while synching and archiving effectively.  The issue with .git directories is a real blocker and I'd really appreciate a workable solution.  It doesn't have to be perfect, but manually invoking submodule or the need to configure lots of remotes is not exactly practical.
-
-I don't know enough to fully understand everything above.  So what follows may be hopelessly naive.  But it occurred to me there may be a simpler solution: what if git-annex changed the name of its repo to .annex (or so) instead of .git?  And maybe similarly .gitignore to .annexignore etc.  Wouldn't the nested git repositories then \"just work\"?  Because of the hardcoded ignore rules, this approach would require a tweaked git for annex... but overall, wouldn't it be cleaner and more minimal?
-
-I'm probably overlooking something, but maybe this idea can lead somewhere?
-
-"""]]