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 <[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
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
