Re: preferring mercurial

[Stephen J. Turnbull]

Jordi Gutiérrez Hermoso writes:

 > Furthermore, hg's internal data structures aren't that hard to
 > understand either. Commit -> tree -> blob -> ref, meet changelog ->
 > manifest -> filelog -> revlog.

Besides the fact that blob->ref is nonsense, look whose terminology
makes more sense here.

 > > 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/

First, note that the culprit, Gerrit, does not use git to access git
repos, and by *default* does push --force.  Blaming this particular
disaster on git itself is unfair.

Second, from hg help push:

     -f --force                 force push

    Note:
      Extra care should be taken with the -f/--force option, which
      will push all new heads on all branches, an action which will
      almost always cause confusion for collaborators.

IOW, this is a people problem, which Mercurial would be subject to as
well.

 > > History isn't *changed*, it is recreated
 > 
 > Same in hg.  New history means new hashes. Old history is still
 > lying around.

Where?  How do you get at it?  Eg (some output deleted):

$ mkdir hgtest && cd hgtest && hg init
$ echo foo >> foo && hg add foo && hg commit -m 1 && hg heads
changeset:   0:ead82a170088
$ echo foo >> foo && hg commit -m 2 && hg heads
changeset:   1:e5790bc8b230
$ hg rollback
repository tip rolled back to revision 0 (undo commit)
$ hg heads
changeset:   0:ead82a170088
$ hg log -r ead82a170088
changeset:   0:ead82a170088
$ hg log -r e5790bc8b230
abort: unknown revision 'e5790bc8b230'!

Oops.  The same thing happened with "commit --amend".

 > > 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.

Unfortunately, no.  The actual behavior of hg is indeed immediately
destructive in some cases, unlike git.