
Mercurial 2.9 released - 15DCFA8F
http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_2.9_.282014-2-1.29
======
sdfjkl
Very glad to see this in between all the git monoculture. Yes, GitHub is kind
of nice for some things, but git really isn't.

~~~
pekk
What a contentless comment. One might just as well flatly claim that mercurial
isn't nice for anything.

~~~
ender7
git's CLI design is byzantine and inconsistent, with terms that are both
overloaded _and_ underloaded (many commands do multiple, unrelated things
while at the same time many common tasks do not have commands). It's very easy
for newcomers to place their local repo into a limbo or failure state that
they can't get out of without consulting a git guru. git's error messages and
man pages are written for its developers, not for its users. git's overall CLI
structure maps poorly onto its underpinnings, half-hiding parts and not
explaining the rest. Pushing and pulling have really bizarre default behavior
that easily confuse those who have not carefully studied how they work.

git is extremely powerful and is, buried underneath its abysmal UI, a
thoughtful and elegant work of engineering. However, as a product it's
incredibly difficult to explain to other people. Until you've invested a
thoroughly unnecessary amount of time learning its gotchas, quirks, and
vagaries it is a monumental pain in the ass to use.

(Don't get me wrong, I use git all the time and appreciate its power. I just
wish Linus has asked someone else to design the CLI.)

~~~
adharmad
> git is extremely powerful and is, buried underneath its abysmal UI, a
> thoughtful and elegant work of engineering. However, as a product it's
> incredibly difficult to explain to other people. Until you've invested a
> thoroughly unnecessary amount of time learning its gotchas, quirks, and
> vagaries it is a monumental pain in the ass to use.

To some extent, the same arguments can be used by newbies against any powerful
tool (such as vim).

~~~
shawnz
As far as I am concerned, the gap in power between git and hg is much smaller
than the gap in ease of use. The ease-of-use argument is only countered when
there is real value to using the more frustrating alternative, and I'm not
sure there is with git (besides the existence of GitHub, and the support of
Linus Torvalds).

------
philtar
I rarely have geeky conversations with anyone (since I don't know any and that
is why I hang out here) but I'm genuinely curious:

Why is git more popular than hg? I tried both and hg was generally easier (for
me) to pick up. I'm sure it's not JUST because of github.

~~~
rdtsc
3 reasons:

* Linux Kernel : this means for once, great popularity. Those who commit to the kernel have quite a bit of say and influence in the industry. The tools they use get free marketing just from that. But this actually leads to the next reason -->

* Speed : initially git was quite a bit faster. It had been tested and benchmarked day to day on the kernel source tree. hg, bazaar and others weren't as performant back in the day.

* Github : this was the nail in the coffin of all the other DVCS-es as they say. It just came on time, with a nice interface,issues, easy to fork, do pull requests, markdown readmes etc. Not all rocket science features but it was just working very consistently and smoothly.

Now I liked bazaar better if I were not to compare them on performance back in
the day. I like some of its centralization options, other things. But it is
kind of too late in that sense. Launchpad should have appeared, say 6 months
earlier, and it should have been smoking fast. It wasn't. And so my favorite
DVCS was left behind. Bitbucket is also very nice. I really like it. But well
all the cool kids are on Github so some projects just moved to that. I creates
kind of mono-culture and I am not sure if it is good or bad yet.

At the end of the day there are 2 type of developers -- those who care about
version control systems, read about them, play with them, and those that
don't. This classification usually says nothing about other qualities,
experience, personality traits etc. It is just the second group just cares to
use it as a tool. They are willing to learn the minimum amount of command from
a refcard to get their code committed. And having just one system means having
one ref card only if they have to collaborate. So learning git/Github
interface is the easiest way to proceed.

~~~
tonfa
> Speed

Actually in 2005 performance was pretty similar and for some workflows hg was
definitely faster (patch + commit). Also before packs were introduced git just
used massive disk space (hg had smart storage from day one).

~~~
jordigh
git is still slower than hg for some operations, such as blame and clone. I
think it's fundamentally due to the nature of git's data structures, they just
don't optimise for this case, but David Kastrup has boasted that he can fix
git's slowness. I'm skeptical, but let's see...

------
toggle
The only bug here that was "bugging" me was that issue 3857, where you had to
specify the username in your config rather than being able to just do it on
the fly in the command. Nice to see the rest getting fixed, though.

While we're talking about Mercurial (which is rare), the crecord extension may
be getting Windows support soon -- there's a Windows fork, and the original
author wants to merge it in. Crecord is a command-line interface for choosing
which specific lines to include in a commit. It's one of the reasons why I
feel hg is very useable from the command line, even if you aren't a command-
line wizard.

