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

[David Chelimsky]

On Apr 18, 2008, at 3:43 AM, Dan North wrote:

> 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.

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.

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.

> 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!

It actually does in much the same way. You get a warning, but you can  
still force the push.

> 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 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.

Cheers,
David

> Cheers,
> Dan
>
>
> On 18/04/2008, Pat Maddox <pergesu at gmail.com> wrote:
> 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.
>
>
> Pat
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080418/9874baca/attachment-0001.html