* Prefer Mercurial instead of git @ 2014-01-03 21:52 Jordi Gutiérrez Hermoso 2014-01-04 10:11 ` David Kastrup ` (2 more replies) 0 siblings, 3 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-03 21:52 UTC (permalink / raw To: Emacs development discussions; +Cc: esr@thyrsus.com 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:// ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-03 21:52 Prefer Mercurial instead of git Jordi Gutiérrez Hermoso @ 2014-01-04 10:11 ` David Kastrup 2014-01-04 10:20 ` David Engster ` (2 more replies) 2014-01-04 14:12 ` Rüdiger Sonderfeld 2014-01-05 2:14 ` Karl Fogel 2 siblings, 3 replies; 72+ messages in thread From: David Kastrup @ 2014-01-04 10:11 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 10:11 ` David Kastrup @ 2014-01-04 10:20 ` David Engster 2014-01-04 10:33 ` Eric S. Raymond 2014-01-04 13:13 ` Jordi Gutiérrez Hermoso 2 siblings, 0 replies; 72+ messages in thread From: David Engster @ 2014-01-04 10:20 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 10:11 ` David Kastrup 2014-01-04 10:20 ` David Engster @ 2014-01-04 10:33 ` Eric S. Raymond 2014-01-04 13:13 ` Jordi Gutiérrez Hermoso 2 siblings, 0 replies; 72+ messages in thread From: Eric S. Raymond @ 2014-01-04 10:33 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel 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> ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 10:11 ` David Kastrup 2014-01-04 10:20 ` David Engster 2014-01-04 10:33 ` Eric S. Raymond @ 2014-01-04 13:13 ` Jordi Gutiérrez Hermoso 2014-01-04 13:29 ` David Engster 2014-01-04 14:23 ` David Kastrup 2 siblings, 2 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 13:13 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 13:13 ` Jordi Gutiérrez Hermoso @ 2014-01-04 13:29 ` David Engster 2014-01-04 14:23 ` David Kastrup 1 sibling, 0 replies; 72+ messages in thread From: David Engster @ 2014-01-04 13:29 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: David Kastrup, emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 13:13 ` Jordi Gutiérrez Hermoso 2014-01-04 13:29 ` David Engster @ 2014-01-04 14:23 ` David Kastrup 2014-01-04 14:38 ` Jordi Gutiérrez Hermoso 2014-01-04 14:40 ` Jordi Gutiérrez Hermoso 1 sibling, 2 replies; 72+ messages in thread From: David Kastrup @ 2014-01-04 14:23 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 14:23 ` David Kastrup @ 2014-01-04 14:38 ` Jordi Gutiérrez Hermoso 2014-01-04 15:19 ` David Kastrup 2014-01-04 14:40 ` Jordi Gutiérrez Hermoso 1 sibling, 1 reply; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 14:38 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 14:38 ` Jordi Gutiérrez Hermoso @ 2014-01-04 15:19 ` David Kastrup 2014-01-04 15:24 ` Jordi Gutiérrez Hermoso 0 siblings, 1 reply; 72+ messages in thread From: David Kastrup @ 2014-01-04 15:19 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 15:19 ` David Kastrup @ 2014-01-04 15:24 ` Jordi Gutiérrez Hermoso 2014-01-04 16:51 ` David Engster 0 siblings, 1 reply; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 15:24 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 15:24 ` Jordi Gutiérrez Hermoso @ 2014-01-04 16:51 ` David Engster 2014-01-04 17:16 ` Jordi Gutiérrez Hermoso 0 siblings, 1 reply; 72+ messages in thread From: David Engster @ 2014-01-04 16:51 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: David Kastrup, emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 16:51 ` David Engster @ 2014-01-04 17:16 ` Jordi Gutiérrez Hermoso 2014-01-04 17:31 ` David Engster 2014-01-04 17:35 ` Eli Zaretskii 0 siblings, 2 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 17:16 UTC (permalink / raw To: David Engster; +Cc: David Kastrup, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 17:16 ` Jordi Gutiérrez Hermoso @ 2014-01-04 17:31 ` David Engster 2014-01-04 17:40 ` Jordi Gutiérrez Hermoso 2014-01-04 17:35 ` Eli Zaretskii 1 sibling, 1 reply; 72+ messages in thread From: David Engster @ 2014-01-04 17:31 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: David Kastrup, emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 17:31 ` David Engster @ 2014-01-04 17:40 ` Jordi Gutiérrez Hermoso 2014-01-04 18:34 ` Alan Mackenzie 2014-01-05 11:07 ` Leo Liu 0 siblings, 2 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 17:40 UTC (permalink / raw To: David Engster; +Cc: David Kastrup, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 17:40 ` Jordi Gutiérrez Hermoso @ 2014-01-04 18:34 ` Alan Mackenzie 2014-01-04 19:26 ` Óscar Fuentes 2014-01-04 20:18 ` Stefan Monnier 2014-01-05 11:07 ` Leo Liu 1 sibling, 2 replies; 72+ messages in thread From: Alan Mackenzie @ 2014-01-04 18:34 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: David Kastrup, David Engster, emacs-devel 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). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 18:34 ` Alan Mackenzie @ 2014-01-04 19:26 ` Óscar Fuentes 2014-01-04 20:18 ` Stefan Monnier 1 sibling, 0 replies; 72+ messages in thread From: Óscar Fuentes @ 2014-01-04 19:26 UTC (permalink / raw To: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 18:34 ` Alan Mackenzie 2014-01-04 19:26 ` Óscar Fuentes @ 2014-01-04 20:18 ` Stefan Monnier 1 sibling, 0 replies; 72+ messages in thread From: Stefan Monnier @ 2014-01-04 20:18 UTC (permalink / raw To: Alan Mackenzie Cc: Jordi Gutiérrez Hermoso, David Kastrup, David Engster, emacs-devel > 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 17:40 ` Jordi Gutiérrez Hermoso 2014-01-04 18:34 ` Alan Mackenzie @ 2014-01-05 11:07 ` Leo Liu 1 sibling, 0 replies; 72+ messages in thread From: Leo Liu @ 2014-01-05 11:07 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: David Kastrup, David Engster, emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 17:16 ` Jordi Gutiérrez Hermoso 2014-01-04 17:31 ` David Engster @ 2014-01-04 17:35 ` Eli Zaretskii 2014-01-04 18:25 ` Paul Eggert 1 sibling, 1 reply; 72+ messages in thread From: Eli Zaretskii @ 2014-01-04 17:35 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: dak, deng, emacs-devel > 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 17:35 ` Eli Zaretskii @ 2014-01-04 18:25 ` Paul Eggert 2014-01-04 20:03 ` Eli Zaretskii 0 siblings, 1 reply; 72+ messages in thread From: Paul Eggert @ 2014-01-04 18:25 UTC (permalink / raw To: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 18:25 ` Paul Eggert @ 2014-01-04 20:03 ` Eli Zaretskii 2014-01-06 12:26 ` Darren Hoo 0 siblings, 1 reply; 72+ messages in thread From: Eli Zaretskii @ 2014-01-04 20:03 UTC (permalink / raw To: Paul Eggert; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 20:03 ` Eli Zaretskii @ 2014-01-06 12:26 ` Darren Hoo 2014-01-06 14:58 ` Stefan Monnier ` (2 more replies) 0 siblings, 3 replies; 72+ messages in thread From: Darren Hoo @ 2014-01-06 12:26 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 12:26 ` Darren Hoo @ 2014-01-06 14:58 ` Stefan Monnier 2014-01-06 17:44 ` Eli Zaretskii 2014-01-06 19:33 ` Paul Eggert 2 siblings, 0 replies; 72+ messages in thread From: Stefan Monnier @ 2014-01-06 14:58 UTC (permalink / raw To: Darren Hoo; +Cc: emacs-devel > I know you are the core developer. ^^^ a -- Stefan ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 12:26 ` Darren Hoo 2014-01-06 14:58 ` Stefan Monnier @ 2014-01-06 17:44 ` Eli Zaretskii 2014-01-06 19:33 ` Paul Eggert 2 siblings, 0 replies; 72+ messages in thread From: Eli Zaretskii @ 2014-01-06 17:44 UTC (permalink / raw To: Darren Hoo; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 12:26 ` Darren Hoo 2014-01-06 14:58 ` Stefan Monnier 2014-01-06 17:44 ` Eli Zaretskii @ 2014-01-06 19:33 ` Paul Eggert 2 siblings, 0 replies; 72+ messages in thread From: Paul Eggert @ 2014-01-06 19:33 UTC (permalink / raw To: Darren Hoo, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 14:23 ` David Kastrup 2014-01-04 14:38 ` Jordi Gutiérrez Hermoso @ 2014-01-04 14:40 ` Jordi Gutiérrez Hermoso 2014-01-05 12:17 ` Stephen J. Turnbull 1 sibling, 1 reply; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 14:40 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 14:40 ` Jordi Gutiérrez Hermoso @ 2014-01-05 12:17 ` Stephen J. Turnbull 2014-01-05 13:19 ` Jordi Gutiérrez Hermoso 2014-01-05 13:56 ` David Kastrup 0 siblings, 2 replies; 72+ messages in thread From: Stephen J. Turnbull @ 2014-01-05 12:17 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: David Kastrup, emacs-devel 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). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 12:17 ` Stephen J. Turnbull @ 2014-01-05 13:19 ` Jordi Gutiérrez Hermoso 2014-01-05 13:25 ` Florian Weimer ` (2 more replies) 2014-01-05 13:56 ` David Kastrup 1 sibling, 3 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-05 13:19 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: David Kastrup, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 13:19 ` Jordi Gutiérrez Hermoso @ 2014-01-05 13:25 ` Florian Weimer 2014-01-05 13:55 ` Jordi Gutiérrez Hermoso 2014-01-05 15:38 ` Óscar Fuentes 2014-01-05 17:54 ` Stephen J. Turnbull 2 siblings, 1 reply; 72+ messages in thread From: Florian Weimer @ 2014-01-05 13:25 UTC (permalink / raw To: Jordi Gutiérrez Hermoso Cc: Stephen J. Turnbull, David Kastrup, emacs-devel * 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). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 13:25 ` Florian Weimer @ 2014-01-05 13:55 ` Jordi Gutiérrez Hermoso 0 siblings, 0 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-05 13:55 UTC (permalink / raw To: Florian Weimer; +Cc: Stephen J. Turnbull, David Kastrup, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 13:19 ` Jordi Gutiérrez Hermoso 2014-01-05 13:25 ` Florian Weimer @ 2014-01-05 15:38 ` Óscar Fuentes 2014-01-05 16:18 ` Jordi Gutiérrez Hermoso 2014-01-05 17:54 ` Stephen J. Turnbull 2 siblings, 1 reply; 72+ messages in thread From: Óscar Fuentes @ 2014-01-05 15:38 UTC (permalink / raw To: emacs-devel 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? ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 15:38 ` Óscar Fuentes @ 2014-01-05 16:18 ` Jordi Gutiérrez Hermoso 2014-01-05 16:41 ` Eric S. Raymond ` (2 more replies) 0 siblings, 3 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-05 16:18 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 16:18 ` Jordi Gutiérrez Hermoso @ 2014-01-05 16:41 ` Eric S. Raymond 2014-01-05 17:09 ` Óscar Fuentes 2014-01-06 0:03 ` David Kastrup 2 siblings, 0 replies; 72+ messages in thread From: Eric S. Raymond @ 2014-01-05 16:41 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: Óscar Fuentes, emacs-devel 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> ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 16:18 ` Jordi Gutiérrez Hermoso 2014-01-05 16:41 ` Eric S. Raymond @ 2014-01-05 17:09 ` Óscar Fuentes 2014-01-05 23:26 ` Jordi Gutiérrez Hermoso 2014-01-06 0:03 ` David Kastrup 2 siblings, 1 reply; 72+ messages in thread From: Óscar Fuentes @ 2014-01-05 17:09 UTC (permalink / raw To: emacs-devel 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.) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 17:09 ` Óscar Fuentes @ 2014-01-05 23:26 ` Jordi Gutiérrez Hermoso 2014-01-06 0:38 ` Óscar Fuentes 0 siblings, 1 reply; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-05 23:26 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 23:26 ` Jordi Gutiérrez Hermoso @ 2014-01-06 0:38 ` Óscar Fuentes 2014-01-06 1:01 ` Jordi Gutiérrez Hermoso 0 siblings, 1 reply; 72+ messages in thread From: Óscar Fuentes @ 2014-01-06 0:38 UTC (permalink / raw To: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 0:38 ` Óscar Fuentes @ 2014-01-06 1:01 ` Jordi Gutiérrez Hermoso 0 siblings, 0 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-06 1:01 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 16:18 ` Jordi Gutiérrez Hermoso 2014-01-05 16:41 ` Eric S. Raymond 2014-01-05 17:09 ` Óscar Fuentes @ 2014-01-06 0:03 ` David Kastrup 2 siblings, 0 replies; 72+ messages in thread From: David Kastrup @ 2014-01-06 0:03 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: Óscar Fuentes, emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 13:19 ` Jordi Gutiérrez Hermoso 2014-01-05 13:25 ` Florian Weimer 2014-01-05 15:38 ` Óscar Fuentes @ 2014-01-05 17:54 ` Stephen J. Turnbull 2014-01-05 23:03 ` Dov Feldstern 2 siblings, 1 reply; 72+ messages in thread From: Stephen J. Turnbull @ 2014-01-05 17:54 UTC (permalink / raw To: Jordi Gutiérrez Hermoso; +Cc: David Kastrup, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 17:54 ` Stephen J. Turnbull @ 2014-01-05 23:03 ` Dov Feldstern 2014-01-05 23:23 ` Karl Fogel 0 siblings, 1 reply; 72+ messages in thread From: Dov Feldstern @ 2014-01-05 23:03 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 23:03 ` Dov Feldstern @ 2014-01-05 23:23 ` Karl Fogel 2014-01-05 23:37 ` Dov Feldstern 0 siblings, 1 reply; 72+ messages in thread From: Karl Fogel @ 2014-01-05 23:23 UTC (permalink / raw To: Dov Feldstern; +Cc: emacs-devel 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 :-). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 23:23 ` Karl Fogel @ 2014-01-05 23:37 ` Dov Feldstern 2014-01-06 4:02 ` Stephen J. Turnbull 0 siblings, 1 reply; 72+ messages in thread From: Dov Feldstern @ 2014-01-05 23:37 UTC (permalink / raw To: Karl Fogel; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 23:37 ` Dov Feldstern @ 2014-01-06 4:02 ` Stephen J. Turnbull 0 siblings, 0 replies; 72+ messages in thread From: Stephen J. Turnbull @ 2014-01-06 4:02 UTC (permalink / raw To: Dov Feldstern; +Cc: Karl Fogel, emacs-devel 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*. :-) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 12:17 ` Stephen J. Turnbull 2014-01-05 13:19 ` Jordi Gutiérrez Hermoso @ 2014-01-05 13:56 ` David Kastrup 1 sibling, 0 replies; 72+ messages in thread From: David Kastrup @ 2014-01-05 13:56 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: Jordi Gutiérrez Hermoso, emacs-devel "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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-03 21:52 Prefer Mercurial instead of git Jordi Gutiérrez Hermoso 2014-01-04 10:11 ` David Kastrup @ 2014-01-04 14:12 ` Rüdiger Sonderfeld 2014-01-04 16:08 ` Sebastian Wiesner 2014-01-05 2:14 ` Karl Fogel 2 siblings, 1 reply; 72+ messages in thread From: Rüdiger Sonderfeld @ 2014-01-04 14:12 UTC (permalink / raw To: emacs-devel; +Cc: esr@thyrsus.com, Jordi Gutiérrez Hermoso 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 14:12 ` Rüdiger Sonderfeld @ 2014-01-04 16:08 ` Sebastian Wiesner 2014-01-04 16:41 ` Jordi Gutiérrez Hermoso 0 siblings, 1 reply; 72+ messages in thread From: Sebastian Wiesner @ 2014-01-04 16:08 UTC (permalink / raw To: Rüdiger Sonderfeld Cc: esr@thyrsus.com, Jordi Gutiérrez Hermoso, emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 16:08 ` Sebastian Wiesner @ 2014-01-04 16:41 ` Jordi Gutiérrez Hermoso 2014-01-04 18:37 ` David Kastrup 2014-01-05 17:16 ` Sebastian Wiesner 0 siblings, 2 replies; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 16:41 UTC (permalink / raw To: Sebastian Wiesner; +Cc: Rüdiger Sonderfeld, esr@thyrsus.com, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 16:41 ` Jordi Gutiérrez Hermoso @ 2014-01-04 18:37 ` David Kastrup 2014-01-04 18:44 ` Alan Mackenzie ` (2 more replies) 2014-01-05 17:16 ` Sebastian Wiesner 1 sibling, 3 replies; 72+ messages in thread From: David Kastrup @ 2014-01-04 18:37 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 18:37 ` David Kastrup @ 2014-01-04 18:44 ` Alan Mackenzie 2014-01-04 19:04 ` Jordi Gutiérrez Hermoso 2014-01-05 3:13 ` Jay Belanger 2 siblings, 0 replies; 72+ messages in thread From: Alan Mackenzie @ 2014-01-04 18:44 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 18:37 ` David Kastrup 2014-01-04 18:44 ` Alan Mackenzie @ 2014-01-04 19:04 ` Jordi Gutiérrez Hermoso 2014-01-04 19:30 ` Óscar Fuentes 2014-01-05 3:13 ` Jay Belanger 2 siblings, 1 reply; 72+ messages in thread From: Jordi Gutiérrez Hermoso @ 2014-01-04 19:04 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 19:04 ` Jordi Gutiérrez Hermoso @ 2014-01-04 19:30 ` Óscar Fuentes 2014-01-05 16:23 ` Eli Zaretskii 0 siblings, 1 reply; 72+ messages in thread From: Óscar Fuentes @ 2014-01-04 19:30 UTC (permalink / raw To: emacs-devel 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] ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 19:30 ` Óscar Fuentes @ 2014-01-05 16:23 ` Eli Zaretskii 2014-01-05 16:46 ` Eric S. Raymond 2014-01-05 16:52 ` Óscar Fuentes 0 siblings, 2 replies; 72+ messages in thread From: Eli Zaretskii @ 2014-01-05 16:23 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 16:23 ` Eli Zaretskii @ 2014-01-05 16:46 ` Eric S. Raymond 2014-01-05 17:03 ` Eli Zaretskii 2014-01-05 16:52 ` Óscar Fuentes 1 sibling, 1 reply; 72+ messages in thread From: Eric S. Raymond @ 2014-01-05 16:46 UTC (permalink / raw To: Eli Zaretskii; +Cc: Óscar Fuentes, emacs-devel 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> ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 16:46 ` Eric S. Raymond @ 2014-01-05 17:03 ` Eli Zaretskii 0 siblings, 0 replies; 72+ messages in thread From: Eli Zaretskii @ 2014-01-05 17:03 UTC (permalink / raw To: esr; +Cc: ofv, emacs-devel > 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 16:23 ` Eli Zaretskii 2014-01-05 16:46 ` Eric S. Raymond @ 2014-01-05 16:52 ` Óscar Fuentes 2014-01-05 17:17 ` Eli Zaretskii 1 sibling, 1 reply; 72+ messages in thread From: Óscar Fuentes @ 2014-01-05 16:52 UTC (permalink / raw To: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 16:52 ` Óscar Fuentes @ 2014-01-05 17:17 ` Eli Zaretskii 2014-01-05 17:55 ` Óscar Fuentes 2014-01-06 0:12 ` David Kastrup 0 siblings, 2 replies; 72+ messages in thread From: Eli Zaretskii @ 2014-01-05 17:17 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 17:17 ` Eli Zaretskii @ 2014-01-05 17:55 ` Óscar Fuentes 2014-01-05 18:07 ` Eli Zaretskii 2014-01-05 21:07 ` Sean Sieger 2014-01-06 0:12 ` David Kastrup 1 sibling, 2 replies; 72+ messages in thread From: Óscar Fuentes @ 2014-01-05 17:55 UTC (permalink / raw To: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 17:55 ` Óscar Fuentes @ 2014-01-05 18:07 ` Eli Zaretskii 2014-01-05 18:54 ` Óscar Fuentes 2014-01-05 21:07 ` Sean Sieger 1 sibling, 1 reply; 72+ messages in thread From: Eli Zaretskii @ 2014-01-05 18:07 UTC (permalink / raw To: Óscar Fuentes; +Cc: emacs-devel > 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? ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 18:07 ` Eli Zaretskii @ 2014-01-05 18:54 ` Óscar Fuentes 0 siblings, 0 replies; 72+ messages in thread From: Óscar Fuentes @ 2014-01-05 18:54 UTC (permalink / raw To: emacs-devel 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.) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 17:55 ` Óscar Fuentes 2014-01-05 18:07 ` Eli Zaretskii @ 2014-01-05 21:07 ` Sean Sieger 1 sibling, 0 replies; 72+ messages in thread From: Sean Sieger @ 2014-01-05 21:07 UTC (permalink / raw To: emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 17:17 ` Eli Zaretskii 2014-01-05 17:55 ` Óscar Fuentes @ 2014-01-06 0:12 ` David Kastrup 2014-01-06 0:21 ` Rostislav Svoboda 2014-01-06 3:47 ` Eli Zaretskii 1 sibling, 2 replies; 72+ messages in thread From: David Kastrup @ 2014-01-06 0:12 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 0:12 ` David Kastrup @ 2014-01-06 0:21 ` Rostislav Svoboda 2014-01-06 0:30 ` Karl Fogel 2014-01-06 3:47 ` Eli Zaretskii 1 sibling, 1 reply; 72+ messages in thread From: Rostislav Svoboda @ 2014-01-06 0:21 UTC (permalink / raw To: emacs-devel Is anybody out there able to convert this "git vs. hg" discussion from feelings into numbers? ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 0:21 ` Rostislav Svoboda @ 2014-01-06 0:30 ` Karl Fogel 2014-01-06 2:24 ` Jay Belanger 0 siblings, 1 reply; 72+ messages in thread From: Karl Fogel @ 2014-01-06 0:30 UTC (permalink / raw To: Rostislav Svoboda; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 0:30 ` Karl Fogel @ 2014-01-06 2:24 ` Jay Belanger 2014-01-06 16:51 ` Karl Fogel 0 siblings, 1 reply; 72+ messages in thread From: Jay Belanger @ 2014-01-06 2:24 UTC (permalink / raw To: emacs-devel; +Cc: jay.p.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 2:24 ` Jay Belanger @ 2014-01-06 16:51 ` Karl Fogel 2014-01-06 17:13 ` Jay Belanger 0 siblings, 1 reply; 72+ messages in thread From: Karl Fogel @ 2014-01-06 16:51 UTC (permalink / raw To: Jay Belanger; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 16:51 ` Karl Fogel @ 2014-01-06 17:13 ` Jay Belanger 0 siblings, 0 replies; 72+ messages in thread From: Jay Belanger @ 2014-01-06 17:13 UTC (permalink / raw To: emacs-devel; +Cc: jay.p.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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-06 0:12 ` David Kastrup 2014-01-06 0:21 ` Rostislav Svoboda @ 2014-01-06 3:47 ` Eli Zaretskii 1 sibling, 0 replies; 72+ messages in thread From: Eli Zaretskii @ 2014-01-06 3:47 UTC (permalink / raw To: David Kastrup; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 18:37 ` David Kastrup 2014-01-04 18:44 ` Alan Mackenzie 2014-01-04 19:04 ` Jordi Gutiérrez Hermoso @ 2014-01-05 3:13 ` Jay Belanger 2 siblings, 0 replies; 72+ messages in thread From: Jay Belanger @ 2014-01-05 3:13 UTC (permalink / raw To: emacs-devel; +Cc: jay.p.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-04 16:41 ` Jordi Gutiérrez Hermoso 2014-01-04 18:37 ` David Kastrup @ 2014-01-05 17:16 ` Sebastian Wiesner 2014-01-06 0:17 ` David Kastrup 1 sibling, 1 reply; 72+ messages in thread From: Sebastian Wiesner @ 2014-01-05 17:16 UTC (permalink / raw To: Jordi Gutiérrez Hermoso Cc: Rüdiger Sonderfeld, esr@thyrsus.com, emacs-devel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-05 17:16 ` Sebastian Wiesner @ 2014-01-06 0:17 ` David Kastrup 0 siblings, 0 replies; 72+ messages in thread From: David Kastrup @ 2014-01-06 0:17 UTC (permalink / raw To: emacs-devel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git 2014-01-03 21:52 Prefer Mercurial instead of git Jordi Gutiérrez Hermoso 2014-01-04 10:11 ` David Kastrup 2014-01-04 14:12 ` Rüdiger Sonderfeld @ 2014-01-05 2:14 ` Karl Fogel 2 siblings, 0 replies; 72+ messages in thread From: Karl Fogel @ 2014-01-05 2:14 UTC (permalink / raw To: Jordi \1 Hermoso; +Cc: esr@thyrsus.com, Emacs development discussions 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: Prefer Mercurial instead of git
@ 2014-01-06 13:08 grischka
0 siblings, 0 replies; 72+ messages in thread
From: grischka @ 2014-01-06 13:08 UTC (permalink / raw
To: acm; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 72+ messages in thread
end of thread, other threads:[~2014-01-06 19:33 UTC | newest] Thread overview: 72+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-03 21:52 Prefer Mercurial instead of git Jordi Gutiérrez Hermoso 2014-01-04 10:11 ` David Kastrup 2014-01-04 10:20 ` David Engster 2014-01-04 10:33 ` Eric S. Raymond 2014-01-04 13:13 ` Jordi Gutiérrez Hermoso 2014-01-04 13:29 ` David Engster 2014-01-04 14:23 ` David Kastrup 2014-01-04 14:38 ` Jordi Gutiérrez Hermoso 2014-01-04 15:19 ` David Kastrup 2014-01-04 15:24 ` Jordi Gutiérrez Hermoso 2014-01-04 16:51 ` David Engster 2014-01-04 17:16 ` Jordi Gutiérrez Hermoso 2014-01-04 17:31 ` David Engster 2014-01-04 17:40 ` Jordi Gutiérrez Hermoso 2014-01-04 18:34 ` Alan Mackenzie 2014-01-04 19:26 ` Óscar Fuentes 2014-01-04 20:18 ` Stefan Monnier 2014-01-05 11:07 ` Leo Liu 2014-01-04 17:35 ` Eli Zaretskii 2014-01-04 18:25 ` Paul Eggert 2014-01-04 20:03 ` Eli Zaretskii 2014-01-06 12:26 ` Darren Hoo 2014-01-06 14:58 ` Stefan Monnier 2014-01-06 17:44 ` Eli Zaretskii 2014-01-06 19:33 ` Paul Eggert 2014-01-04 14:40 ` Jordi Gutiérrez Hermoso 2014-01-05 12:17 ` Stephen J. Turnbull 2014-01-05 13:19 ` Jordi Gutiérrez Hermoso 2014-01-05 13:25 ` Florian Weimer 2014-01-05 13:55 ` Jordi Gutiérrez Hermoso 2014-01-05 15:38 ` Óscar Fuentes 2014-01-05 16:18 ` Jordi Gutiérrez Hermoso 2014-01-05 16:41 ` Eric S. Raymond 2014-01-05 17:09 ` Óscar Fuentes 2014-01-05 23:26 ` Jordi Gutiérrez Hermoso 2014-01-06 0:38 ` Óscar Fuentes 2014-01-06 1:01 ` Jordi Gutiérrez Hermoso 2014-01-06 0:03 ` David Kastrup 2014-01-05 17:54 ` Stephen J. Turnbull 2014-01-05 23:03 ` Dov Feldstern 2014-01-05 23:23 ` Karl Fogel 2014-01-05 23:37 ` Dov Feldstern 2014-01-06 4:02 ` Stephen J. Turnbull 2014-01-05 13:56 ` David Kastrup 2014-01-04 14:12 ` Rüdiger Sonderfeld 2014-01-04 16:08 ` Sebastian Wiesner 2014-01-04 16:41 ` Jordi Gutiérrez Hermoso 2014-01-04 18:37 ` David Kastrup 2014-01-04 18:44 ` Alan Mackenzie 2014-01-04 19:04 ` Jordi Gutiérrez Hermoso 2014-01-04 19:30 ` Óscar Fuentes 2014-01-05 16:23 ` Eli Zaretskii 2014-01-05 16:46 ` Eric S. Raymond 2014-01-05 17:03 ` Eli Zaretskii 2014-01-05 16:52 ` Óscar Fuentes 2014-01-05 17:17 ` Eli Zaretskii 2014-01-05 17:55 ` Óscar Fuentes 2014-01-05 18:07 ` Eli Zaretskii 2014-01-05 18:54 ` Óscar Fuentes 2014-01-05 21:07 ` Sean Sieger 2014-01-06 0:12 ` David Kastrup 2014-01-06 0:21 ` Rostislav Svoboda 2014-01-06 0:30 ` Karl Fogel 2014-01-06 2:24 ` Jay Belanger 2014-01-06 16:51 ` Karl Fogel 2014-01-06 17:13 ` Jay Belanger 2014-01-06 3:47 ` Eli Zaretskii 2014-01-05 3:13 ` Jay Belanger 2014-01-05 17:16 ` Sebastian Wiesner 2014-01-06 0:17 ` David Kastrup 2014-01-05 2:14 ` Karl Fogel -- strict thread matches above, loose matches on Subject: below -- 2014-01-06 13:08 grischka
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.