Prefer Mercurial instead of git

Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

Please CC me in replies as I am not subscribed to this list.

I know a majority opinion lies with git due to various cultural
factors. I would, however, want to make a case for Mercurial being a
better choice for a GNU package.

Mercurial (hereafter, hg) is technically no less capable than git. It
is fast[1], featureful[2], and actively developed[3]. Technically
speaking, Mercurial is a great choice. As far as Emacs development
goes, I know magit makes a strong case for git, but there's no reason
why magit couldn't abstract away its backend and present the same UI
for git as for hg. They are almost equal on a purely technical level,
sometimes hg besting git for some features, sometimes git taking the
lead. Moreover, hg is frequently touted as being more approachable
than git[4]. We have been successfully using hg for Octave development
for the past few years, and we are very happy with it. It works very
well for us.

My main argument in favour of hg is not technical, but rather social.
For GNU, I think it is far more important to support a project that
aligns with GNU's aims, and I find git's GPLv2-only license to be a
disadvantage when contrasted with hg's GPLv2-or-later. For example,
this makes it more awkward to combine git with AGPL code, which is
something that we reasonably might want to do for web front-ends.
GPLv3 and AGPL have mutual cross-compatibility clauses with each
other, but AIUI, GPLv2-only and AGPL don't.

I also think that Matt Mackall (mpm), hg's very active lead dev, has a
friendlier position towards GNU than git's maintainers do. As a
result, hg itself is a strong defender of free software, they take
active steps to enforce the GPL, and made steps towards moving to
GPLv2+ whereas git is not going to do so. I think as a very prominent
GNU package, Emacs would do well to offer a nod to an equally
technically capable DVCS that is more aligned with GNU's goals.

Besides, I think mpm is an Emacs user himself. I think he'd be
pleased. :-)

- Jordi G. H.

[1] http://draketo.de/proj/hg-vs-git-server/test-results.html#results

    Mercurial is also faster than git at one of the frequent
    criticisms against bzr: slow clones. Try it yourself on gnulib and
    its hg mirror:

     $ time hg clone http://hg.savannah.gnu.org/hgweb/octave/gnulib-hg/
     $ time git clone http://git.savannah.gnu.org/gitweb/?p=gnulib.git

    These two are on exact the same server, so at least for this repo,
    this is a fair comparison of speed of hg vs git.

[2] http://mercurial.selenic.com/wiki/UsingExtensions#Extensions_bundled_with_Mercurial

[3] https://www.ohloh.net/p/mercurial/commits/summary

[4] http://programmers.stackexchange.com/questions/87217/why-is-mercurial-considered-to-be-easier-than-git

[5] https://

Re: Prefer Mercurial instead of git

[David Kastrup]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> My main argument in favour of hg is not technical, but rather social.
> For GNU, I think it is far more important to support a project that
> aligns with GNU's aims,

Emacs shot itself in this foot with Bzr already.

> I also think that Matt Mackall (mpm), hg's very active lead dev, has a
> friendlier position towards GNU than git's maintainers do. As a
> result, hg itself is a strong defender of free software, they take
> active steps to enforce the GPL, and made steps towards moving to
> GPLv2+ whereas git is not going to do so.

Bzr anybody?  git is developed and employed by a large community.

> I think as a very prominent GNU package, Emacs would do well to offer
> a nod to an equally technically capable DVCS that is more aligned with
> GNU's goals.

Bzr anybody?

Git is not our dream project.  But it is Free Software.  It does not
align itself with the FSF, sure, but neither do the X Window system and
a number of other products we employ.  Git's lead developer Junio
Hamano, as far as I can tell, does not indulge in the rhetorics of Linus
Torvalds either.

When we support a fringe system, we need to ask ourselves what the
long-term objectives are in return for the cost we pay in dependencies
and in keeping people from joining our project.

What are the underlying technologies?  For Git, C and shell scripting,
basically core GNU facilities.  For Mercurial, Python.  That's nicer for
developers working on Windows, but what did we write GNU for if we are
going to let our technical choices be dictated by Windows to all
eternity?

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[David Engster]

David Kastrup writes:
> Git's lead developer Junio Hamano, as far as I can tell, does not
> indulge in the rhetorics of Linus Torvalds either.

And he is an Emacs user. :-)

-David

Re: Prefer Mercurial instead of git

[Eric S. Raymond]

David Kastrup <dak@gnu.org>:
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
> > My main argument in favour of hg is not technical, but rather social.
> > For GNU, I think it is far more important to support a project that
> > aligns with GNU's aims,
> 
> Emacs shot itself in this foot with Bzr already.

+1.  And I say that as someone who *likes* hg and wishes it had won.
Repeating the bzr mistake would be stupid, stupid, *stupid*.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 11:11 +0100, David Kastrup wrote:
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
> > My main argument in favour of hg is not technical, but rather social.
> > For GNU, I think it is far more important to support a project that
> > aligns with GNU's aims,
> 
> Emacs shot itself in this foot with Bzr already.

That wasn't the problem with bzr. The problems with bzr are technical,
not social. Its *algorithms* were unsalvageable.

By the way, Mercurial made a huge effort to move from GPLv2-only to
GPLv2+. They are committed to software freedom. Emacs should reward
this commitment.
 
> > I also think that Matt Mackall (mpm), hg's very active lead dev, has a
> > friendlier position towards GNU than git's maintainers do. As a
> > result, hg itself is a strong defender of free software, they take
> > active steps to enforce the GPL, and made steps towards moving to
> > GPLv2+ whereas git is not going to do so.
> 
> Bzr anybody?  git is developed and employed by a large community.

Mercurial is not small, even if it's smaller than git. It's backed by
Atlassian, Google, Facebook, Python, GNU Octave, GNU Multiprecision
Library, GNU Health, Mozilla, Pidgin. It's lively and active.

 > When we support a fringe system,

Mercurial is not fringe. It's git's biggest contender.  It is
routinely offered as an alternative to git.
 
> What are the underlying technologies? For Git, C and shell
> scripting, basically core GNU facilities. For Mercurial, Python.
> That's nicer for developers working on Windows, but what did we
> write GNU for if we are going to let our technical choices be
> dictated by Windows to all eternity?

Python is actually nicer for everyone, not just Windows. It is far
easier to hack hg than git. mpm has better *taste* in design than
Hamano and Torvalds. You can hack hg *immediately*, with a --debugger
switch. It drops you right into hg's code. It's very nice.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[David Engster]

Jordi Gutiérrez Hermoso writes:
> On Sat, 2014-01-04 at 11:11 +0100, David Kastrup wrote:
>> Emacs shot itself in this foot with Bzr already.
>
> That wasn't the problem with bzr. The problems with bzr are technical,
> not social.

No, it is exactly the other way round. The switch happens because Bazaar
is a dead project.

> Its *algorithms* were unsalvageable.

Bazaar was quite capable of handling the Emacs source.

-David

Re: Prefer Mercurial instead of git

[Rüdiger Sonderfeld]

On Friday 03 January 2014 16:52:32 Jordi Gutiérrez Hermoso wrote:
> I know a majority opinion lies with git due to various cultural
> factors. I would, however, want to make a case for Mercurial being a
> better choice for a GNU package.

