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.
1. I push from laptop1 to my central server. All is good. 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. 3. Oh silly sod - of course I committed from the other machine. 4. I pull from the central server, merge locally and commit, creating a new single head representing the merge 5. I then push the result, meaning there is only ever a single head/tip/edge/whatever in the repository. 6. I realise that this is what I always do with subversion anyway - update, merge, [run tests], commit. It seems git doesn't protect you from yourself like hg does - which is understandable, it's designed for and used by scarier people! 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? Cheers, Dan On 18/04/2008, Pat Maddox <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 17, 2008 at 9:01 AM, Jonathan Leighton > <[EMAIL PROTECTED]> 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. > > > Pat > > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
