On Tue, Apr 8, 2008 at 4:49 PM, D. Stuart Freeman <stuart.freeman@xxxxxxxxxxxxx> wrote: > It's possible to have svn:externals point at a specific revision, but > that's not the point. Right, I forgot that they added that. > cd ../access > git checkout -b 2-5-x sakai_2-5-x # sakai_2-5-x is an svn import > cd ../sakai > git checkout -b 2-5-x sakai_2-5-x > git submodule add -b 2-5-x ../access access > > Which gives me an error about access already existing. You should only ever need to add a given submodule once. As far as I can tell, this is a bit of confusion in the way git-submodule works, but I don't have any suggestions for what to do about it yet so I don't complain :) The way to understand git-submodule's operation is in terms of what it actually does. Roughly speaking, git-submodule-add puts things into .gitmodules and .git/config; git-submodule-init copies that stuff from .gitmodules to .git/config (so if you're the guy who did the add, you can skip this step). Then git-commit actually checks the submodule reference into the parent tree, and someone who pulls your parent tree needs to run git-submodule-update in order to actually retrieve the new submodule pointer. In other words, git-submodule is very powerful, but also very complicated, and at least one of the things I said up above is probably wrong :) By comparison, svn:externals is at least easy to understand. Anyway, in this case, what you need to know is that .git/config already contains your submodule information. Sadly, .gitmodules is probably sitting somewhere on your original branch, so it probably doesn't exist. You could remove the entry from .git/config by hand and use git-submodule-add again (thus putting it in both places), or copy the .gitmodules file from the original branch, or git-cherry-pick the commit where you added it. You should *also* cd into the access subdir and checkout the right revision there; at that time, the next commit to the sakai repository will make sure the submodule reference is to the right place. Phew, I hope that made things more clear instead of less clear. :) Have fun, Avery -- 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