The Emacs community is largely using git.  I just checked which methods are 
used for `el-get' packages.  By far the largest are git based (git, github) 
with more than 61%.  The next largest is http (http, http-tar) with ~18%.  
Mercurial is used for less than 2% of the packages.

Many major Emacs packages already use git: Org, Gnus, AUCTeX, ESS, GNU ELPA, 
...

As you said the main arguments are social and not technical.  And the 
community is the major social asset of any free software project.  Therefore 
it seems like a bad idea to switch to anything but git.  I think Stefan 
already made it clear that it's either git or bzr.

Regards
Rüdiger

Raw data from el-get (2c93601b3c907)

((fossil . 1)
 (go . 6)
 (no-op . 2)
 (cvs . 4)
 (git-svn . 2)
 (builtin . 11)
 (ftp . 5)
 (emacsmirror . 9)
 (bzr . 10)
 ("github" . 2)
 (svn . 11)
 (hg . 17)
 (elpa . 24)
 (http . 145)
 (emacswiki . 89)
 (git . 55)
 (http-tar . 20)
 (github . 518))

I didn't count git-svn, emacsmirror for git.  And didn't check the vcs used by 
packages managed through elpa, go, or other methods.  So 62% is a rather low 
estimate.

Re: Prefer Mercurial instead of git

[David Kastrup]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On Sat, 2014-01-04 at 11:11 +0100, David Kastrup wrote:
>> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
>> 
>> > My main argument in favour of hg is not technical, but rather social.
>> > For GNU, I think it is far more important to support a project that
>> > aligns with GNU's aims,
>> 
>> Emacs shot itself in this foot with Bzr already.
>
> That wasn't the problem with bzr. The problems with bzr are technical,
> not social. Its *algorithms* were unsalvageable.

Sorry, that's just nonsense.  Algorithms can always be replaced by
better ones.  Database formats can be migrated.  It is not a technical
problem that Bazaar was essentially swallowed and privatized by
Canonical.  Its technical problems affected its user base and had an
influence on it not surpassing the critical mass for getting a vibrant
community behind it that would have rendered Canonical's power grab (and
subsequent retirement) teethless.

At any rate, I don't think we are likely to get better advice than from
Stephen Turnbull.  He is the XEmacs maintainer, and XEmacs has now used
Mercurial as its version control system for several years.

If his experience makes him lean towards Git (with which he is also
quite familiar it would seem), I consider this much more relevant than
the recommendations of insider fans of a tool.  An insider fan is nice
to have because it's usually easy to embarrass him or her into doing a
lot of work making his tool actually better fit the job.  But at one
point of time, they tire, and then the product and the underlying steady
community are more important.

And that's the sort of settled situation that XEmacs is in regarding its
use of Mercurial.  If it's Stephen's view that a second time they would
probably not do that again given the state and development of Git, and
that's more or less how I understood his comments, then that's quite
strong medicine.

There seems to be no point in ignoring extremely pertinent experience.

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 15:23 +0100, David Kastrup wrote:
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> > That wasn't the problem with bzr. The problems with bzr are technical,
> > not social. Its *algorithms* were unsalvageable.
> 
> Sorry, that's just nonsense.

I appreciate your apology, but my argument is not nonsense. 

bzr's codebase was so heavily leveraged towards bad algorithms that it
would have taken too great of an effort to fix it. Ultimately, bzr's
slow code is what really killed it. It is slow to clone, slow to show
you the log, slow to annotate a diff. Even people who tried to use bzr
for Emacs primarily complained it about being slow, and only secondly
about it being not git.

Mercurial does not have these problems.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 15:23 +0100, David Kastrup wrote:

> At any rate, I don't think we are likely to get better advice than from
> Stephen Turnbull.  He is the XEmacs maintainer, and XEmacs has now used
> Mercurial as its version control system for several years.

I don't think Stephen's a particular expert in this any more than I
am. I have used Mercurial as a GNU maintainer for Octave for many
years, and I have used git in other situations. I'm as qualified as he
may be. And I think Mercurial is a good choice, and I will choose it
again, and again.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[David Kastrup]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On Sat, 2014-01-04 at 15:23 +0100, David Kastrup wrote:
>> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
>
>> > That wasn't the problem with bzr. The problems with bzr are technical,
>> > not social. Its *algorithms* were unsalvageable.
>> 
>> Sorry, that's just nonsense.
>
> I appreciate your apology, but my argument is not nonsense.

I see no point in continuing this.  You "reply" by first cutting away
the explanation and pretend that it was not there.

If you don't feel you want to address the points I make, then there is
no point in pretending to have a discussion.

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 16:19 +0100, David Kastrup wrote:

> I see no point in continuing this. You "reply" by first cutting away
> the explanation and pretend that it was not there.

You gotta chill out, bro and try something other than git. It's nice.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[Sebastian Wiesner]

2014/1/4 Rüdiger Sonderfeld <ruediger@c-plusplus.de>:
> On Friday 03 January 2014 16:52:32 Jordi Gutiérrez Hermoso wrote:
>> I know a majority opinion lies with git due to various cultural
>> factors. I would, however, want to make a case for Mercurial being a
>> better choice for a GNU package.
>
> The Emacs community is largely using git.  I just checked which methods are
> used for `el-get' packages.  By far the largest are git based (git, github)
> with more than 61%.  The next largest is http (http, http-tar) with ~18%.
> Mercurial is used for less than 2% of the packages.
>
> Many major Emacs packages already use git: Org, Gnus, AUCTeX, ESS, GNU ELPA,
> ...
>
> As you said the main arguments are social and not technical.  And the
> community is the major social asset of any free software project.  Therefore
> it seems like a bad idea to switch to anything but git.  I think Stefan
> already made it clear that it's either git or bzr.
>
> Regards
> Rüdiger
>
> Raw data from el-get (2c93601b3c907)
>
> ((fossil . 1)
>  (go . 6)
>  (no-op . 2)
>  (cvs . 4)
>  (git-svn . 2)
>  (builtin . 11)
>  (ftp . 5)
>  (emacsmirror . 9)
>  (bzr . 10)
>  ("github" . 2)
>  (svn . 11)
>  (hg . 17)
>  (elpa . 24)
>  (http . 145)
>  (emacswiki . 89)
>  (git . 55)
>  (http-tar . 20)
>  (github . 518))
>
> I didn't count git-svn, emacsmirror for git.  And didn't check the vcs used by
> packages managed through elpa, go, or other methods.  So 62% is a rather low
> estimate.

