preferring mercurial

preferring mercurial

[Neal Becker]

I don't understand the git momentum.  I've use hg heavily, and am generally 
happy with it.

Every time I have to use git, I have a terrible time.  I find it vastly more 
complicated than hg.  The docs (in the form of man pages) I find never answer my
questions.  Each one seems to cover 100 different topics, variations and corner
cases.  Trying to read this requires a vast new vocabulary or arcane terms.

hg also has tortoisehg, which is a very nice mature gui.  There is nothing like 
that for git.  I have found 1 or 2 guis that are extremely limited in function.

Re: preferring mercurial

[Tim Visher]

Hi Neal,

On Thu, Jan 9, 2014 at 7:35 AM, Neal Becker <ndbecker2@gmail.com> wrote:
> I don't understand the git momentum.  I've use hg heavily, and am generally
> happy with it.

At this point, as esr has said on multiple occasions, git's momentum
just is what it is. It one like Java did. It's probably time to just
make your peace with that.

> Every time I have to use git, I have a terrible time.  I find it vastly more
> complicated than hg.  The docs (in the form of man pages) I find never answer my
> questions.  Each one seems to cover 100 different topics, variations and corner
> cases.  Trying to read this requires a vast new vocabulary or arcane terms.

I've used git since pretty early on and so I don't have beginners mind
here but I'd say that if you were to give it time and loose some of
your assumptions, git's ui would start to make more sense to you. I
don't know if it's Stockholm Syndrome talking or not, but having used
it for a number of years almost exclusively it's ui and terminology
make perfect sense to me.

> hg also has tortoisehg, which is a very nice mature gui.  There is nothing like
> that for git.  I have found 1 or 2 guis that are extremely limited in function.

Sounds like you're on windows, then. Have you given tortoisegit or Git
Cheetah a shot? Back when I was into GUIs, I remember tortoisegit
being at least as nice as tortoisesvn (which I believe was the main
progenitor of the tortoise-x naming convention).

https://code.google.com/p/tortoisegit/
https://github.com/msysgit/Git-Cheetah

--

In Christ,

Timmy V.

http://blog.twonegatives.com/
http://five.sentenc.es/ -- Spend less time on mail

Re: preferring mercurial

[Neal Becker]

Actually, I don't use windows.  I use emacs for almost everything.  But thg is 
actually very nice for visualizing things - it one of the very few guis I use.

Re: preferring mercurial

[Rüdiger Sonderfeld]

This has all been discussed here: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00238.html

On Thursday 09 January 2014 07:35:22 Neal Becker wrote:
> hg also has tortoisehg, which is a very nice mature gui.  There is nothing
> like that for git.  I have found 1 or 2 guis that are extremely limited in
> function.

