<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><html>On Apr 18, 2008, at 3:43 AM, Dan North wrote:</html><br class="Apple-interchange-newline"><blockquote type="cite">With mercurial I nearly did a similar thing, working on my own but committing from two different machines. Luckily mercurial gave me a warning that allowed me to make sense of what I was doing. Not sure how this works with git but here goes.<br> <br>1. I push from laptop1 to my central server. All is good.<br>2. I push from laptop2 to my central server. Mercurial doesn't allow this and warns me that the remote repo will have two heads (which is allowed but probably not what I want). I can override this with --force.<br> 3. Oh silly sod - of course I committed from the other machine.</blockquote><div><br></div><div>This is actually what happened. Two people were doing work at the same time and one got the warning from the repo and did a "push --force." We've all learned a lesson from this and it won't happen again.</div><div><br></div><div>In my opinion, even if you are allowed to force a push, the repo should maintain some reachable history somewhere of the commits that you are "hiding." So the public "view" removes those commits but they can be retrieved.</div><br><blockquote type="cite">4. I <span style="font-style: italic;">pull</span> from the central server, merge locally and commit, creating a new single head representing the merge<br> 5. I then push the result, meaning there is only ever a single head/tip/edge/whatever in the repository.<br>6. I realise that this is what I always do with subversion anyway - update, merge, [run tests], commit.<br><br>It seems git doesn't protect you from yourself like hg does - which is understandable, it's designed for and used by scarier people!</blockquote><div><br></div><div>It actually does in much the same way. You get a warning, but you can still force the push.</div><br><blockquote type="cite">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?</blockquote><div><br></div><div>I do think this should be the way we do things. We have some rake tasks that manage these bits one step at a time. I'll add one that combines them. You'll still be able to do them one at a time, and you'll still need to pull/merge again if central repo warns you on commit.</div><div><br></div><div>Cheers,</div><div>David</div><br><blockquote type="cite">Cheers,<br>Dan<br><br><br><div><span class="gmail_quote">On 18/04/2008, <b class="gmail_sendername">Pat Maddox</b> <<a href="mailto:pergesu@gmail.com">pergesu@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Thu, Apr 17, 2008 at 9:01 AM, Jonathan Leighton<br> <<a href="mailto:j@jonathanleighton.com">j@jonathanleighton.com</a>> wrote:<br> > On Thu, 2008-04-17 at 08:49 -0400, David Chelimsky wrote:<br> > > This all make sense?<br> ><br> > Ok, I have to confess I haven't been paying that much attention to the<br> > way things are or were set out on github, so let me see if I'm fully<br> > understanding what you're saying...<br> ><br> > Was "rspec" previously split up into several repositories, with a<br> > "parent" repository which contained the other repositories as<br> > submodules? So you are essentially saying that it is a bad idea to split<br> > one single project into a number of pieces and manage that project<br> > through submodules? However, you do consider submodules to be a good<br> > idea if you are using and wish to track third-party upstream code, for<br> > example plugins in a Rails project?<br> <br> <br>RSpec was split into four repos...and it still is actually. But<br> originally the rspec-dev project was a superproject that included the<br> other three as submodules.<br> <br> The problem with submodules is if two people are making changes to the<br> submodules at the same time.<br> <br> Let's say I work on the rspec submodule, and my final commit is<br> abc123. You work on the rspec submodule as well and your final commit<br> is def456. The superproject tracks the head of each submodule,<br> meaning we each need to commit a reference to the heads of rspec. At<br> some point you pull from my...and the incoming commits say that the<br> head is abc123, but you say def456. merge conflict. Not a big deal,<br> since you have all the latest code, so you can safely point it at<br> def456. But it's a bit of a hassle because you have to do that every<br> single time. I don't actually know what all the potential problems<br> are, but beyond just the hassle, it seems very easy for someone to<br> make a mistake, causing a lot of headaches.<br> <br> We still have stuff split up, but we realized there's no reason for<br> the rspec-dev repo to track the others as submodules. We wrote a rake<br> task to check out all the other repos beneath the rspec-dev dir. It's<br> basically the exact same setup, but without the submodule tracking.<br> And it avoids any problems with submodules, because it's all just<br> standard git push/pull/merge stuff.<br> <br><br> Pat<br> <br>_______________________________________________<br> rspec-users mailing list<br> <a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br> <a href="http://rubyforge.org/mailman/listinfo/rspec-users">http://rubyforge.org/mailman/listinfo/rspec-users</a><br> </blockquote></div><br> _______________________________________________<br>rspec-users mailing list<br><a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br>http://rubyforge.org/mailman/listinfo/rspec-users</blockquote></div><br></body></html>