[rspec-users] rspec + github == !submodules
pergesu at gmail.com
Thu Apr 17 23:43:44 EDT 2008
On Thu, Apr 17, 2008 at 9:01 AM, Jonathan Leighton
<j at jonathanleighton.com> wrote:
> On Thu, 2008-04-17 at 08:49 -0400, David Chelimsky wrote:
> > This all make sense?
> Ok, I have to confess I haven't been paying that much attention to the
> way things are or were set out on github, so let me see if I'm fully
> understanding what you're saying...
> Was "rspec" previously split up into several repositories, with a
> "parent" repository which contained the other repositories as
> submodules? So you are essentially saying that it is a bad idea to split
> one single project into a number of pieces and manage that project
> through submodules? However, you do consider submodules to be a good
> idea if you are using and wish to track third-party upstream code, for
> example plugins in a Rails project?
RSpec was split into four repos...and it still is actually. But
originally the rspec-dev project was a superproject that included the
other three as submodules.
The problem with submodules is if two people are making changes to the
submodules at the same time.
Let's say I work on the rspec submodule, and my final commit is
abc123. You work on the rspec submodule as well and your final commit
is def456. The superproject tracks the head of each submodule,
meaning we each need to commit a reference to the heads of rspec. At
some point you pull from my...and the incoming commits say that the
head is abc123, but you say def456. merge conflict. Not a big deal,
since you have all the latest code, so you can safely point it at
def456. But it's a bit of a hassle because you have to do that every
single time. I don't actually know what all the potential problems
are, but beyond just the hassle, it seems very easy for someone to
make a mistake, causing a lot of headaches.
We still have stuff split up, but we realized there's no reason for
the rspec-dev repo to track the others as submodules. We wrote a rake
task to check out all the other repos beneath the rspec-dev dir. It's
basically the exact same setup, but without the submodule tracking.
And it avoids any problems with submodules, because it's all just
standard git push/pull/merge stuff.
More information about the rspec-users