I don't think a GUI primarily for Windows (non-free software) is going to 
persuade GNU Emacs developers.  (And in my opinion `magit' is the best VCS 
interface I have used so far.)

Regards,
Rüdiger

Re: preferring mercurial

[François Orieux]

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

>This has all been discussed here: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00238.html

As a programmer of scientific algorithm for data processing, I choose hg
when I have the choice and git when I haven't the choice. But I am just
a user of hg, git and emacs.

My resume of all the posts I have read is that git and hg are
technically equivalent. Hg is cleaner, easier with better doc and ui
with a bigger respect of history.

And git is popular... But if they are technically equivalent, then git
is not popular for technical reasons. So why git is more popular if it
is not for technical reasons, neither for it's doc, it's ui or whatever
you want ?

The second good point for git I have see is that developer will not have
to learn another tools. With such argument I'm asking myself why I have
learn emacs, python and numpy... Finnally there is magit and I must
admit that magit make me use git with less anxiety about my work :)

Regards, François

-- 
IAP, CNRS-UPMC - Paris, France
+33 1 73 77 55 11
http://research.orieux.fr

Re: preferring mercurial

[Stephen J. Turnbull]

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

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.  Bzr definitely loses big here: the internals are
layer upon layer upon layer of complex Python API.  I don't know about
Mercurial, haven't looked at its internals.  Git invites you to play
with the DAG, just as Lisp invites you to play with lists.

Is this *better*?  That's a matter of taste.  But different?  Definitely.

 > Hg is cleaner, easier with better doc and ui

I disagree, but again it's a matter of taste.

 > with a bigger respect of history.

That is a lie, and you should stop repeating it, and tell people who
try to tell it to you to stop, too.

Nothing has more respect for history than git.  Using git, you can
forget history (by deleting or moving refs) but you can't change it or
delete it.[1]  That's why git doesn't have backups (the way hg and bzr
save bundles if you do a "commit --amend" or a "strip") for the
operations that fans of other VCS call "history-changing" -- it
doesn't need them.  History isn't *changed*, it is recreated -- and
the original history remains accessible to the user.  AFAIK hg and bzr
*do* destroy history when they perform operations like commit --amend,
strip, and rebase.  For sure, git *does not*.

It's true that you can alter the presentation of history in git
relatively easily compared to other VCSes.  But it's possible in them,
too, and (AFAIK) in them it does destroy original history in the
process of remaking it.


Footnotes: 
[1]  If you don't care about parts of history you've forgotten, git-gc
will eventually delete forgotten history -- and only forgotten history.
But because of the reflog, even if you forget, git won't, for at least
30 days (by default).

Re: preferring mercurial

[François Orieux]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> François Orieux writes:
>
>> My resume of all the posts I have read is that git and hg are
>> technically equivalent.
>
> [...] but git exposes a much cleaner interface to the internal model
> of blobs (file content), trees (file directories), and commits *to the
> user*.
>
> [...] I don't know about Mercurial, haven't looked at its internals.

I don't know to, but you can't say "git is better" and say after you
don't know about hg.

>> Hg is cleaner, easier with better doc and ui
>
> I disagree, but again it's a matter of taste.

By using both, we can't really say it's a matter of taste. By reading
doc we can't to. Or by reading all these pages on internet, like

http://stevelosh.com/blog/2013/04/git-koans/

>> with a bigger respect of history.
>
> That is a lie, and you should stop repeating it, and tell people who
> try to tell it to you to stop, too.
>
> Nothing has more respect for history than git.  Using git, you can
> forget history (by deleting or moving refs) but you can't change it or
> delete it.[1] [...]

Ok I didn't know that point and I will stop.

Git is excellent and a good choice for emacs. But by taking into account
all the pro and cons of both tools, we must admit that the sole thing
that really remains is that git is popular: git is chosen because
"everybody" chose this tool. Why not afterall.

--
IAP, CNRS-UPMC - Paris, France
+33 1 73 77 55 11
http://research.orieux.fr

Re: preferring mercurial

[Nathan Trapuzzano]

François Orieux <orieux@iap.fr> writes:

> But by taking into account all the pro and cons of both tools, we must
> admit that the sole thing that really remains is that git is popular:
> git is chosen because "everybody" chose this tool. Why not afterall.

I still don't think that's right.  Git and Mercurial have significantly
different data models.  Git's model is much simpler and allows complex
actions to be defined in terms of a small number of very basic unifying
concepts, whereas the same actions in Mercurial often require
non-standard extensions.  As I believe someone in this thread already
put it: "Git got branches right, Mercurial (and Bazaar, etc.) didn't".
This essay describes the difference well:

http://xentac.net/2012/01/19/the-real-difference-between-git-and-mercurial.html

Re: preferring mercurial

[Stephen J. Turnbull]

Nathan Trapuzzano writes:

 > "Git got branches right, Mercurial (and Bazaar, etc.) didn't".
 > This essay describes the difference well:
 > 
 > http://xentac.net/2012/01/19/the-real-difference-between-git-and-mercurial.html

Except that this blog fails to mention bookmarks and the rev query
language, like I did earlier in this thread.  The combination of those
two changes the game quite a bit I suspect.

I still like git's open data structures compared to Mercurial's
revlogs (for example, it's not obvious what happens if you rollback a
bookmarked commit), but once you have proper refs and a query
language, it should be possible to do most of the things git does as
git does them.

Re: preferring mercurial

[Stephen J. Turnbull]

François Orieux writes:

 > I don't know to, but you can't say "git is better"
 > and say after you don't know about hg.

And I didn't.  I said I like it better (I've used both heavily), and I
said the model of version control *presented to the user* (not to the
developer) is cleaner.

 > Git is excellent and a good choice for emacs. But by taking into account
 > all the pro and cons of both tools, we must admit that the sole thing
 > that really remains is that git is popular: git is chosen because
 > "everybody" chose this tool. Why not afterall.

There is another thing.  Other things being equal, I think the Emacs
developers as a group prefer tools that say "Hi, I'm the git VCS.
Hack me!"  I've never been tempted to hack hg (and I *like* Python),
and considered hacking bzr only to help a friend (which I quickly
learned was not worth it).

Certainly some senior Emacs developers have expressed a strong
preference for a VCS that doesn't need to be hacked, and undoubtedly a
fair amount of hacking around git by somebody is needed to help them
achieve comfortable workflows.  Whether it's worth it is their decision.

Re: preferring mercurial

[Stefan Monnier]

> all the pro and cons of both tools, we must admit that the sole thing
> that really remains is that git is popular:

Of course.  That's the whole reason for the change.  If it weren't for
that, we'd stick to Bzr which serves us fine for Emacs's trunk.


        Stefan

Re: preferring mercurial

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> > all the pro and cons of both tools, we must admit that the sole thing
> > that really remains is that git is popular:
> 
> Of course.  That's the whole reason for the change.  If it weren't for
> that, we'd stick to Bzr which serves us fine for Emacs's trunk.

Furthermore, the Mercurial fans bitching about this seem to forget that 
in the original post where I pushed for the change to git that *I prefer
Mercurial myself*.  Yet I use git, because the advantages of being part
of the largest and most active ecosystem outweigh the technical benefits
of Mercurial.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: preferring mercurial

[Jordi Gutiérrez Hermoso]

On Fri, 2014-01-10 at 09:08 -0500, Eric S. Raymond wrote:

> Furthermore, the Mercurial fans bitching about this seem to forget
> that in the original post where I pushed for the change to git that
> *I prefer Mercurial myself*. Yet I use git

Not much of a preference, then. Why not help us improve hg-git or
advocate for Kiln Harmony to get freed up?

- Jordi G. H.

Re: preferring mercurial

[Eric S. Raymond]

Jordi Gutiérrez Hermoso <jordigh@octave.org>:
> On Fri, 2014-01-10 at 09:08 -0500, Eric S. Raymond wrote:
> 
> > Furthermore, the Mercurial fans bitching about this seem to forget
> > that in the original post where I pushed for the change to git that
> > *I prefer Mercurial myself*. Yet I use git
> 
> Not much of a preference, then. Why not help us improve hg-git or
> advocate for Kiln Harmony to get freed up?

Because I don't believe anything I could do would reverse git's
runaway-leader status.  I'm too busy to bother with futile gestures.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: preferring mercurial

[Jordi Gutiérrez Hermoso]

On Fri, 2014-01-10 at 10:55 -0500, Eric S. Raymond wrote:
> Jordi Gutiérrez Hermoso <jordigh@octave.org>:
> > On Fri, 2014-01-10 at 09:08 -0500, Eric S. Raymond wrote:
> > 
> > > Furthermore, the Mercurial fans bitching about this seem to forget
> > > that in the original post where I pushed for the change to git that
> > > *I prefer Mercurial myself*. Yet I use git
> > 
> > Not much of a preference, then. Why not help us improve hg-git or
> > advocate for Kiln Harmony to get freed up?
> 
> Because I don't believe anything I could do would reverse git's
> runaway-leader status.  I'm too busy to bother with futile gestures.

I didn't say you had to do anything about git's popularity. I'm just
wondering why you're putting up with a tool that you don't enjoy
yourself. It's not very hackerly-ethical to put up with tools you
consider bad but you use them just because they're popular. Why not
work on improving the tool you enjoy using?

- Jordi G. H.

Re: preferring mercurial

[Eli Zaretskii]

> Date: Fri, 10 Jan 2014 10:55:29 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Neal Becker <ndbecker2@gmail.com>, emacs-devel@gnu.org,
> 	Rüdiger Sonderfeld <ruediger@c-plusplus.de>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	"Stephen J. Turnbull" <stephen@xemacs.org>,
> 	François Orieux <orieux@iap.fr>
> 
> I'm too busy to bother with futile gestures.

Please calm down and show some goddamn respect to anyone you are
talking with here.  You have no right to treat people like that around
here.  If you have nothing useful to tell about some subject, please
consider saying nothing at all.  Especially if you think the
discussion is futile.

Thanks in advance.

Re: preferring mercurial

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I'm too busy to bother with futile gestures.

    Please calm down and show some goddamn respect to anyone you are
    talking with here.  You have no right to treat people like that around
    here.

If you think ESR was mistreating someone, I think that was a
misunderstanding.  Someone else had suggested he work on various
projects to help Mercurial become more popular.  He referred to those
suggested projects as "futile gestures" -- but that doesn't insult any
person, not even the person who suggested those projects.  His message
criticized the suggestion, not the person.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: preferring mercurial

[Jordi Gutiérrez Hermoso]

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.

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.

Re: preferring mercurial

[David Engster]

Stephen J. Turnbull writes:
> Jordi Gutiérrez Hermoso writes:
>  > > 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. 

Also note that they could have quickly fixed this with the reflog if
they would host the repository themselves and not on Github; to be fair,
Github provided the reflog pretty quick (Jenkins is a pretty popular
project...). Also, if you have direct access to the repo, you can easily
block force pushes on branches in the first place.

So if anything, this incident was more a reminder that you really should
have full control over your main repository.

-David

Re: preferring mercurial

[Jordi Gutiérrez Hermoso]

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.

Re: preferring mercurial

[Stephen J. Turnbull]

Jordi Gutiérrez Hermoso writes:

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

You don't seem to understand what the problem is.  Consider an hg repo
with 100 bookmarks, all of which suddenly point to completely
different places -- or worse, places that at a glance look like where
you should be but in fact are different.  Now figure out how to
re-associate the 100 bookmarks with the correct dangling heads.  Why
is this easier in hg than it would be in git?

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

I haven't had any trouble. <shrug/>

 > will destroy all unstaged changes.

Indeed.  But unstaged changes aren't history yet, by definition.  (And
in git staged changes are: there will be objects to match in the object
database.)

Anyway, my point has never been that git doesn't have issues, even
design bugs such as the lockless gc.  The point is that as far as DAG
manipulations go, it's easy to reason about what git will do and where
commits will be if they get lost.  Even about GC -- if multiple GC
processes are running, you're going to get corruption. :-P

But hg ... for example, don't you think it's kinda gross that hg
(including Evolve) has 3 different backup mechanisms that you've
mentioned so far (.orig, strip backup, hidden obsolete commit)?  And
there may be variations on some of them (does hg have a "git-stash"
equivalent?  which format does it use? are strip backups == bundles ==
mq patches?  if so, why the proliferation of names?  if not, how do
they differ?)  Not to forget that Mercurial has 2.5 kinds of branch
structure: bookmarks, named branches, and the special named branch
"default".)

In the case of git, you just branch.  (OK historically there was
quilt, but quilt really prexisted even bitkeeper.)  And there's only
one kind of branch structure: the transitive closure of the parent
relation for a commit.  A stash is a specialized branch.  The reflog
is a collection of specialized branches with algorithmically generated
names.  A tag is more or less a closed branch.  Tracking branches help
you keep your upstream and downstream straight.  Doing something
dangerous?  Tag or branch and work on that -- and you needn't even
fear gc.

                           ****************

I know there are a lot of people who want to blindly memorize recipes
and never think about their tools.  Mercurial is great for them.  But
every time I say "what about ..." you respond, "oh, there's a hack for
that" (and in a VCS, keeping diffs as a backup is definitely a hack).
Proliferation of special hacks makes it hard to think about such tools.

But I think that Emacs users by and large *do* think about their
tools.  Sure, Eli dislikes git and has refused to work on Bazaar.  But
that's more or less an accident: I know from other MLs that he works
on DJGPP and gdb and AFAIK neither is his job -- he could let other
people do that, too.  But he doesn't, he contributes.

Thing is, there are a lot of folks in Emacs who *do* care to think
about VCS.  Karl Fogel wrote one, for heaven's sake.  ESR clearly
thinks about VCS a lot (to the extent that he still considers himself
maintainer of vc.el).  Andreas obviously knows git inside out.  DAK
has threatened to contribute patches to git.  And that's just off the
top of my head.  You may not see a difference between the design of
git and hg, but I do, and I think Emacs developers are more likely to
make Emacs-relevant contributions to git's ecosystem than to hg's.

Re: preferring mercurial

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Jordi Gutiérrez Hermoso writes:
>
>  > 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.
>
> You don't seem to understand what the problem is.  Consider an hg repo
> with 100 bookmarks, all of which suddenly point to completely
> different places -- or worse, places that at a glance look like where
> you should be but in fact are different.  Now figure out how to
> re-associate the 100 bookmarks with the correct dangling heads.  Why
> is this easier in hg than it would be in git?
>
>  > > 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?)
>
> I haven't had any trouble. <shrug/>
>
>  > will destroy all unstaged changes.
>
> Indeed.  But unstaged changes aren't history yet, by definition.  (And
> in git staged changes are: there will be objects to match in the object
> database.)

Well, if they have not entered the reflog yet, they will be pretty hard
to dig up.  It's like handing someone a disk and saying "don't worry,
all the data is still there, only the inodes have been lost".

If we are talking about something like a private Bitcoin key (small and
very precious, hopefully identifiable), digging for it will be worth the
cost.

> DAK has threatened to contribute patches to git.

Oh, I did in the past speed up the diffing algorithm and made it use
less memory, so it's not an idle threat.

With regard to my threat of working on "git blame", I've got non-working
code doing most of the part.  I have just decided that the whole
algorithm does the wrong things in the wrong order, so fixing the
"remaining" bugs will lead to badly maintainable code of the "don't
touch this, it seems to work right now" variety.

So I am doing the core algorithm and data structures from scratch, and
that takes longer.

The problem is to stop somewhere before I rewrite all of git's
library...  But then I suffer from the "I can do better than _that_"
phenomenon pretty much every time I look too close at software written
by somebody else.  And if you don't manage to keep yourself confined to
messing with about a man*month's worth of messy code, you don't get
anywhere...

-- 
David Kastrup

Re: preferring mercurial

[Martin Geisler]

Stephen J. Turnbull <stephen <at> xemacs.org> writes:

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

Whether that is a good idea or not is debatable :)
 
> This means that git is more hackable: you can script it with shell,

Did you know that the official API for Mercurial is it's command line
interface? That means that scripting it with a shell script is not just
possible but even recommended. There are libraries for a number of languages
that gives you a higher level API:

  http://mercurial.selenic.com/wiki/CommandServer#Libraries

There are a number of "debug" commands that you can use to expose the
internal structure of the changelog, the manifests, and the filelogs (like
Git, Mercurial also stores the data in a 3-level structure.)

> you can script it with Python, you can script it with Emacs Lisp, or
> you can write C.  Bzr definitely loses big here: the internals are
> layer upon layer upon layer of complex Python API.  I don't know about
> Mercurial, haven't looked at its internals.  Git invites you to play
> with the DAG, just as Lisp invites you to play with lists.
> 
> Is this *better*?  That's a matter of taste.  But different?  Definitely.
> 
>  > Hg is cleaner, easier with better doc and ui
> 
> I disagree, but again it's a matter of taste.
> 
>  > with a bigger respect of history.
> 
> That is a lie, and you should stop repeating it, and tell people who
> try to tell it to you to stop, too.
> 
> Nothing has more respect for history than git.  Using git, you can
> forget history (by deleting or moving refs) but you can't change it or
> delete it.[1]  That's why git doesn't have backups (the way hg and bzr
> save bundles if you do a "commit --amend" or a "strip") for the
> operations that fans of other VCS call "history-changing" -- it
> doesn't need them.  History isn't *changed*, it is recreated -- and
> the original history remains accessible to the user.  AFAIK hg and bzr
> *do* destroy history when they perform operations like commit --amend,
> strip, and rebase.  For sure, git *does not*.

(Mercurial developer here.) I can assure you that Mercurial works the same
way: when you amend or rebase, you *recreate* history. It *must* work like
this since Mercurial (just like Git) uses recursive SHA-1 hashing to
determine the ID for each commit.

The old history is not destroyed, but it is currently moved out of the
repository proper -- it is moved into the bundles you mention above. That
makes it possible to restore it with 'hg pull .hg/strip-backup/your-bundle'

I agree that this is not as nice as merely hiding the old history like Git
does. It's also not as efficient since we have to move data around when
creating the bundle. This is why we're working hard on making Mercurial
*hide* the old history instead of moving it into bundles. The code is
currently in an extension that you can enable:

  http://mercurial.selenic.com/wiki/ChangesetEvolution

I've been using it for a year now and this means that all my rebased and
amended commits are still present in the repository and 'hg log --hidden'
will show them.

> It's true that you can alter the presentation of history in git
> relatively easily compared to other VCSes.  But it's possible in them,
> too, and (AFAIK) in them it does destroy original history in the
> process of remaking it.

Not 100% accurate for Mercurial today and it will be plain wrong in the future.

-- 
Martin Geisler

Re: preferring mercurial

[Martin Geisler]

Rüdiger Sonderfeld <ruediger <at> c-plusplus.de> writes:

> This has all been discussed here:
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00238.html
> 
> On Thursday 09 January 2014 07:35:22 Neal Becker wrote:
> > hg also has tortoisehg, which is a very nice mature gui.  There is nothing
> > like that for git.  I have found 1 or 2 guis that are extremely limited in
> > function.
> 
> I don't think a GUI primarily for Windows (non-free software) is going to 
> persuade GNU Emacs developers.  (And in my opinion `magit' is the best VCS 
> interface I have used so far.)

