1 files changed, 30 insertions, 0 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_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
new file mode 100644
index 000000000..3cbee238c
--- /dev/null
+++ 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
@@ -0,0 +1,30 @@
+[[!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
+"""]]