

Mercurial over Git - jchonphoenix
http://jonchu.posterous.com/16445171

======
icefox
"Need to make a new branch? Try git branch--er... I mean 4 seemingly random
Git commands that don't include the word branch. "

'git branch <branchname> [start-point]' creates a new branch....

Maybe he is referring to the fact that git branch wont change change branches?
You have to use git checkout to actually switch branches.

"Not only is documentation for some important features sparse, the
documentation that does exist is rarely ever of the best quality."

I am curious what specifically he was referring to. The docs on git-scm are
pretty extensive. Between the docs, books, cheatsheets, videos there is a ton
out there. Even the man pages include example usage where many man pages for
command line tools do not.

Something I can't help but ponder is that in switching to the second system
they already had a grasp of some dvc concepts making it easier and if trying
git second would have been easier.

~~~
viraptor
I think he meant `git checkout -b ...` since that's what people want to do
most of the time. What's the use case for creating a branch if you're not
going to use it straight away? (and no 'branch' in the command really)

~~~
jshen
does he really have a problem remembering 'git checkout -b ...'? Seems like a
non issue to me.

~~~
viraptor
It's not an issue, but it can be an annoyance. Put many of them together and
you've got a reason why projects like Ubuntu's 100 papercuts exist. If you
have to work with something that just isn't quite right even if it works in
the end, it can affect your work.

------
drewcrawford
To a lot of the people who prefer Hg to Git, I ask this question: What's the
proper way to do a feature branch in Hg? (serious question) The three answers
I've heard are:

* Use hg branch <branchname> like git. The problem is this always requires me to do a push -f, which doesn't feel right...

* Use clone. Really? For a feature branch?

* Use the LocalBranches extension. Really, feature branches (the #1 productivity gain since switching to DVCS) isn't in the core code?

I have yet to find an equivalent to what I consider a core git workflow.

~~~
reiddraper
push -f is what I use, "force" makes it sound more sinister than it is.

~~~
samps
push -f is the thing. Requiring -f just makes you think twice before
accidentally exposing the rest of the world to your changes without merging
them.

------
lincolnq
Your use of the words "intuitive" and "revert" in this context betray that
your models are driven by how you expect centralized version control to work.

While Git and Mercurial are nearly isomorphic in implementation, their UIs
differ significantly because they're written with different models of DVCS in
mind.

Basically, I would argue you haven't fully grokked Git. To the extent that I
have understood Git's model, I have found it extremely insightful; if you want
this insight, you should spend a little more time trying to understand it
before giving up on it.

~~~
alexgartrell
As a long-time TA for the class leading up to 15-410 (almost as long as he's
been a student at CMU) I can firmly attest to the fact that we have done
absolutely nothing to make him aware of centralized version control (or
distributed version control...) :)

So basically, he's got the freshest possible eyes to make this judgement, and
if your counterclaim is that he hasn't truly grokked it yet, then that
suggests that it may be counterintuitive.

Additional fairness: the project in question is a 6-week round-the-clock code
fest. Writing a kernel from scratch takes forever. (Is this project just a
waste of time? Having moved on to poking at the Linux kernel and stuff, I'd
say almost certainly, but that's a topic for another conversation.)

Most Sincerely, Alex "Found out the hard way that reset != revert" Gartrell

~~~
theli0nheart
> if your counterclaim is that he hasn't truly grokked it yet, then that
> suggests that it may be counterintuitive.

Or proper usage wasn't explained to him correctly.

~~~
wmcc
Since we learn from the online docs, doesn't your statement imply that Gits
online documentation isn't very good?

~~~
pyre
> _Since we learn from the online docs_

That's an assumption.

~~~
mcn
wmcc stated he was in the same OS class as the blog poster.

------
jmtulloss
It will be interesting to hear what he thinks of Mercurial after running into
some of its warts.

I think it's valuable to read the opinions of people who are just getting into
this game. Those of us with lots of experience with the everyday tools of the
trade might not see a lot of substance to this critique, but it's important
when designing any product to make sure it's approachable for novices. There's
often a tradeoff there for power or flexibility, which git has been unwilling
to make (probably rightfully so), but it does seem that things could be done
to make the tool easier to get into, without necessarily compromising its
power.

~~~
tghw
It's not a trade-off of power or flexibility as much as it is a difference in
priorities. Git puts all of the powerful -- and potentially dangerous -- tools
front and center (history editing, to name a big one), whereas Mercurial
supports all of the same functionality, but hides away some of the more
dangerous tools until you're ready to enable them.

------
MrMatt
This seems to be less about Mercurial vs Git, and more Jon Chu vs Git.

Although I haven't used Mercurial, all of the issues he brings up I found
really easy to solve when I started using Git (~2 years ago). The number and
quality of online resources has only improved since then.

------
OSTwister
If I understand git right, it's designed to allow different front ends - the
"porcelain." I wonder if an alternative "porcelain" could be made which would
be more intuitive to some?

~~~
lincolnq
It was made several years ago, near the birth of Git, called cogito.
<http://git.or.cz/cogito/> . It's currently deprecated.

It was how I learned Git actually; it made the UI very similar to mercurial's
UI. It was actually a surprisingly good learning curve, because it allowed me
to experiment with git commands side-by-side with cg commands on the same
repo, and I slowly transitioned out of cg into full-fledged git, almost
without noticing. I'm a little sad it's not maintained.

~~~
OSTwister
Very like Mercurial eh? I wonder if it'd be worth someone's while to pick it
up & maintain it.

------
jchonphoenix
I believe the preference of one system over the other is based mostly on how
they feel to the user.

Git is like a swiss army knife. git checkout can do just about everything and
anything. Mercurial seems to be more split. hg update and hg revert do
separate things.

Again a lot of preference comes down to personal feel. I prefer modularity.
Others may prefer one tool solving it all.

~~~
tghw
Apropos of your comment (and possibly the source):
[http://stevelosh.com/blog/2010/01/the-real-difference-
betwee...](http://stevelosh.com/blog/2010/01/the-real-difference-between-
mercurial-and-git/)

------
awt
Grb gives you wings:

<http://grb.rubyforge.org/>

~~~
jkmcf
grb will help you create and manage remote branches. Why something like this
isn't baked into git, I don't know. I'm just happy grb exists!

    
    
      git_remote_branch version 0.3.0
    
      Usage:
    
      grb create branch_name [origin_server] 
      grb publish branch_name [origin_server] 
      grb rename branch_name [origin_server] 
      grb delete branch_name [origin_server] 
      grb track branch_name [origin_server]
    

There are also plenty of aliases for the various actions.

    
    
      create: create, new
      delete: delete, destroy, kill, remove, rm
      publish: publish, remotize, share
      rename: rename, rn, mv, move
      track: track, follow, grab, fetch

------
pkulak
You don't have a personal preference, you're just ignorant.

Okay, now no one has to comment anymore; I've taken care of all of it.

~~~
wmcc
Troll

