Re: Newbie grief

On Thu, May 3, 2012 at 9:13 PM, Rich Pixley [off-list ref] wrote:

This is probably what I'm going to end up using.

Just for comparison, here's a similar process in hg.

Cache server:

 $ hg clone $uri_for_central_repo

% git clone $uri_for_central_repo

Machine A:

 $ hg clone $uri_for_cache_repo

% git clone $uri_for_cache_repo

 $ # ...do some work...
 $ hg push

% git push

Machine B:

 $ hg clone $uri_for_cache_repo

% git clone $uri_for_cache_repo

 $ # ...do some work...
 $ hg push # assume this collides

% git push

 pushing to $uri_for_cache_repo
 searching for changes
 abort: push creates new remote head 6d2eb0a6a278!
 (you should pull and merge or use push -f to force)
 $ hg push -f # the pull and merge case parallels git, so let's use push -f.

This is stupid, why make everybody else's life difficult? Let's merge here.

% git pull
% git push

Any repo:

 $ hg pull # pulls in all changes including the dual heads

% git pull

 $ hg merge # collapses the dual heads
 $ hg commit # commits the merge
 $ hg push

No need for this, the guy that diverged did this (Machine B).

Plus, what happens if 3 other machines do this? You you have 3 merges,
2 would conflict, and then you would have useless recursive merges, or
some people would have to revert. Why bother N people, when one guy
can do it at the origin (Machine B)?

Machine A:

 $ hg pull # pulls in all changes so far
 $ hg up

% git pull

 $ #... do some work ...
 $ hg push

% git push

Machine B

 $ hg pull
 $ hg up

% git pull

 $ # ... do some work ...
 $ hg push

% git push

Any repo:

 $ hg pull $uri_to_central_repo
 $ hg merge

% git pull $uri_to_central_repo

 $ hg push $uri_to_central_repo

% git push $uri_to_central_repo

 $ hg push # default is cache repo

% git push

Machine B:

 $ hg pull

% git pull

Some Conclusions:

* the work flows are similar.

* the hg commands are simpler and have the defaults that we want, primarily
because no extra branches are required.

Wrong.

* the hg error messages are straightforward, clear, and don't require any
deep knowledge of the source code control system or it's limitations.  (I
still don't understand what the git message on collision is saying.)

Whatever. I don't care what the error message for a merge conflict
actually says, all I need to know is that there was a conflict.

* hg has more options about how to handle the collisions or the merges.
 While git can mimic some of those options, doing so requires a priori
knowledge that isn't stored in the source code control system and therefor
requires a human exchange which is optional with hg.

WTF? git handles collisions just fine.

Actually the git version has less commands. And if configured properly
you don't need to specify URLs.

Cheers.

-- 
Felipe Contreras