Re: preferring mercurial

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

On Sat, 2014-01-11 at 04:20 +0900, Stephen J. Turnbull wrote:
> 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.

Terminology aside (we're not going to solve the second hardest problem
in computer science today), the structures are very similar. The
arrows were just meant to be suggestive. I wasn't trying to give them
a specific meaning.

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

The fact that git allows this at all is an architectural problem in
the UI. There are better ways, like hg evolve.

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

The problem here would be different: both heads would be visible on
the remote repo. Have you never tried doing this? I'm sure you're well
aware that heads in hg don't need to have a reference to them in order
to be visible from the UI and avoid garbage collection.

In hg the problem is much easier to solve without server-side access:
just push another commit closing-branch commit on the extra head that
you don't want to keep working on.

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

Oh, right. rollback. The one plainly destructive operation in core hg.
It's deprecated, meaning it doesn't show up in the docs anymore, but
because hg is committed to forever backwards compatibility in the CLI,
the actual command is going to be operational forever. At least
nowadays we get

    $ hg help rollback
    hg rollback

    roll back the last transaction (DANGEROUS) (DEPRECATED)

        Please use "hg commit --amend" instead of rollback to correct
        mistakes in the last commit.

    [etc]

One of hg's youthful mistakes. Please don't use it anymore.

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

No, commit --amend creates strip backups by default, or hidden
obsolete commits when using evolve.

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

git has immediately destructive operations too, for example the "git
reset HEAD --hard" that everyone blindly memorises (who really can
keep all of the kinds of resets straight?) will destroy all unstaged
changes. The equivalent command "hg revert --all" creates .orig file
backups unless you explicitly give it the --no-backup option.

Here is a fun git bug I know about: git-gc cannot do concurrency. If
multiple git-gc processes run on the same repo at the same time, you
may end up deleting more than merely unreferenced commits. It's only
very recently received a patch that I know of:

   http://git.661346.n2.nabble.com/PATCH-gc-notice-gc-processes-run-by-other-users-td7601374.html

No write locks on git-gc? That's one of git's youthful mistakes.

- Jordi G. H.