For reference, a little grepping in the recipes of MELPA
(http://melpa.milkbox.net/) reveals a similar bias towards Git:

$ grep ':fetcher hg' * | wc -l
31
$ grep ':fetcher git' * | grep -v github | wc -l
29
$ grep ':fetcher github' * | wc -l
1186

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 17:08 +0100, Sebastian Wiesner wrote:

> For reference, a little grepping in the recipes of MELPA
> (http://melpa.milkbox.net/) reveals a similar bias towards Git:
> 
> $ grep ':fetcher hg' * | wc -l
> 31
> $ grep ':fetcher git' * | grep -v github | wc -l
> 29
> $ grep ':fetcher github' * | wc -l
> 1186

This looks like a bias towards github, not git. And this is a problem,
not something to be praised.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[David Engster]

Jordi Gutiérrez Hermoso writes:
> On Sat, 2014-01-04 at 16:19 +0100, David Kastrup wrote:
>
>> I see no point in continuing this. You "reply" by first cutting away
>> the explanation and pretend that it was not there.
>
> You gotta chill out, bro and try something other than git. It's nice.

Oh, but you are aware that we have used "something other than git" for a
few years? And that there are several people on this list who actually
happen to like Bazaar, among them the maintainer of this little project?

I can assure you that your bashing of Bazaar simply based on hearsay
won't make your praise of hg's merits more convincing.

-David

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 17:51 +0100, David Engster wrote:

> I can assure you that your bashing of Bazaar simply based on hearsay
> won't make your praise of hg's merits more convincing.

Eh, relax. Consider hg without my praise. Consider it without me.

Also, saying bzr is slow is hardly hearsay. bzr has its merits, and I
applaud the efforts to give it a nice UI efforts and its documentation
is quite good, but it's obviously not fit for Emacs. If it were, we
wouldn't be having this discussion in the first place.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[David Engster]

Jordi Gutiérrez Hermoso writes:
> bzr has its merits, and I applaud the efforts to give it a nice UI
> efforts and its documentation is quite good, but it's obviously not
> fit for Emacs. If it were, we wouldn't be having this discussion in
> the first place.

You keep repeating this, and it is still wrong. We do the switch because
Bazaar is dead.

-David

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> From: Jordi Gutiérrez Hermoso <jordigh@octave.org>
> Date: Sat, 04 Jan 2014 12:16:30 -0500
> Cc: David Kastrup <dak@gnu.org>, emacs-devel@gnu.org
> 
> [bzr is] obviously not fit for Emacs. If it were, we wouldn't be
> having this discussion in the first place.

Why we are having this discussion is explained here:

  http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html

There's nothing farther from truth than saying that bzr is not fit for
Emacs.  All of the core developers used bzr for years with no
problems.  If bzr were still actively developed and maintained, we
would probably stick to it, because the effort invested in integrating
it into our development processes is not easily tossed.

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 18:31 +0100, David Engster wrote:
> Jordi Gutiérrez Hermoso writes:
> > bzr has its merits, and I applaud the efforts to give it a nice UI
> > efforts and its documentation is quite good, but it's obviously not
> > fit for Emacs. If it were, we wouldn't be having this discussion in
> > the first place.
> 
> You keep repeating this, and it is still wrong. We do the switch because
> Bazaar is dead.

bzr dying is a consequence of its technical demerits. If it were good
code, it would survive even in the face of git's popularity, just as
hg has survived and is doing quite well.

bzr didn't die merely because of Canonical's involvement. If people
liked it enough, they would have forked it, maintained it themselves.
It's free software. It can't be "effectively privatised", like someone
else said. Darcs has failed to be popular because it was slow and
buggy (and perhaps because Haskell is much more niche and can't
attract enough developers, but I'm not so sure about this).

But hg has great architecture, is built by a kernel hacker just like
git is, it's just as fast and somtimes faster than git, and it has a
common enough programming language that it has no trouble attracting
contributors. Like I said, mpm's devotion to keeping hg free and
GNU-friendly is also a very good point in favour.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[Paul Eggert]

Eli Zaretskii wrote:
> All of the core developers used bzr for years with no
> problems.

bzr is significantly and annoyingly slower than git
in most of my use cases.  I can and have put up with it
and have gotten work done, but saying it has
"no problems" goes too far.

Re: Prefer Mercurial instead of git

[Alan Mackenzie]

On Sat, Jan 04, 2014 at 12:40:10PM -0500, Jordi Gutiérrez Hermoso wrote:
> On Sat, 2014-01-04 at 18:31 +0100, David Engster wrote:
> > Jordi Gutiérrez Hermoso writes:
> > > bzr has its merits, and I applaud the efforts to give it a nice UI
> > > efforts and its documentation is quite good, but it's obviously not
> > > fit for Emacs. If it were, we wouldn't be having this discussion in
> > > the first place.

> > You keep repeating this, and it is still wrong. We do the switch
> > because Bazaar is dead.

> bzr dying is a consequence of its technical demerits. If it were good
> code, it would survive even in the face of git's popularity, just as
> hg has survived and is doing quite well.

I think bzr was somewhat lacking in good documentation and simplicity.  I
found it quirky to use, and never got to like it, though clearly some
people do like it a lot.

git has prospered, I think, because it is used by Linux (just like C did
because it was used by Unix).

> bzr didn't die merely because of Canonical's involvement. If people
> liked it enough, they would have forked it, maintained it themselves.
> It's free software. It can't be "effectively privatised", like someone
> else said.

There seems to have been something peculiar about bzr that it died so
suddenly.  Maybe maintaining the code had become drudgery.  Normally, I'd
expect a project like that to peter out over many years rather than be
abandoned abruptly like bzr was.

> Darcs has failed to be popular because it was slow and buggy (and
> perhaps because Haskell is much more niche and can't attract enough
> developers, but I'm not so sure about this).

Darcs is still alive though, isn't it?  It would be good if Haskell
became less niche, I think.

> But hg has great architecture, is built by a kernel hacker just like
> git is, it's just as fast and somtimes faster than git, and it has a
> common enough programming language that it has no trouble attracting
> contributors. Like I said, mpm's devotion to keeping hg free and
> GNU-friendly is also a very good point in favour.

I agree with you about Mercurial.  It is vastly superior to git in terms
of documentation and simplicity; it has a single man page written in a
lively compelling style and must surely approach closely the elusive goal
of "as simple as possible but not simpler".  I selected hg for CC Mode a
couple of years ago, and don't regret the decision.

The impression I have of git (though I haven't used it) is that it is the
C++ of DVCSs - loaded up with feature after feature, many of marginal
utility.  I'd love to be mistaken on this point.  I do wonder if new
contributers to projects are ever discouraged by the difficulty of
learning git - it must be an order of magnitude more difficult to learn
to use effectively than CVS or Mercurial.

I would support changing to Mercurial (which I believe has a long life
ahead of it), but accept the sheer weight of numbers of those who like or
already use git makes this most unlikely.

> - Jordi G. H.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Prefer Mercurial instead of git

[David Kastrup]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On Sat, 2014-01-04 at 17:08 +0100, Sebastian Wiesner wrote:
>
>> For reference, a little grepping in the recipes of MELPA
>> (http://melpa.milkbox.net/) reveals a similar bias towards Git:
>> 
>> $ grep ':fetcher hg' * | wc -l
>> 31
>> $ grep ':fetcher git' * | grep -v github | wc -l
>> 29
>> $ grep ':fetcher github' * | wc -l
>> 1186
>
> This looks like a bias towards github, not git. And this is a problem,
> not something to be praised.

For reference, Jordi's blog:

<URL:http://jordi.inversethought.com/blog/enough-git/>

The starting paragraph should make clear why he is determined not to
listen to any experience or talking point from anybody regarding git:

    When in the course of human events it becomes necessary for a
    software user to disparage a thoroughly hostile DVCS, there is no
    recourse but to blog about it. Thus, software diplomacy has failed,
    and we must face the fact that I irredeemably hate git. To prove
    this, let these facts be submitted to a candid world.

I don't see that we have much to gain from indulging in his mission of
hate here.

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[Alan Mackenzie]

On Sat, Jan 04, 2014 at 07:37:25PM +0100, David Kastrup wrote:
> For reference, Jordi's blog:

> <URL:http://jordi.inversethought.com/blog/enough-git/>

> The starting paragraph should make clear why he is determined not to
> listen to any experience or talking point from anybody regarding git:

Troll.

>     When in the course of human events it becomes necessary for a
>     software user to disparage a thoroughly hostile DVCS, there is no
>     recourse but to blog about it. Thus, software diplomacy has failed,
>     and we must face the fact that I irredeemably hate git. To prove
>     this, let these facts be submitted to a candid world.

> I don't see that we have much to gain from indulging in his mission of
> hate here.

Troll.

Jordi, don't get drawn into this.  Don't feed him.  When it comes to
hating git, you have good company, namely Eli Z.

> -- 
> David Kastrup

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sat, 2014-01-04 at 19:37 +0100, David Kastrup wrote:

> For reference, Jordi's blog:
> 
> <URL:http://jordi.inversethought.com/blog/enough-git/>
[snip]
> I don't see that we have much to gain from indulging in his mission of
> hate here.

I wrote that over two years ago. I don't hate git that much anymore. I
merely think now that it has an awful UI, and I'm hardly alone in this
opinion.

Regardless, character assassination is needless. Consider Mercurial
without me. Separate your assessment of hg from your assessment of me.
I'm sure you're capable of doing this.

Chill out, bro,
- Jordi G. H.

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

[snip]

> The impression I have of git (though I haven't used it) is that it is the
> C++ of DVCSs - loaded up with feature after feature, many of marginal
> utility.

You are comparing apples to oranges. For a C++ programmer it is not
enough to know just "C with classes", he needs to master a whole lot of
features (save for the most arcane, perhaps), popular idioms and
libraries. This or the programmer is acting deceivingly if he claims to
be proficient with C++. But you can effectively use git by just knowing
a tiny part of its functionality. Nobody would accuse you of cheating if
you claim to be a git user without being aware of 98% of its features.

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

[snip]

> I don't hate git that much anymore. I merely think now that it has an
> awful UI, and I'm hardly alone in this opinion.

The UI issue is a red herring. You can work with Git from Emacs without
ever seeing git's UI, except perhaps for cloning the remote repo.

[snip]

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> Date: Sat, 04 Jan 2014 10:25:40 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Eli Zaretskii wrote:
> > All of the core developers used bzr for years with no
> > problems.
> 
> bzr is significantly and annoyingly slower than git in most of my
> use cases.

In percents, but not in absolute numbers.  It is fast enough.

And if speed is so important to you, why do you use makeinfo 5, which
is 18 times slower than its predecessor?

> I can and have put up with it and have gotten work done, but saying
> it has "no problems" goes too far.

Sorry, but I didn't mean you when I wrote the above.

Re: Prefer Mercurial instead of git

[Stefan Monnier]

> There seems to have been something peculiar about bzr that it died so
> suddenly.

Yes: it was mostly developed and maintained by Canonical employees,
during their paid time, i.e. not volunteers.  So when Canonical decided
it wasn't worth the money, the project ended up with basically noone.


        Stefan

Re: Prefer Mercurial instead of git

[Karl Fogel]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
>Please CC me in replies as I am not subscribed to this list.
>
>I know a majority opinion lies with git due to various cultural
>factors. I would, however, want to make a case for Mercurial being a
>better choice for a GNU package.

Heh.  I started the original thread largely in order to take exactly
this poll in one thread -- that's why I included this line:

>Does anyone think we should stay on bzr, or choose a VCS other than git?

However, that thread has grown to contain at least one large side
discussion, and now we have a new thread that polls separately about
Mercurial.  I suppose this was inevitable :-).

Anyway: I strongly favor Emacs choosing Git over Mercurcial.  

I've used both systems, and don't find much practical difference between
them in most development situations.  Their own maintenance communities
seem roughly equally healthy at this moment in time.  I prefer Git
simply because it is winning the popularity war, which means that:

  - When one searches the Web for help on a Git question, one is more
    likely to find the answer quickly.

  - When one seeks help directly from a person, that person is more
    likely to be a) available and b) able to answer.

  - Git is likely to be solidly maintained for decades into the future.
    I do not have quite the same faith for Mercurial, though it does
    look like it will be okay for at least a decade or so.

  - More people are developing tools to work with Git than with
    Mercurial.  (Call it the "library" advantage, by analogy with
    programming languages.)

  - Skills I develop in Git can be reinvested in more other places than
    skills I learn in Mercurial can be.

I don't see any really major technical reason to prefer either system;
my argument is just a standard positive feedback loop argument.

I'll happily use either, but if you're asking for votes, Git gets mine.

-K

Re: Prefer Mercurial instead of git

[Jay Belanger]

> For reference, Jordi's blog:
...
< <URL:http://jordi.inversethought.com/blog/enough-git/>
...
>     and we must face the fact that I irredeemably hate git. To prove
>     this, let these facts be submitted to a candid world.

You left off the facts being submitted, at least one of which (poor
documentation) is a big topic of conversation in the various emacs-devel
threads. 

> I don't see that we have much to gain from indulging in his mission of
> hate here.

He has (in his blog) stated several reasons why he doesn't like git.
I would think that hating a tool is a pretty good reason to speak out
against it, particularly if the speaker can provide a rationale to use
another tool.

Re: Prefer Mercurial instead of git

[Leo Liu]

On 2014-01-05 01:40 +0800, Jordi Gutiérrez Hermoso wrote:
> But hg has great architecture, is built by a kernel hacker just like
> git is, it's just as fast and somtimes faster than git, and it has a
> common enough programming language that it has no trouble attracting
> contributors.

#git @ freenode         949 users
#mercurial @ freenode   162 users

So I don't think hg is doing particularly well. It would be too bold to
take emacs off bzr and place it on hg.

Leo

Re: Prefer Mercurial instead of git

[Stephen J. Turnbull]

Jordi Gutiérrez Hermoso writes:

 > I don't think Stephen's a particular expert in this

I don't either.  But since I'm not an expert, why listen to me?
Listen to Barry Warsaw and Karl Fogel, who invited me to coauthor,
instead:

http://www.python.org/doc/peps/pep-0374/
http://www.emacswiki.org/BzrForEmacsDevs

And to get David K to recommend me given how often we've been at each
others' throats over the decades is a pretty good trick, one I'm proud
of.

 > And I think Mercurial is a good choice, and I will choose it again,
 > and again.

Technically, it is a good choice.  I'm not unhappy with it for XEmacs
development, although if things were moving as fast as they do in
Emacs I might sing a different tune.  Technically Bazaar was a good
choice.  As it turned out, the Bazaar developers were very good at
fixing technical problems, including using different or even new
algorithms when necessary.  But it then turned out that once they
weren't paid to do Bazaar, they stopped entirely.  I didn't expect
that, and it kills the deal, since there remain serious technical
problems that affect some users (eg, network performance).
Nevertheless, as ESR and DAK have been at pains to point out, the
problem with Mercurial, like the problem with Bazaar, isn't technical.

The problem is that Mercurial isn't git.  Git definitely is the leader
now.  Git is "cool".  Git is more flexible (neither Mercurial nor
Bazaar can support workflows that use colocated branches heavily).
Git has more growth potential: new techniques for manipulating DAGs
are developed in and for git.  (They can't be developed *in* Mercurial
or Bazaar command language, you have to go to Python level to develop
useful new features.)  Mercurial's supporting applications don't seem
to improve as quickly (at least, not those distributed with Mercurial,
cf. gitk vs. hg view).  So git is clearly winning the popularity
contest, both in general and on emacs-devel.

I actually see two features that git doesn't provide (and I don't know
how git would provide them robustly) in Bazaar (bound branches and
mainline-respecting operations).  I don't see any in Mercurial.

Mercurial's big advantage is that it's more comfortable for people who
are already used to CVS or Subversion and never want to think about
VC.  For many Emacs developers, that is an attraction.  It's not hard
to use git that way, though -- it's just that if you ask people who
use git's unique capabilities, they won't tell you about it :-/.

But like Bazaar, it's hard to see Mercurial as a starting point for
future evolution.  As applied to programming, VC is an editing task,
really.  If developing new ways of applying editing technology is what
Emacs is about, serious consideration should be given to giving up
comfort for a while.  Eg, it's hard to see how Mercurial or Bazaar
could directly support a Darcs-like patch type, but in git it's
simple: just a pair of SHA1s.  (Creating a "patch algebra" for that
would be harder; it would have to involve a subfile type so that files
become composite, just as trees are in current git -- but creating the
subfile type is trivial in git, and the submodule kludge suggests that
extending to a patch algebra might not be as hard as you'd think --
git's data structures are remarkably flexible.  Add Emacs Lisp for
creating new patch == autoedit types and wow, you might have something
new, bright! shiny!)

Also, people who think in terms of "commit" and "update" being
heavyweight (network) operations tend to insist on associating commits
with development milestones.  They deprecate git's DAG-traversing as
useless and DAG-editing as "history modification".  Nothing wrong with
that -- as long as they save their opinions for their own workflows.
Micro-commits, DAG compression, and even the much-maligned rebase all
have their place in other workflows.

Of course, as someone who frequently uses rebase, micro-commits, and
similar techniques in my own workflows, I'm biased.  But between the
growth possibilities inherent in git's simpler, more extensible
architecture, and current workflows that are difficult to impossible
to emulate with other VCSes, I think git is both technically and by
popularity the obvious choice (if Emacs is going to switch VCSes).

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sun, 2014-01-05 at 21:17 +0900, Stephen J. Turnbull wrote:
> Jordi Gutiérrez Hermoso writes:

>  > And I think Mercurial is a good choice, and I will choose it again,
>  > and again.
> 

> The problem is that Mercurial isn't git. Git definitely is the
> leader now. Git is "cool". Git is more flexible (neither Mercurial
> nor Bazaar can support workflows that use colocated branches
> heavily).

Huh, bookmarks? We use "collocated branches" heavily in GNU Octave
during our GSoC experience, and it worked just fine. Our GSoC students
were each working on their bookmark, and we've pulled their code into
mainline when it was ready. Otherwise we typically use named branches,
since it's easier for core devs to just watch at most 2 or 3 branches
at the same time over a long period of time. Both branching types have
their uses.

> Git has more growth potential: new techniques for manipulating DAGs
> are developed in and for git. (They can't be developed *in*
> Mercurial or Bazaar command language, you have to go to Python level
> to develop useful new features.)

This isn't true, Mercurial's API is its CLI (so is git's, really, but
git is bold enough to also call it a UI, which I don't think it
deserves). Its CLI is what is promised to remain stable, and you can
develop plenty of tools with its CLI only, and people do. We automate
workflows by reading and parsing its stdout. This is, for example, how
Mercurial's most popular front-end that you somehow failed to mention
works: TortoiseHg.

We could adapt magit to use hg exactly the same way. Every git command
it writes has an hg equivalent. For example, last time I checked,
magit stages hunks by creating a patch in memory and sending it to
git's stdin, this can be done in hg with something such as

    cat patch | hg qimport --name staging-area -

Writing hg extensions in Python is just a nicer choice for some
things if you happen to already like Python.

> Mercurial's supporting applications don't seem to improve as quickly
> (at least, not those distributed with Mercurial, cf. gitk vs. hg
> view).

Nobody cares that TortoiseHg isn't distributed with hg, since for many
interested people, TortoiseHg bundles hg.

> So git is clearly winning the popularity contest, both in general
> and on emacs-devel.

I don't get this argument. Windows and Mac OS X are also more popular;
does this mean we shouldn't use any other OS because all of the cool
games are almost exclusively developed on Windows?

And Mercurial, despite being less popular, *does* get a lot of toys
developed for it too. One that I like that replaces my most frequent
usage of magit is crecord: interactively select hunks for committing.

> I actually see two features that git doesn't provide (and I don't
> know how git would provide them robustly) in Bazaar (bound branches
> and mainline-respecting operations). I don't see any in Mercurial.

I'm surprised. You've been using hg this long and you haven't seen any
new features? Here are a few of hg-only features that are really cool:

   * revsets: (hg help revsets) hg supports a really cool DSL for
     querying its history. It's very rich and easy to understand.
     There's very little syntax to memorise, since it's a language
     built on simple function calls. It's far richer than what you can
     get in gitrevisions(7) The resulting queries can be used anywhere
     in the CLI where a single revision can be used.

   * Evolve and phases: This git lecture,

      http://git-scm.com/docs/git-rebase#_recovering_from_upstream_rebase

     is pointless from a pure DVCS point of view. There is nothing
     that should stop us from "rebasing" as, git calls all DAG
     modifications, upstream source. In Mercurial, it is possible to
     collaboratively edit history ("rebase", in git parlance). There
     are two tools in place for this, phases, which indicate which
     commits are "safe" to collaboratively edit, and Evolve, which
     brings forth some tools for automatically handling the conflicts
     that ensue. In Mercurial, commits carry around extra metadata
     that propagates across clones and indicates whether this commit
     has been modified upstream or not. Evolve uses this metadata for
     automatically fixing any instability that is based on the commits
     that upstream has modified.

   * Instant web interface: This one is more well-known. You can do
     "hg serve" at any time to instantly serve a particular repo over
     the web. This is supposed to be a lightweight server, so it's not
     suited to be used alone without nginx or Apache or whatever, but
     it's good enough for a quick setup between friends. The instant
     web interface is featureful enough to do most read-only hg
     operations plus it also allows pushing to the repo it's serving
     from.

There are others that are a little less impressive but just present a
nicer interface: hg's templating engine, which is both used for
presenting the hg log and for creating custom hgweb designs, being
able to push to any repo (i.e. no need for a separate bare repo type),
hg outgoing and incoming for seeing what commits will be shared before
doing any actual sharing.

My point here is that Mercurial is not short of innovation, apparently
only short of publicity. So here is some publicity.

> Eg, it's hard to see how Mercurial or Bazaar could directly support
> a Darcs-like patch type, but in git it's simple: just a pair of
> SHA1s.

I have only briefly skimmed Darcs' theory of patches. If you're
patient enough to explain to me what you hope to accomplish by
emulating it, I might enjoy thinking about how to implement it in hg.
Since hg has very similar architecture to git and you say this is easy
in git, I am certain this is feasible.

> Also, people who think in terms of "commit" and "update" being
> heavyweight (network) operations tend to insist on associating
> commits with development milestones. They deprecate git's
> DAG-traversing as useless and DAG-editing as "history modification".

No, hg has a lot of ability to modify history or traverse the DAG, as
you call it.

> Of course, as someone who frequently uses rebase, micro-commits, and
> similar techniques in my own workflows, I'm biased.

Apparently you're not using them in Mercurial? 

    hg commit --amend
    hg histedit -r .~3
    hg update -r @
    hg rebase -b myseries
    hg crecord

Do you know what these tools do? Is there a reason why you don't use
them, if you really are not?

> But between the growth possibilities inherent in git's simpler, more
> extensible architecture, and current workflows that are difficult to
> impossible to emulate with other VCSes, I think git is both
> technically and by popularity the obvious choice (if Emacs is going
> to switch VCSes).

Of course I don't dispute that git is more popular, but I do contend
that hg is not as small as bzr, and its development status is much
more healthy than bzr's. It's also not as obscure as bzr, and given
the amount of money that is being pumped into it by several commercial
entities,

    http://mercurial.selenic.com/sponsors/

fears of something like what Canonical did to bzr seem unfounded to
me.

Mercurial is a good choice, despite being less popular than git.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[Florian Weimer]

* Jordi Gutiérrez Hermoso:

> On Sun, 2014-01-05 at 21:17 +0900, Stephen J. Turnbull wrote:
>> The problem is that Mercurial isn't git. Git definitely is the
>> leader now. Git is "cool". Git is more flexible (neither Mercurial
>> nor Bazaar can support workflows that use colocated branches
>> heavily).
>
> Huh, bookmarks? We use "collocated branches" heavily in GNU Octave
> during our GSoC experience, and it worked just fine. Our GSoC students
> were each working on their bookmark, and we've pulled their code into
> mainline when it was ready.

Back when I needed this the last time, I couldn't find documentation
how bookmarks interacted with merging.  It also wasn't entirely clear
to me how to prepare the final patch useful for submitting it upstream
(I wasn't a committer, and it had to be a single, flattened patch).

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sun, 2014-01-05 at 14:25 +0100, Florian Weimer wrote:
> * Jordi Gutiérrez Hermoso:
> 
> > On Sun, 2014-01-05 at 21:17 +0900, Stephen J. Turnbull wrote:
> >> The problem is that Mercurial isn't git. Git definitely is the
> >> leader now. Git is "cool". Git is more flexible (neither Mercurial
> >> nor Bazaar can support workflows that use colocated branches
> >> heavily).
> >
> > Huh, bookmarks? We use "collocated branches" heavily in GNU Octave
> > during our GSoC experience, and it worked just fine. Our GSoC students
> > were each working on their bookmark, and we've pulled their code into
> > mainline when it was ready.
> 
> Back when I needed this the last time, I couldn't find documentation
> how bookmarks interacted with merging.

The term you want is "divergent bookmark", I think:

    http://mercurial.aragost.com/kick-start/en/bookmarks/#divergent-bookmarks

> It also wasn't entirely clear to me how to prepare the final patch
> useful for submitting it upstream (I wasn't a committer, and it had
> to be a single, flattened patch).

You can use hg histedit to fold your commits into one. Then you can
use hg export to get a diff with enough metadata to recreate your
commit in another hg clone.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[David Kastrup]

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

> Jordi Gutiérrez Hermoso writes:
>
>  > I don't think Stephen's a particular expert in this
>
> I don't either.  But since I'm not an expert, why listen to me?
> Listen to Barry Warsaw and Karl Fogel, who invited me to coauthor,
> instead:
>
> http://www.python.org/doc/peps/pep-0374/
> http://www.emacswiki.org/BzrForEmacsDevs
>
> And to get David K to recommend me given how often we've been at each
> others' throats

Locking horns.  Different thing.

> over the decades is a pretty good trick, one I'm proud of.

<URL:http://drmcninja.com/archives/comic/21p97/>

> Nevertheless, as ESR and DAK have been at pains to point out, the
> problem with Mercurial, like the problem with Bazaar, isn't technical.
>
> The problem is that Mercurial isn't git.  Git definitely is the leader
> now.  Git is "cool".  Git is more flexible (neither Mercurial nor
> Bazaar can support workflows that use colocated branches heavily).
> Git has more growth potential: new techniques for manipulating DAGs
> are developed in and for git.  (They can't be developed *in* Mercurial
> or Bazaar command language, you have to go to Python level to develop
> useful new features.)  Mercurial's supporting applications don't seem
> to improve as quickly (at least, not those distributed with Mercurial,
> cf. gitk vs. hg view).  So git is clearly winning the popularity
> contest, both in general and on emacs-devel.

There is actually another problem here: with regard to Software Freedom,
Git is in the "good enough" category.  People are comfortable using it.
And that's something which, in the big order of things, we should
consider as a win.  However, services like Github try locking people
into their proprietary services.  And are succeeding.  The software
Github runs on is proprietary, and the usage conditions are pretty
onerous.  Yes, one can pull repositories from them, but the entire other
workflow they offer to users is locked down.

Of course, it is the Facebook effect at work again: if you build a
_business_ model around gratis services, your product is not the
service, but the users.

The tool Git itself does not care what it is used for, and Git upstream
is also not overly interested as long as the conditions on Git itself
are kept.

The Git universe is unlike the Windows universe: it does not strongly
prefer proprietary thinking and workflows.

And yet we do try to bring the value of freedom also to Windows users,
like when providing Emacs.

I think there is more at stake by turning the back on Git.  It is too
important as a free tool to let the proprietary vendors determine the
directions how "everybody" is going to use it, under their control, with
their ultimate weapon: convenience.

If we don't offer answers of our own, we forfeit the game.  There are
games which are loaded against us anyway, where there is little point in
playing to lose.  But this one's right at our door.

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> We could adapt magit to use hg exactly the same way.

Why do you insist on mentioning Magit? Its interface is modeled on git's
characteristic features (index, remotes, etc) Adapting it for hg would
require a huge rewrite. You'll better write your own package from
scratch.

Do you have Magit-envy? ;-)

> Every git command
> it writes has an hg equivalent. For example, last time I checked,
> magit stages hunks by creating a patch in memory and sending it to
> git's stdin, this can be done in hg with something such as
>
>     cat patch | hg qimport --name staging-area -

So you can somehow emulate a poor-man's git stage with hg. Good. But why
should hg users interested on that? Do they have git-envy too?

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sun, 2014-01-05 at 16:38 +0100, Óscar Fuentes wrote:
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
> > We could adapt magit to use hg exactly the same way.
> 
> Why do you insist on mentioning Magit?

Because it's frequently loved and other people mention it as an
advantage to using git with Emacs.

>  Its interface is modeled on git's characteristic features (index,

hg queues

> remotes,

hg paths

> etc)

hg etc

> Adapting it for hg would require a huge rewrite. You'll better write
> your own package from scratch.

I spoke with Sigma a while ago in #emacs (he was or is a big magit
contributor, I can't recall his actual name), and he think it's
feasible to abstract away the git part of magit and use it as an
interface for git and hg. Magit would hardly be the first of its kind
to abstract away git and hg. Kiln Harmony has also done this, as has,
for example, Phabricator.

> Do you have Magit-envy? ;-)

