On Tue, 1 May 2007, Chris Shoemaker wrote: > > Making git-svn handle svn:externals with specified revisions would be > _quite_ useful. There's a special-case of this that I use personally: > svn:externals that point to other paths (and other revisions) of the > parent repo. Side note: even _without_ a specified revision, I think it's quite sane to have the rule that a submodule hash of all zeroes is "unversioned". Such a submodule is still _useful_: while the tree itself contains no information (and it SHOULD NOT do so, since the actual location of the external module may not be globally stable or visible!), it would basically act like subversion externals together with the ".gitmodules" file that contains that information. So while the git submodule thing was designed to specify specific revisions, there's nothing that really technically _requires_ it. The exact SHA1 details in the submodule link are going to be up to the higher-level user anyway. (Of course, if you actually have a "all zeroes" gitlink entry, and then have a checked-out git tree at that entry, "git status" and "git diff" would show it as needing update. I think that's _correct_, but if we want to shut it up for the special case of all-zero SHA1, we trivially could). But while I'm encouraged that the whole gitlink thing seems to be working for Andy, and some others are playing with it too, I'm also a bit discouraged by the fact that there hasn't been any noise or work on the porcelain side. I was obviously optimistic and hoping we'd see support in checkout/diff, but I haven't heard anybody talk about actually implementing .gitmodules and the porcelain support that uses them.. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html