Re: preferring mercurial

["Jordi Gutiérrez Hermoso" <jordigh@octave.org>]

On Fri, 2014-01-10 at 02:31 +0900, Stephen J. Turnbull wrote:
> François Orieux writes:
> 
>  > My resume of all the posts I have read is that git and hg are
>  > technically equivalent.
> 
> AFAICS they are very much *not* technically equivalent. They may be
> equal in power, especially at the UI level, but git exposes a much
> cleaner interface to the internal model of blobs (file content),
> trees (file directories), and commits *to the user*. 

To me this seems like a *bad* thing. You wouldn't want to write
mallocs in order to use Emacs just because part of Emacs is written in
C. That would not make you feel more productive.

User interfaces are a good thing. It's ok to have hackable internals,
but it's not ok to expose them by default. Granted, with the likes of
legit, magit, or git-flow, then git really does get a UI, so perhaps
you'll just say that git's defaults are not for me.

Furthermore, hg's internal data structures aren't that hard to
understand either. Commit -> tree -> blob -> ref, meet changelog ->
manifest -> filelog -> revlog. This is a good introduction to hg's
internals:

    http://hgbook.red-bean.com/read/behind-the-scenes.html

They're both actually quite similar, trees are like manifests, blobs
are like revlogs. A testament to how similar is that it's actually
possible for Kiln Harmony to exist: a bridge between git and hg at the
*data structures* level.

> This means that git is more hackable: you can script it with shell,
> you can script it with Python, you can script it with Emacs Lisp, or
> you can write C.

You can do any of these with hg, and you have your choice of C (hg's
commandserver), Python ("import mercurial"; it's just another Python
library), or bash or any other language (parsing hg's stdout,
guaranteed to be parseable forever). The way magit is written, just by
piping to and from git is exactly the way that it could be written for
hg.

> I don't know about Mercurial, haven't looked at its internals.

Neither have I in detail until recently, in order to understand why it
was faster than git.

> Git invites you to play with the DAG, just as Lisp invites you to
> play with lists.

There's lots of DAG playing in hg too. Please recall my past message
to you in which I outlined the hg commands for DAG-playing.

> Nothing has more respect for history than git.

This isn't very respectful of history:

    http://www.infoq.com/news/2013/11/use-the-force/

It took a lot of work to fix this problem:

    http://jenkins-ci.org/content/summary-report-git-repository-disruption-incident-nov-10th

> That's why git doesn't have backups (the way hg and bzr
> save bundles if you do a "commit --amend" or a "strip")

This is a quibble. One stores backups on the DAG and you have to dig
through the reflog to get them. Another stores backups in
.hg/strip-backups and you have to use hg incoming to dig through them.
It's just a UI difference. The biggest difference is that by default
git deletes it automatically after a longish time, but hg doesn't.

With hg's evolve, however, you get something much better than either
strip bundles or unreferenced commits: safe collaborative edition of
history that knows how to propagate across clones. No more "git push
--force"!

> History isn't *changed*, it is recreated

Same in hg. New history means new hashes. Old history is still lying
around.

> and the original history remains accessible to the user.

Sort of. Depends on what you mean by "accessible". To an unexperienced
user, either of git or hg, rewritten history can appear to be lost
until they learn the proper incantations to recover it. This is why hg
disables history edition by default, analogous to how Emacs disables
some commands by default. It's just a matter of unmuzzling them both
if you want to use those features.

> AFAIK hg and bzr *do* destroy history when they perform operations
> like commit --amend, strip, and rebase.

I hope I helped you to know better now.

Lastly, let me say that git has its uses, but it also has some
fundamental flaws, and there's still plenty of room for friendly
competition. :-)

- Jordi G. H.