On Tue, 1 May 2007, Chris Shoemaker wrote:
quoted text
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html