Eric Wong wrote:
Since git-svn misses some other stuff (many property settings, externals) I'll be working on an internal logging format that can help track those things. It'd be nice to have a command like git svn checkout which works like git checkout; but empty directories are created.
Presumably once the submodule support is worked out, svn externals could be represented as git-svn-managed submodules, yes?
In fact, I'd go so far as to say it should be a design goal of the submodule support: you should be able to indicate somehow that a submodule is a git clone of some non-git resource, and anything that iterates through the submodules (e.g. to freshen them from their respective origins) should know how to run git-svn or whatever so it's all seamlessly integrated. I suppose that's a special case of making git-svn and friends more tightly integrated with git in general; if the git "push" and "fetch" commands know to run git-svn instead of talking to a remote git repository, then it might Just Work for submodules.
Independent of the supermodule being managed by git-svn, the "my software depends on externally-managed code" problem that submodules are attempting to address would be solved a lot more comprehensively if the remote code base could be an svn repository and git knew enough to run git-svn as appropriate to keep it fresh. (Not just svn, of course; any foreign CM system that has an equivalent of git-svn should work.) It'd be pretty cool to have a supermodule that tied together some native-git-managed code, a couple of external svn repositories, and a CVS tree or two, all under a single umbrella with the details automatically taken care of by default.
-Steve - 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