Not really. I'm trying to appeal to git Emacs users.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 04 Jan 2014 20:30:04 +0100
> 
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
> [snip]
> 
> > I don't hate git that much anymore. I merely think now that it has an
> > awful UI, and I'm hardly alone in this opinion.
> 
> The UI issue is a red herring. You can work with Git from Emacs without
> ever seeing git's UI, except perhaps for cloning the remote repo.

Not entirely a red herring, because the Emacs front-ends only support
a small fraction of the available commands.  A cursory look into
vc-git.el indicates that it uses about 10% to 20% of the git
commands.  Magit does better: 1/4th tgo 1/3rd, but still most of the
commands are not supported.

Granted, what the front-ends support are the most important and
frequently used commands.  But the rest are still useful and need to
be used from time to time, especially since they allow to do so much.
Which means that one still needs to learn and understand the CLI
syntax and the myriad of the options.

Re: Prefer Mercurial instead of git

[Eric S. Raymond]

Jordi Gutiérrez Hermoso <jordigh@octave.org>:
> I spoke with Sigma a while ago in #emacs (he was or is a big magit
> contributor, I can't recall his actual name), and he think it's
> feasible to abstract away the git part of magit and use it as an
> interface for git and hg. Magit would hardly be the first of its kind
> to abstract away git and hg. Kiln Harmony has also done this, as has,
> for example, Phabricator.

