all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Jordi Gutiérrez Hermoso" <jordigh@octave.org>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: "Rüdiger Sonderfeld" <ruediger@c-plusplus.de>,
	"Neal Becker" <ndbecker2@gmail.com>,
	"François Orieux" <orieux@iap.fr>,
	emacs-devel@gnu.org
Subject: Re: preferring mercurial
Date: Fri, 10 Jan 2014 10:03:48 -0500	[thread overview]
Message-ID: <1389366228.5784.14.camel@Iris> (raw)
In-Reply-To: <87iottf4fe.fsf@uwakimon.sk.tsukuba.ac.jp>

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.





  parent reply	other threads:[~2014-01-10 15:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-09 12:35 preferring mercurial Neal Becker
2014-01-09 13:11 ` Tim Visher
2014-01-09 13:53   ` Neal Becker
2014-01-09 13:44 ` Rüdiger Sonderfeld
2014-01-09 14:49   ` François Orieux
2014-01-09 17:31     ` Stephen J. Turnbull
2014-01-10  9:54       ` François Orieux
2014-01-10 11:48         ` Nathan Trapuzzano
2014-01-10 12:44           ` Stephen J. Turnbull
2014-01-10 11:50         ` Stephen J. Turnbull
2014-01-10 13:59         ` Stefan Monnier
2014-01-10 14:08           ` Eric S. Raymond
2014-01-10 15:22             ` Jordi Gutiérrez Hermoso
2014-01-10 15:55               ` Eric S. Raymond
2014-01-10 16:09                 ` Jordi Gutiérrez Hermoso
2014-01-10 16:21                 ` Eli Zaretskii
2014-01-11  7:15                   ` Richard Stallman
2014-01-10 15:03       ` Jordi Gutiérrez Hermoso [this message]
2014-01-10 19:20         ` Stephen J. Turnbull
2014-01-10 19:54           ` David Engster
2014-01-10 19:55           ` Jordi Gutiérrez Hermoso
2014-01-11 15:55             ` Stephen J. Turnbull
2014-01-11 16:37               ` David Kastrup
2014-01-15 17:07       ` Martin Geisler
2014-01-15 16:49   ` Martin Geisler
2014-01-09 15:42 ` Yuri Khan
2014-01-10 15:16   ` Jordi Gutiérrez Hermoso
2014-01-09 20:28 ` Barry Warsaw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1389366228.5784.14.camel@Iris \
    --to=jordigh@octave.org \
    --cc=emacs-devel@gnu.org \
    --cc=ndbecker2@gmail.com \
    --cc=orieux@iap.fr \
    --cc=ruediger@c-plusplus.de \
    --cc=stephen@xemacs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.