[rspec-users] rspec + github == !submodules

Pat Maddox pergesu at gmail.com
Fri Apr 18 05:24:43 EDT 2008

On Fri, Apr 18, 2008 at 12:43 AM, Dan North <tastapod at gmail.com> wrote:
> Could a pull-merge-commit before pushing have avoided this, and should we
> make that our endorsed way of working? Or am I missing something else about
> how dscm works?

I'm still fuzzy on the details of exactly what happened.  I believe it
was the result of a "commit -f" which forced the remote repository to
rewrite the history when there was branched histories that needed

I believe that pull-merge-commit would work fine, I experimented
locally to understand the effects of handling submodule reference
merge conflicts.  As I mentioned before, it is just a bit of a hassle
to have to do.  David also pointed out that even without the
conflicts, you still have to commit the reference, leading to lots of
"updated rspec-rails" type commits in rspec-dev.

pull-merge-commit is probably a good workflow (and indeed the only
one, because otherwise it's push-REJECTED-pull-merge-commit).  The
main advantage to not using submodules is that you'll only have to
merge is when git can't intelligently merge the repos, rather than
every time two repositories have different HEADs.


More information about the rspec-users mailing list