Hi,

I'm a Mercurial developer, but please don't let that scare you :) Saying
that TortoiseHg is a GUI primarily for Windows is a mistake. It is a
cross-platform Python program that runs on at least Linux, Mac OS X, and
Windows. I use it on Linux daily. It is packaged for at least Debian and
Ubuntu. See

  http://tortoisehg.bitbucket.org/download/linux.html

The confusion probably comes from the "Tortoise" prefix, which is also used
by TortoiseSVN and some other version control GUIs. I believe the other GUIs
are Windows only, and so I can understand that people who haven't looked
deeper into things would think that TortoiseHg is also just for Windows.


-- 
Martin Geisler

Re: preferring mercurial

[Yuri Khan]

On Thu, Jan 9, 2014 at 7:35 PM, Neal Becker <ndbecker2@gmail.com> wrote:
> I don't understand the git momentum.  I've use hg heavily, and am generally
> happy with it.

I use git heavily, and am happy with it. Except that I wish gitk and
git gui were more keyboard-friendly.

> Every time I have to use git, I have a terrible time.  I find it vastly more
> complicated than hg.  The docs (in the form of man pages) I find never answer my
> questions.  Each one seems to cover 100 different topics, variations and corner
> cases.  Trying to read this requires a vast new vocabulary or arcane terms.

