On Tue, Sep 2, 2008 at 5:49 PM, Tim Haines <[EMAIL PROTECTED]> wrote: > Hi James, > > Thanks for writing these instructions up in detail. I've just followed them > and will play around with them over the next few days. A couple of > questions > > 1) I assume with submodules I can create and switch to branches of the > submodules if I want to try my app out with some patches applied to rspec or > rails? There's no hidden gotch'ya here?
There is. If you ever run "git submodule init" (and/or update, I don't remember) again then it'll blow away your entire local repo. Meaning if you've made changes that you haven't pushed, you lose them all. Suck. Also, if you're actually making changes to the child repo, and you're working collaboratively, you're going to be dealing with a bunch of headaches. Basically, submodules work by git saying "vendor/plugins/rspec points to commit abc123 from git://github.com/yourmirror/rspec.git". If you make changes to the repo and commit, git will update the reference to the new commit. Now let's say one of your coworkers makes a non-conflicting change and commits...well, now the parent repo has conflicting changes (you say that the submodule points to foo456 and your coworker says it points to bar789). You get a conflict in the parent repo, now you have to resolve it, and you have to do it every single time. This was the system we originally had when the RSpec repo moved to git and it was a massive PITA. Basically, if you want to track remote repos, but you're not doing active development on them, submodules work fine. The second you want to start making changes, submodules are going to be a bitch. I wrote a gem and some sake tasks to help with this a bit. It's very simple but it's worked beautifully so far for me. http://github.com/pat-maddox/giternal/tree/master > 2) When I'm getting near deployment for production (a few months away yet) > I'm thinking of freezing to a tagged version of Rails. (Not sure this > terminology is still correct with Git - but basically I might stick with > Rails 2.2 or something - but I'm not sure this has benefits anymore). How > would you go about this? Freezing is something that I want to put into giternal but so far haven't had a strong enough need to. I might work on it soon just for the heck of it :) The basic idea I have is to flatten the repo...so you move the .git dir to .git.frozen, add the whole external and commit. Then to unfreeze you remove the dir from version control (though without deleting it locally) and move .git.frozen back to .git. Again, something I want to put in giternal but haven't done yet. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
