On Thu, May 3, 2012 at 9:13 PM, Rich Pixley <rich.pixley@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html