crecord:
[https://bitbucket.org/edgimar/crecord/](https://bitbucket.org/edgimar/crecord/)

windows fork:
[https://bitbucket.org/jmb/crecord](https://bitbucket.org/jmb/crecord)

------
notwedtm
I would be interested in hearing from people who are using hg still. What is
the reasoning? Do you see something in hg that the rest of us don't? Are there
specific features of hg that git doesn't have?

~~~
nilved
Mercurial isn't the terrible DVCS that people left for greener git pastures;
indeed it's the opposite: GitHub is why git won, and people are still learning
how terrible git is and how awesome Mercurial is. They don't "still use"
Mercurial, they "still use" git.

Mercurial has a great API. git has a terrible API. Mercurial is a joy to
extend in Python. git is impossible to extend to any meaningful degree and is
a terrible mess of Perl, shell script and C.

git is a hack and Mercurial is the future.

~~~
yapcguy
I use both. I dont think Git 'won' but it is more popular. I suspect many git
users dont even know why they use git except because they were told to, they
probably never tried hg or know anything about darcs, bitkeeper, etc.

~~~
leobelle
I like git because it stores objects, not diffs and you can recover from
almost anything with reflog.

~~~
anton_gogolev
> I like git because it stores objects, not diffs

Now _that's_ a reason to pick a VCS! Would you drop Git if you found out that
this is not true [1]?

[1]: [http://git-scm.com/book/en/Git-Internals-Packfiles](http://git-
scm.com/book/en/Git-Internals-Packfiles)

~~~
tomlu
I see where he is coming from even if the wording is ambiguous. Git presents
the abstraction of storing objects, and diffs are inferred. The exact
implementation is beside the point.

~~~
tonfa
But then mercurial is the same, the abstraction is about file content, the
diff compression is an internal detail of the storage format like packs.

~~~
tomlu
Yeah for sure. Mercurial is great too.

I was thinking of SVN which does store its commits as diffs, which makes it
brittle (anyone that has tried to use the svn admin tools to rewrite the
repository will know what I mean).

------
polarix
I would LOVE to use mercurial. If the concept of a backup bundle was
completely removed. When I amend a commit with git, I don't put myself 20
minutes away from recovering that pre-amend commit. If hg comes up with some
way to have a flat namespace like git, (ideally with a reflog) I'll be back.

~~~
anton_gogolev
That whole "back up a part of history so that you could undo stuff later" will
be gone as soon as Changeset Evolution [1] is ready. An when it's ready, it
will be tremendous.

[1]:
[http://mercurial.selenic.com/wiki/ChangesetEvolution](http://mercurial.selenic.com/wiki/ChangesetEvolution)

~~~
kyrra
Ooo, being able to push rewritten history, that's nice! Seeing that neither
Git nor HG handles pushing history rewriting gracefully right now, this would
be awesome.

------
eperoumal
For all the reasons mentionned in this thread (interface consistency,
performance, ...) hg is far superior to git. But, as long as git would get the
cool tools - namely, gitlab / gitlab-ci - people won't bother looking at hg. I
started a new project with collaborators a month ago, we had to chose git
mainly because of gitlab, as it would ease the process of managing
consistently our codebase in a visual and simple way, not to mention the
continuous integration goodness that comes with gitlab-ci. There is, to my
knowledge, no close equivalent for hg.

~~~
ergo14
there is rhodecode.com, It's very nice product and I use it on a daily basis.

------
jgalt212
Has anyone used this (or something similar)?

the Hg-Git mercurial plugin

[http://hg-git.github.io/](http://hg-git.github.io/)

~~~
gtaylor
I've tried to use it to mirror an old Hg repo in git, but ran into some really
weird errors with branches in Hg causing vague errors. I couldn't get any help
on the mailing list, and I ended up giving up right as the project said
"Forget it, let's just move to Git."

This was about six months ago. I don't have the error message. I got the
impression that the documentation and the support were pretty sparse for this
plugin. Though, it may work well for more simple Hg repositories, I guess.

------
pbreit
The monthly updates always scare me a bit for version control. Is that really
prudent?

~~~
ngoldbaum
They're actually very big on backwards compatibility. It's quite
straightforward to work with repositories created by old mercurial versions on
and communicate with mercurial installs with different versions. The only
thing that won't work is features that are only in the newer version.

The real effect of the monthly releases is that bugs get cixed in releases,
new features get added, and I get to regularly see all of the awesome activity
going on in the mercurial world.

~~~
Silhouette
This is something that has always made us a little nervous about updating here
as well. Do you know whether the underlying data structures for repositories
are generally maintained with both forward and backward compatibility?

Edit: For anyone else interested, I finally found the magic search term I
never had before, which led me to this page about upgrading and compatibility:

[http://mercurial.selenic.com/wiki/UpgradingMercurial](http://mercurial.selenic.com/wiki/UpgradingMercurial)

and this page about potentially breaking changes where they do occur:

[http://mercurial.selenic.com/wiki/UpgradeNotes](http://mercurial.selenic.com/wiki/UpgradeNotes)

The short version is that older and newer Hg clients and servers and mostly
interoperable in all directions, but with a few specific caveats that are
worth reading before you upgrade anything. There is also the ability to
explicitly change the underlying repository format for compatibility reasons
if you need to.