Not to mention VC mode, in which I busted a very similar move - in 1992 :-).
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Prefer Mercurial instead of git

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> Not entirely a red herring, because the Emacs front-ends only support
> a small fraction of the available commands.  A cursory look into
> vc-git.el indicates that it uses about 10% to 20% of the git
> commands.

My goal in designing VC way back when was to capture the common
features of common workflows across multiple VCSes - where originally
in 1992 "multiple" meant SCCS and RCS.  I was very focused on having a
single command do the next logical thing in the checkout-edit-checkin
cycle.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The UI issue is a red herring. You can work with Git from Emacs without
>> ever seeing git's UI, except perhaps for cloning the remote repo.
>
> Not entirely a red herring, because the Emacs front-ends only support
> a small fraction of the available commands.  A cursory look into
> vc-git.el indicates that it uses about 10% to 20% of the git
> commands.  Magit does better: 1/4th tgo 1/3rd, but still most of the
> commands are not supported.
>
> Granted, what the front-ends support are the most important and
> frequently used commands.  But the rest are still useful and need to
> be used from time to time, especially since they allow to do so much.
> Which means that one still needs to learn and understand the CLI
> syntax and the myriad of the options.

This "all-embracing" view is flawed for Git, is flawed for Emacs and is
flawed for a microwave oven. Furthermore, it is counterproductive.

