Re: Migrating svn to git with heavy use of externals
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- Apr 8, 2008, 21:01 UTC
- Message-ID
- <32541b130804081401n743f39c9o3f016da9dee2eb92@mail.gmail.com>
- In-Reply-To
- <47FBDA77.2050402@et.gatech.edu>
On Tue, Apr 8, 2008 at 4:49 PM, D. Stuart Freeman <stuart.freeman@et.gatech.edu> 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.
Show 7 quoted lines
> 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