On Fri, Apr 18, 2008 at 12:43 AM, Dan North <[EMAIL PROTECTED]> 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 resolving. 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. Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