The fact that some feature or command-line switch exists on git doesn't
mean that you "need to know it because it is useful". Supposing that
they are useful for *your use case*, it might not be time-effective to
learn and memorize that feature. I'm happily and efficaciously using git
from several years now and there are entire areas which are completely
unknown for me.

So mentioning the complexity of git when, in practice, you just need a
few minutes tutorial to use it with Magit and less than an hour for
adquiring a sound knowledge of its architecture (which allows a more
effective learning and usage), is a red herring, indeed.

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> Date: Sun, 5 Jan 2014 11:46:54 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org>:
> > Not entirely a red herring, because the Emacs front-ends only support
> > a small fraction of the available commands.  A cursory look into
> > vc-git.el indicates that it uses about 10% to 20% of the git
> > commands.
> 
> My goal in designing VC way back when was to capture the common
> features of common workflows across multiple VCSes - where originally
> in 1992 "multiple" meant SCCS and RCS.  I was very focused on having a
> single command do the next logical thing in the checkout-edit-checkin
> cycle.

Yes, and that's a good goal.  My point is that it necessarily leaves
the less common commands out of scope, and thus CLI usage is still
needed sometimes.

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On Sun, 2014-01-05 at 16:38 +0100, Óscar Fuentes wrote:
>> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
>> 
>> > We could adapt magit to use hg exactly the same way.
>> 
>> Why do you insist on mentioning Magit?
>
> Because it's frequently loved and other people mention it as an
> advantage to using git with Emacs.

So you are mentioning *current* Emacs/git productivity tools as a bait
for fishing *git users* and gaining them for the hg cause because those
tools *could* be adapted to hg?

>>  Its interface is modeled on git's characteristic features (index,
>
> hg queues
>
>> remotes,
>
> hg paths
>
>> etc)
>
> hg etc

No, thanks, I prefer the real thing.

>> Adapting it for hg would require a huge rewrite. You'll better write
>> your own package from scratch.
>
> I spoke with Sigma a while ago in #emacs (he was or is a big magit
> contributor, I can't recall his actual name), and he think it's
> feasible to abstract away the git part of magit and use it as an
> interface for git and hg.

Sure, and with a bit more of work it could be adapted to RCS too :-)

If you would be happy working with a hg-based Magit, why should you
object to working with a git-based Magit, once Emacs switches to git?

> Magit would hardly be the first of its kind
> to abstract away git and hg. Kiln Harmony has also done this, as has,
> for example, Phabricator.
>
>> Do you have Magit-envy? ;-)
>
> Not really. I'm trying to appeal to git Emacs users.

Have you considered the possibility that those users could be so
attached to git/Emacs as you can be to hg/Emacs? As git does the work
for me, why should I invest time on learning another tool that adds
*nothing* to my productivity?

But the issue here, as others already told you several times, is not
about which tool is best from the technical POV (both hg and git are
good enough, each with its own strong and weak points) but about
choosing the most popular and future-proof option. From this POV, going
with hg would be repeating the bzr mistake (well, not as bad, but a
mistake anyways.)

Re: Prefer Mercurial instead of git

[Sebastian Wiesner]

Am 04.01.2014 17:41 schrieb "Jordi Gutiérrez Hermoso" <jordigh@octave.org>:
>
> On Sat, 2014-01-04 at 17:08 +0100, Sebastian Wiesner wrote:
>
> > For reference, a little grepping in the recipes of MELPA
> > (http://melpa.milkbox.net/) reveals a similar bias towards Git:
> >
> > $ grep ':fetcher hg' * | wc -l
> > 31
> > $ grep ':fetcher git' * | grep -v github | wc -l
> > 29
> > $ grep ':fetcher github' * | wc -l
> > 1186
>
> This looks like a bias towards github, not git. And this is a problem,
> not something to be praised.

Oh dear.  I didn't praise anything.  I simply provided data about the
popularity of Git and Mercurial within the community of  independent
Emacs developers, which indicates that Git is by far the most popular
DVCS among these developers.  That's a fact, like it or not.

I didn't make any judgement as to whether this is good or bad, or even
relevant at all. Do whatever you want with it.

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 05 Jan 2014 17:52:43 +0100
> 
> The fact that some feature or command-line switch exists on git doesn't
> mean that you "need to know it because it is useful". Supposing that
> they are useful for *your use case*, it might not be time-effective to
> learn and memorize that feature. I'm happily and efficaciously using git
> from several years now and there are entire areas which are completely
> unknown for me.
> 
> So mentioning the complexity of git when, in practice, you just need a
> few minutes tutorial to use it with Magit and less than an hour for
> adquiring a sound knowledge of its architecture (which allows a more
> effective learning and usage), is a red herring, indeed.

If we are supposed to restrict ourselves to what VC or Magit offer,
then why do we need to switch to git?  One of the main reasons, we are
told, is that git is so powerful, and can be used to do jobs that bzr
users can only dream about.  Why do you want me to artificially
restrain myself from learning those powerful features and using them
to my benefit?

IOW, a change in a major development tool is not an easy decision
precisely _because_ it requires one to learn the new tool, and learn
it thoroughly.  Otherwise, the switch is a waste of energy.  Saying
that the complexity is a red herring because one should simply
disregard the complex and the powerful features makes very little
sense to me.  Would you suggest that someone uses Emacs as a fancy
Notepad, just because the rest is not really needed?  I doubt that.

Now, I didn't mean, of course, that one must familiarize oneself with
all the commands and options.  But the key concepts, the "soul" of the
tool, its basic principles of operation and its philosophy -- without
learning that, you will never be able to use that one command that
solves a particular problem, when you need that.

Re: Prefer Mercurial instead of git

[Stephen J. Turnbull]

Jordi Gutiérrez Hermoso writes:

 > Mercurial is a good choice,

Which is the first thing that *I* wrote about it.  Hm?

 > despite being less popular than git.

Still, it's not as good a choice as git, *because* it's less popular
than git, in particular, among Emacs developers.  You could argue that
at least three very senior developers (if RMS isn't the third,
*somebody* will appear :-) prefer bzr, and might very well prefer hg,
and that's more important than mere numbers.  I can't refute that
argument, but I sure can, and do, disagree with the conclusion.

I have a bunch of further comments on the specifics of Jordi's post,
but they're off-topic for now, so I'm replying to him directly.

Interested parties, let one of us know.

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> If we are supposed to restrict ourselves to what VC or Magit offer,
> then why do we need to switch to git?  One of the main reasons, we are
> told, is that git is so powerful, and can be used to do jobs that bzr
> users can only dream about.

I don't think that that is "one of the main reasons."

The "main reasons" is that bzr is dying, learning it is a hurdle for new
contributors and most Emacs contributors use something else for the
other projects they work on.

Choosing git was, simply, the result of a popularity contest.

> Why do you want me to artificially restrain myself from learning those
> powerful features and using them to my benefit?

You are free to use whatever you like and do the amount of learning
effort that pleases you, of course. What I dispute is your implicit
claim of "git is complex, not-so-well documented and has a not-so-good
UI, hence learning it will be hard." For Eli's definition of "learning",
the claim may be true. For somebody else's definition of "learning",
it is not. Not everyone is interested on a thorough study of the tool
"just in case" when some simple instructions are enough to incorporate
their edits into Emacs' repository.

> IOW, a change in a major development tool is not an easy decision
> precisely _because_ it requires one to learn the new tool, and learn
> it thoroughly.  Otherwise, the switch is a waste of energy.  Saying
> that the complexity is a red herring because one should simply
> disregard the complex and the powerful features makes very little
> sense to me.  Would you suggest that someone uses Emacs as a fancy
> Notepad, just because the rest is not really needed?  I doubt that.
>
> Now, I didn't mean, of course, that one must familiarize oneself with
> all the commands and options.  But the key concepts, the "soul" of the
> tool, its basic principles of operation and its philosophy

This paragraph reflects my POV, but somehow contradicts the previous
one.

> -- without learning that, you will never be able to use that one
> command that solves a particular problem, when you need that.

For those cases, a web search will quickly provide the solution. One
advantage of belonging to a huge user base is that somebody, somewhere,
had your same problem on the past, and helpful experts abound.

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 05 Jan 2014 18:55:26 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If we are supposed to restrict ourselves to what VC or Magit offer,
> > then why do we need to switch to git?  One of the main reasons, we are
> > told, is that git is so powerful, and can be used to do jobs that bzr
> > users can only dream about.
> 
> I don't think that that is "one of the main reasons."
> 
> The "main reasons" is that bzr is dying, learning it is a hurdle for new
> contributors and most Emacs contributors use something else for the
> other projects they work on.
> 
> Choosing git was, simply, the result of a popularity contest.

Maybe we have read two different discussions in two different forums.
My reading of it was that the popularity was explained by power and
flexibility that are unmatched by competition.

> What I dispute is your implicit claim of "git is complex,
> not-so-well documented and has a not-so-good UI, hence learning it
> will be hard."

Did I say that?  I only responded to your assertion that the UI is a
red herring, that's all.

> For Eli's definition of "learning", the claim may be true. For
> somebody else's definition of "learning", it is not. Not everyone is
> interested on a thorough study of the tool "just in case" when some
> simple instructions are enough to incorporate their edits into
> Emacs' repository.

I wonder how many of git enthusiasts think that way.  My impression
was that most, if not all of them think like me: that git is worthy of
being mastered.

> For those cases, a web search will quickly provide the solution. One
> advantage of belonging to a huge user base is that somebody, somewhere,
> had your same problem on the past, and helpful experts abound.

Do you act this way with Emacs, too?

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Choosing git was, simply, the result of a popularity contest.
>
> Maybe we have read two different discussions in two different forums.
> My reading of it was that the popularity was explained by power and
> flexibility that are unmatched by competition.

That, naturally, is the opinion of git proponents.

Certainly, neither RMS nor Stefan are giving the OK to the switch
because they agree with them.

>> What I dispute is your implicit claim of "git is complex,
>> not-so-well documented and has a not-so-good UI, hence learning it
>> will be hard."
>
> Did I say that?

I think that that is precisely the message a bystander could get.

> I only responded to your assertion that the UI is a
> red herring, that's all.
>
>> For Eli's definition of "learning", the claim may be true. For
>> somebody else's definition of "learning", it is not. Not everyone is
>> interested on a thorough study of the tool "just in case" when some
>> simple instructions are enough to incorporate their edits into
>> Emacs' repository.
>
> I wonder how many of git enthusiasts think that way.  My impression
> was that most, if not all of them think like me: that git is worthy of
> being mastered.

Whatever git enthusiasts think about the worthiness of thoroughly
learning git is irrelevant for the transition. The important point is:
"how hard it will be for Emacs hackers that don't know git to keep
contributing?."

>> For those cases, a web search will quickly provide the solution. One
>> advantage of belonging to a huge user base is that somebody, somewhere,
>> had your same problem on the past, and helpful experts abound.
>
> Do you act this way with Emacs, too?

Yes, mostly, although Emacs is not the same case. Emacs is an aggregate
of packages, while Git is largely monolithic. Most Emacs packages have a
very small user base.

There exists no Emacs experts on the same sense that there are Git or
C++ experts (i.e. somebody who quickly can provide an authoritative
answer to almost any question pertaining the subject matter.)

Re: Prefer Mercurial instead of git

[Sean Sieger]

    You are free to use whatever you like and do the amount of learning
    effort that pleases you, of course. What I dispute is your implicit
    claim of "git is complex, not-so-well documented and has a not-so-good
    UI, hence learning it will be hard." For Eli's definition of "learning",
    the claim may be true. For somebody else's definition of "learning",
    it is not. Not everyone is interested on a thorough study of the tool
    "just in case" when some simple instructions are enough to incorporate
    their edits into Emacs' repository.

There is a connection between the scope of ones knowledge and the scope
of ones contribution.

    For those cases, a web search will quickly provide the solution. One
    advantage of belonging to a huge user base is that somebody, somewhere,
    had your same problem on the past, and helpful experts abound.

Precisely, but the experts do not abound; the Eli Zaretskiis are rare.

Re: Prefer Mercurial instead of git

[Dov Feldstern]

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

> 
> Jordi Gutiérrez Hermoso writes:
> 
>  > Mercurial is a good choice,
> 
> Which is the first thing that *I* wrote about it.  Hm?
> 
>  > despite being less popular than git.
> 
> Still, it's not as good a choice as git, *because* it's less popular
> than git, in particular, among Emacs developers.  You could argue that
> at least three very senior developers (if RMS isn't the third,
> *somebody* will appear  prefer bzr, and might very well prefer hg,
> and that's more important than mere numbers.  I can't refute that
> argument, but I sure can, and do, disagree with the conclusion.
> 
> I have a bunch of further comments on the specifics of Jordi's post,
> but they're off-topic for now, so I'm replying to him directly.
> 
> Interested parties, let one of us know.
> 
> 

I'm interested.

Hats off to Jordi for his masterful job in support of mercurial!

I am not an emacs dev, so I have no real right chiming in here. OTOH, this 
kind of decision being discussed on the public mailing list of a high-
profile project like emacs (high-profile enough to make slashdot, anyway :P 
) probably has an influence that is wider than just emacs, and so I'm 
allowing myself to post this anyway...

I realize that for emacs the choice has all but been made in favor of git, 
and certainly there are plenty of valid reasons for such a decision. But I 
still find it a little sad to see quite a few people here feeling compelled 
to choose git because of its popularity, despite their preference for 
mercurial...

I don't have anything of substance to add to the discussion -- again, I 
think that Jordi has done a wonderful job presenting the merits of 
mercurial. However, since popularity seems to be such an important measure, 
I just wanted to register one more vote in favor of mercurial. :)

Dov

Re: Prefer Mercurial instead of git

[Karl Fogel]

Dov Feldstern <dovdevel@gmail.com> writes:
>I realize that for emacs the choice has all but been made in favor of git, 
>and certainly there are plenty of valid reasons for such a decision. But I 
>still find it a little sad to see quite a few people here feeling compelled 
>to choose git because of its popularity, despite their preference for 
>mercurial...

Oh, it's not "compelled" any more than any other aspect of this choice
is.  Network effects are a technical reason too, in the end :-).

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Sun, 2014-01-05 at 18:09 +0100, Óscar Fuentes wrote:
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
> > On Sun, 2014-01-05 at 16:38 +0100, Óscar Fuentes wrote:
> >> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> >> 
> >> > We could adapt magit to use hg exactly the same way.
> >> 
> >> Why do you insist on mentioning Magit?
> >
> > Because it's frequently loved and other people mention it as an
> > advantage to using git with Emacs.
> 
> So you are mentioning *current* Emacs/git productivity tools as a bait
> for fishing *git users* and gaining them for the hg cause because those
> tools *could* be adapted to hg?