If you want answers, read “Pro Git”, not manuals. Manuals are for when
you know what you want, just forgot some little detail.

> hg also has tortoisehg, which is a very nice mature gui.  There is nothing like
> that for git.  I have found 1 or 2 guis that are extremely limited in function.

All Tortoise-like GUIs I have seen have a fatal flaw. They start
visualizing from the space dimension (files in the tree), then you can
dig down through the context menus to the time dimension (commits in
the DAG) and the alternate-reality dimension (branches).

Gitk (and a few less featureful lookalikes, git cola, giggle) start
with the DAG, and then you can select a commit and see which files it
touches. And this helps with the big picture immensely.

Re: preferring mercurial

[Jordi Gutiérrez Hermoso]

On Thu, 2014-01-09 at 22:42 +0700, Yuri Khan wrote:
> All Tortoise-like GUIs I have seen have a fatal flaw. They start
> visualizing from the space dimension (files in the tree), then you can
> dig down through the context menus to the time dimension (commits in
> the DAG) and the alternate-reality dimension (branches).

I guess you haven't seen TortoiseHg, then:

    http://tortoisehg.bitbucket.org/img/vt_history.png
    http://www.system-tray-cleaner.com/systray/htm/wiki/images/6154317d7289dd5b402d9304084d3375.png

You click on commits then you see what's in them.

- Jordi G. H.

Re: preferring mercurial

[Barry Warsaw]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

On Jan 09, 2014, at 07:35 AM, Neal Becker wrote:

>I don't understand the git momentum.  I've use hg heavily, and am generally
>happy with it.
>
>Every time I have to use git, I have a terrible time.  I find it vastly more
>complicated than hg.  The docs (in the form of man pages) I find never answer
>my questions.  Each one seems to cover 100 different topics, variations and
>corner cases.  Trying to read this requires a vast new vocabulary or arcane
>terms.

I agree in terms of git's --help docs.  Here's a not-a-metric:

% git merge --help | wc -l
630
% bzr merge --help | wc -l
116
% hg merge --help | wc -l
35

Is it possible to be *too* helpful? :)

I highly recommend O'Reilly's book on git by Loeliger and McCullough (2nd
edition).  It has the clearest explanation of git's model that I've seen, with
nice pictures for emphasis.  As a bzr > hg > git > svn > cvs > rcs fan, I
wouldn't say the book has made me love git, but it has certainly helped me
make peace with it, to paraphrase a different post in this thread.

-Barry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]