followu

doc/bugs/Git_annexed_files_symlink_are_wrong_when_submodule_is_not_in_the_same_path/comment_4_7dae2920926e7556de442952c4a318d9._comment

@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2015-02-27T20:00:54Z"
+ content="""
+Also, git has only used gitfiles for submodules since git 1.7.8.
+
+So, repos using submodules that were cloned with an older version of git
+would use a .git directory. And, if some part of git only supports
+gitfiles, it wouldn't work with such repositories. Which would probably be
+considered a bug since git doesn't break support for existing checkouts.
+
+git-mv and git-rm man pages have a SUBMODULES section documenting that.
+Including the behavior when using git-rm to try to delete a submodule that
+uses a .git directory, instead of a gitfile:
+
+> Only submodules using a gitfile (which means they were cloned
+> with a Git version 1.7.8 or newer) will be removed from the work
+> tree, as their repository lives inside the .git directory of the
+> superproject. If a submodule (or one of those nested inside it)
+> still uses a .git directory, `git rm` will fail - no matter if forced
+> or not - to protect the submodule's history.
+
+So, I doubt that git is going to break support for .git directory (or symlink)
+in a submodule. But, using that might prevent a few things, particularly
+git-rm of a submodule.
+
+<pre>
+joey@darkstar:~/tmp/r2>git rm module
+error: the following submodule (or one of its nested submodules)
+uses a .git directory:
+    module
+(use 'rm -rf' if you really want to remove it including all of its history)
+</pre>
+"""]]