Sure, same reason, really, that I work on GNU Octave. You wouldn't
suggest I stop working on Octave and tell everyone to just buy
expensive Matlab licenses instead?

I had written a reply to the rest of your email, but I decided that I
didn't enjoy your tone because it made me mean and unpleasant. I hope
you'll forgive me that I deleted the rest of my response and spared us
both further unpleasant conversation.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[Dov Feldstern]

On Mon, Jan 6, 2014 at 1:23 AM, Karl Fogel <kfogel@red-bean.com> wrote:
>
> Dov Feldstern <dovdevel@gmail.com> writes:
> >I realize that for emacs the choice has all but been made in favor of git,
> >and certainly there are plenty of valid reasons for such a decision. But I
> >still find it a little sad to see quite a few people here feeling compelled
> >to choose git because of its popularity, despite their preference for
> >mercurial...
>
> Oh, it's not "compelled" any more than any other aspect of this choice
> is.  Network effects are a technical reason too, in the end :-).

By "compelled" I mean "compelled by circumstances", I'm not hinting at
coercion of any sort... and I agree that network effects are real, and
a valid consideration (though I'd consider them to be second-order).

Re: Prefer Mercurial instead of git

[David Kastrup]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> On Sun, 2014-01-05 at 16:38 +0100, Óscar Fuentes wrote:
>> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
>> 
>> > We could adapt magit to use hg exactly the same way.
>> 
>> Why do you insist on mentioning Magit?
>
> Because it's frequently loved and other people mention it as an
> advantage to using git with Emacs.

Just because I prefer shaving with a knife does not mean that I would
recommend to Chinese people to try shaving with chopsticks.

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

> IOW, a change in a major development tool is not an easy decision
> precisely _because_ it requires one to learn the new tool, and learn
> it thoroughly.  Otherwise, the switch is a waste of energy.  Saying
> that the complexity is a red herring because one should simply
> disregard the complex and the powerful features makes very little
> sense to me.

Git does an excellent job on the VC subset, so this is less absurd than
it may seem to you.  It's quite good and fast at merging and cranking
out log and annotation files.

> Would you suggest that someone uses Emacs as a fancy Notepad, just
> because the rest is not really needed?  I doubt that.

If Notepad deals badly with R2L text, overlong lines and other stuff I
want to be working with, Emacs will be preferable even for Notepad-level
work.

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[David Kastrup]

Sebastian Wiesner <lunaryorn@gmail.com> writes:

> Am 04.01.2014 17:41 schrieb "Jordi Gutiérrez Hermoso" <jordigh@octave.org>:
>>
>> On Sat, 2014-01-04 at 17:08 +0100, Sebastian Wiesner wrote:
>>
>> > For reference, a little grepping in the recipes of MELPA
>> > (http://melpa.milkbox.net/) reveals a similar bias towards Git:
>> >
>> > $ grep ':fetcher hg' * | wc -l
>> > 31
>> > $ grep ':fetcher git' * | grep -v github | wc -l
>> > 29
>> > $ grep ':fetcher github' * | wc -l
>> > 1186
>>
>> This looks like a bias towards github, not git. And this is a problem,
>> not something to be praised.
>
> Oh dear.  I didn't praise anything.  I simply provided data about the
> popularity of Git and Mercurial within the community of  independent
> Emacs developers, which indicates that Git is by far the most popular
> DVCS among these developers.  That's a fact, like it or not.
>
> I didn't make any judgement as to whether this is good or bad, or even
> relevant at all. Do whatever you want with it.

Actually, I agree with Jordi that the bias towards Github, a rather
proprietary service, is a problem.  We are not going to solve that
problem by leaving Git alone.

-- 
David Kastrup

Re: Prefer Mercurial instead of git

[Rostislav Svoboda]

Is anybody out there able to convert this "git vs. hg" discussion from
feelings into numbers?

Re: Prefer Mercurial instead of git

[Karl Fogel]

Rostislav Svoboda <rostislav.svoboda@gmail.com> writes:
>Is anybody out there able to convert this "git vs. hg" discussion from
>feelings into numbers?

I've been saving all the messages, and would have bothered to count if
it weren't so obviously leaning heavily toward git (I've been keeping an
informal count as I see the messages go by).  If someone really feels we
need the numbers, they are in the archives -- "just add labor" :-).  But
most people seem to be talking as though git is already the obvious
winner, and I think they're doing that based on the same informal count.

