On Thu, May 3, 2012 at 11:43 AM, Rich Pixley <rich.pixley@xxxxxxxx> wrote: > > In hg, I don't have to think about how many other branches or repositories > there might be. I don't have to track where the changes are. And I don't > have to do anything to add another repository to the mix or to remove one. > Trivial merges are trivial. The view from any repository is identical, not > just symmetric. The things I want to do are all simple commands. Pull from > the cache, merge if necessary, do some work, push to the cache. Repeat as > necessary since there will be numerous collisions and merges since I'm > working on multiple machines concurrently. And eventually, push to central > server. Wow, this hg sounds great! You should use that! All kidding aside, what you're talking about are design decisions based on preferred workflows. The workflow you're describing may seem obvious and fantastic to you, but it sounds absurdly complicated to me. You hate the way git handles remote branches. I think it's incredibly sensible for a *truly* distributed VCS to enforce location-based namespacing. Basically, we have differences of opinion. Since your opinion seems to be that hg has done everything right and git has done everything wrong, why are you using git? Cheers, -n8 -- HexaLex: A New Angle on Crossword Games for iPhone and iPod Touch http://hexalex.com On The App Store: http://bit.ly/8Mj1CU On Facebook: http://bit.ly/9MIJiV On Twitter: http://twitter.com/hexalexgame http://n8gray.org -- 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