think I found a way to support submodules

doc/bugs/Git_annexed_files_symlink_are_wrong_when_submodule_is_not_in_the_same_path/comment_3_c63b4a86b84c1e4077ddf10858ef5761._comment

@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-02-27T19:45:27Z"
+ content="""
+One way that seems to work to use submodules with git-annex:
+
+* Replace the submodule's .git file with a symlink to the location the
+  contents of the file pointed at. (Eg, ../.git/modules/$whatever)
+* Unset core.worktree in the submodule's .git/config, which will
+  normally be set by git when checking out a submodule.
+
+With this configuration, git seems to work ok (although it's hard to tell
+if there might be some code path that requires .git to be a file and not a
+directory.. seems unlikely though!). And, git-annex works fine, because
+it uses paths relative to the .git symlink, so
+".git/annex/objects/xx/yy/sha/sha" is in the symlink target like usual.
+
+Converting .git to a symlink also means that the same repo that is used
+as a submodule can be moved to a different "mount point" in the parent
+repo, or used standalone, and the git-annex object links in it will
+continue to work.
+
+Looking at the git code, it would be a problem if a code path called
+read_gitfile without also checking is_git_directory or similar. Auditing
+the code, I have found a lot of places that are careful to check both
+possibilities, and none that are a problem with a .git directory;
+although I don't understand all the git code so not 100% sure.
+
+Since a submodule will have core.worktree set, git-annex
+could cheaply check that with nearly no overhead as a first pass to
+detect a submodule, and then do whatever might be appropriate to support
+submodules -- such as replacing .git with a symlink.
+"""]]