-K

Re: Prefer Mercurial instead of git

[Óscar Fuentes]

Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:

> Sure, same reason, really, that I work on GNU Octave. You wouldn't
> suggest I stop working on Octave and tell everyone to just buy
> expensive Matlab licenses instead?

Hmmm...

Mercurial == Octave (Free Software, done for the benefit of all);

Git == Mathematica (Expensive, exclusive, greed-driven software)

Got it.

Re: Prefer Mercurial instead of git

[Jordi Gutiérrez Hermoso]

On Mon, 2014-01-06 at 01:38 +0100, Óscar Fuentes wrote:
> Jordi Gutiérrez Hermoso <jordigh@octave.org> writes:
> 
> > Sure, same reason, really, that I work on GNU Octave. You wouldn't
> > suggest I stop working on Octave and tell everyone to just buy
> > expensive Matlab licenses instead?
> 
> Hmmm...
> 
> Mercurial == Octave (Free Software, done for the benefit of all);
> 
> Git == Mathematica (Expensive, exclusive, greed-driven software)
> 
> Got it.

Please attempt to be a bit more charitable than that:

    https://en.wikipedia.org/wiki/Principle_of_charity

My point was that attempting to emulate git features in hg in order to
attract git users is a ultimately good thing, not something worth of
mockery. I think hg has other benefits beyond what git can
offer, but if git users won't even touch it because it doesn't have
their pet feature, then they also won't see hg's other features. Thus,
it's a good thing to offer reasonable accomodations for git users in
hg, and these accomodations already exist for many things.

- Jordi G. H.

Re: Prefer Mercurial instead of git

[Jay Belanger]

> If someone really feels we need the numbers, they are in the archives
> -- "just add labor" :-).

That would just tell you who was the loudest, not which choice was
preferred by most people.  I suspect it wouldn't matter, but if numbers
are wanted, I think some sort of formal vote should be taken.  Of
course, maybe numbers aren't necessary; Stefan may just want to hear the
discussion and decide what to do.  Or maybe he already has.

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 06 Jan 2014 01:12:31 +0100
> 
> > Would you suggest that someone uses Emacs as a fancy Notepad, just
> > because the rest is not really needed?  I doubt that.
> 
> If Notepad deals badly with R2L text, overlong lines and other stuff I
> want to be working with

It doesn't.

Re: Prefer Mercurial instead of git

[Stephen J. Turnbull]

Dov Feldstern writes:

 > By "compelled" I mean "compelled by circumstances", I'm not hinting at
 > coercion of any sort... and I agree that network effects are real, and
 > a valid consideration (though I'd consider them to be second-order).

They are, indeed, typically characterized by a second-order polynomial
with a positive coefficient on the quadratic term.

In other words, we have O(N^2) *benefits*.

:-)

Re: Prefer Mercurial instead of git

[Darren Hoo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 04 Jan 2014 10:25:40 -0800
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> 
>> Eli Zaretskii wrote:
>> > All of the core developers used bzr for years with no
>> > problems.
>> 
>> bzr is significantly and annoyingly slower than git in most of my
>> use cases.
>
> In percents, but not in absolute numbers.  It is fast enough.
>
> And if speed is so important to you, why do you use makeinfo 5, which
> is 18 times slower than its predecessor?
>
>> I can and have put up with it and have gotten work done, but saying
>> it has "no problems" goes too far.
>
> Sorry, but I didn't mean you when I wrote the above.

I know you are the core developer. (I am a little sensitive to this
word, as in China dictators of our country like to force their people to
call them the "core" leader).

But since when Stefan, Glenn and Chong Yidong became not the core
developers of Emacs?

http://lists.gnu.org/archive/html/emacs-devel/2012-11/msg00235.html

https://bugs.launchpad.net/bzr/+bug/937101

Re: Prefer Mercurial instead of git

[grischka]

Alan Mackenzie wrote:
> I do wonder if new contributers to projects are ever discouraged by 
> the difficulty of learning git - it must be an order of magnitude 
> more difficult to learn to use effectively than CVS or Mercurial.

FWIW, at http://repo.or.cz/w/tinycc.git we allow pushes for
everybody without registration, and while we had quite some
such contributions we didn't see a single git question on the
mailing list nor any mess in the repo over the years ever.

Beyond that these people almost never seem to write bad patches,
and eventually are lazy to explain what they are doing.  Maybe
by incident, maybe not.

--- grischka

Re: Prefer Mercurial instead of git

[Stefan Monnier]

> I know you are the core developer.
                 ^^^
                  a

-- Stefan

Re: Prefer Mercurial instead of git

[Karl Fogel]

Jay Belanger <jay.p.belanger@gmail.com> writes:
>That would just tell you who was the loudest, not which choice was
>preferred by most people.  I suspect it wouldn't matter, but if numbers
>are wanted, I think some sort of formal vote should be taken.

My intention with my "PROPOSAL:" mail was to gather those numbers; I
think those people followed up with a "+1" (or the opposite) grokked
that intention.

So the numbers in that thread be gathered accurately without regard to
who's loudest -- we don't count someone twice just because they posted
twice.  Now, it may not have been clear that the thread was meant to
take this count, and we could have a separate "VOTE:" thread if we
really want to, but my strong impression from the existing thread is
that we already know how that vote would turn out.

>Of course, maybe numbers aren't necessary; Stefan may just want to hear
>the discussion and decide what to do.  Or maybe he already has.

I thought he has, and has stated so.

­K

Re: Prefer Mercurial instead of git

[Jay Belanger]

>>That would just tell you who was the loudest, not which choice was
>>preferred by most people.  I suspect it wouldn't matter, but if numbers
>>are wanted, I think some sort of formal vote should be taken.
>
> My intention with my "PROPOSAL:" mail was to gather those numbers; I
> think those people followed up with a "+1" (or the opposite) grokked
> that intention.

Maybe, maybe not; but "I guess we should hold a poll" isn't necessarily
the same thing as "This is a poll", and I didn't regard it as such.

> So the numbers in that thread be gathered accurately without regard to
> who's loudest -- we don't count someone twice just because they posted
> twice.

Not everybody voiced an opinion; the quieter people would not be counted
at all.  

> Now, it may not have been clear that the thread was meant to
> take this count, and we could have a separate "VOTE:" thread if we
> really want to, but my strong impression from the existing thread is
> that we already know how that vote would turn out.

I don't think it was clear, but your impression may well be right.

>>Of course, maybe numbers aren't necessary; Stefan may just want to hear
>>the discussion and decide what to do.  Or maybe he already has.
>
> I thought he has, and has stated so.

In which case polls don't matter.

Jay

Re: Prefer Mercurial instead of git

[Eli Zaretskii]

> From: Darren Hoo <darren.hoo@gmail.com>
> Date: Mon, 06 Jan 2014 20:26:33 +0800
> 
> But since when Stefan, Glenn and Chong Yidong became not the core
> developers of Emacs?

I never said they weren't.  They sure are.  Please don't put such
words in my mouth.

> http://lists.gnu.org/archive/html/emacs-devel/2012-11/msg00235.html
> 
> https://bugs.launchpad.net/bzr/+bug/937101

Why didn't you quote the bug reports _I_ filed against bzr?  Then my
delusional nature would have been clear to anyone.

But wait, I also reported bugs against Emacs, some of them even
involved crashes.  So perhaps we should abandon this piece of crap,
and switch to Notepad.  Because it's evident that a package that has
bugs can never be useful and generally reliable, right?

If you want to be serious now, then please re-read the part of the
message to which I responded, which was that "bzr was not good for
Emacs".  That is the context against which you should understand my
response.

Of course, even if you didn't catch the context, to assume that by
"without problems" I could possibly mean "without a single bug or
annoyance" would be far fetched, to say the least.

Re: Prefer Mercurial instead of git

[Paul Eggert]

On 01/06/2014 04:26 AM, Darren Hoo wrote:

> I know you are the core developer. (I am a little sensitive to this word ...

Partly because of that kind of sensibility, it's not a
productive use of our time to argue about who's a core
developer and who is not.  Anyway, from a software-engineering
point of view, a more fruitful way to think about it is to
ask who uses the version-control system the most.  Even if a
contributor is not a "core developer" (whatever that means),
if they use the version-control system a lot while making
significant contributions to Emacs, then their opinion
should matter.  After all, our goal is improving Emacs and
advancing software freedom, not exclusion or bureaucracy.