Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix Open Source Programming Software

Emacs Needs To Move To GitHub, Says ESR 252

Posted by timothy from the this-way-to-the-bazaar dept.
hypnosec writes "Eric S. Raymond, co-founder of the Open Source Initiative, has recommended that Emacs should move to another version control system like GitHub, as bzr is dying. In an email, Raymond highlighted the key reasons why he believes that Emacs should move. Raymond said that bzr is moribund; its dev list has flatlined; and most of Canonical's in-house projects have already abandoned bzr and moved to GitHub. ESR believes that bzr's codebase is sufficiently mature to be used as a production tool, but he does mention that continuing to use the revision control system will have 'social and signaling effects damaging to Emacs's prospects.'" Update: 01/06 20:50 GMT by U L : ESR did not suggest Github the proprietary hosting platform for git, but rather git the version control system. Which is actually already available on Savannah (the bazaar repository is automatically synced with the git repository).
This discussion has been archived. No new comments can be posted.

Emacs Needs To Move To GitHub, Says ESR More

Emacs Needs To Move To GitHub, Says ESR

Comments Filter:

  • Git, not Github (Score:5, Informative)

    by codl ( 1703578 ) <codl@codl.fr> on Thursday January 02, 2014 @10:34AM (#45845347)
    ESR's original posting [gnu.org] does not mention Github at all.

  • What's bzr? (Score:2, Interesting)

    by Anonymous Coward

    Never heard of it.

    • Bazaar [canonical.com]. It's a VCS that Canonical developed. Why Switch to Bazaar? [canonical.com]

      IMO, the only things that Bazaar has up on Git these days is released, official support for Windows and thus better GUIs all around for all platforms. Git is still technically a pre-release for Windows. Bazaar is also purportedly better for binary files than Git, and allows downloads from any point in the history (instead of Git requiring that you download the whole repository history).

      • Re:What's bzr? (Score:4, Informative)

        by DrXym ( 126579 ) on Thursday January 02, 2014 @12:00PM (#45846241)
        Git seems to be perpetually in preview on Windows but in practice it works relatively well. There are quite a few front ends for it if you hate the command line.

        The biggest issues I have with it are:

        • Line ending conversion is a massive pain in the arse. Windows is CRLF, Linux is LF. Msysgit asks during installation what line ending conversion policy to use. If you get it wrong, you'll see spurious issues with files marked as modified when no difference is visible. The best advice I can give is set core.autocrlf to false when you install msysgit so that line endings are left alone. You can do stuff with a file called .gitattributes to turn off line ending conversion in the repo itself but JGit (the Java pure impl of Git in Eclipse) doesn't actually bother to honour the settings in that file.
        • Performance is a bit poor. You won't notice in small repos but when the repo is 10,000+ files, simple things like "git status" can sit there for minutes. MSYS has an inefficient lstat and performance becomes noticeably in Git as a consequence. An SSD helps a lot, but that's no consolation for devs who can't ask for one.
        • 260 char MAX_PATH imposes restrictions on path length that the fs itself could cope with.

        Nothing is a deal breaker. I think Git on Windows works as well as most other source control systems when its up and going and comes with its own advantages that compel its use for software development. I wouldn't use it for document management though - something like Subversion would be better for that.

  • GNU Savannah supports git (Score:5, Informative)

    by byolinux ( 535260 ) * on Thursday January 02, 2014 @10:35AM (#45845359) Journal

    No need to move to a proprietary hosting service like Github.

    I wrote about this previously: http://www.fsf.org/blogs/community/savannah [fsf.org]

    • Wow. Support for GNU Arch is really an outstanding feature!

      TLA is for all intent and purposes is dead. The .gitignore alone is reason enough to migrate to git.

      OK, archives is a very cool feature found literally nowhere else, but it alone isn't enough to sway any decision process in favor of TLA.

    • Re: (Score:2, Interesting)

      by mwvdlee ( 775178 )

      Just wondering; why doesn't your article mention Github, which is probably the most popular service right now?

      • Most likely because Stallman completely avoids all cloud services because when you use them, you don't really own your data. Git has an actual chance of being used. Github? Unlikely.

        • Re: (Score:2)

          by DrXym ( 126579 )
          Source code has to be hosted somewhere. Even if the FSF hosts source code on their own servers it's still "in the cloud" as far as people pushing and pulling from it are concerned. Anyway, if it's a big deal, they could set up GitHub as a mirror and host the "master" copy on their server even if in practice most people would be pushing to GitHub and that would be periodically synced to the FSF.
          • I think the FSF is fine w/ cloud services as long as they are AGPL3 licensed. In other words, if someone runs a service on such a server, the source code of all the services that the server runs has to be made available. Unlike in the case of GPL3 or LGPL3, where source code only had to accompany distribution of software, here it has to accompany remotely running software.
        • He'd probably look for an AGPL3 license on such a service before he touches it

    • Re: (Score:2)

      by devent ( 1627873 )

      There are more alternatives. For example Redmine http://www.redmine.org/ [redmine.org]
      Redmine offers a full project management suite: bug track, wiki, forum, files and document, version control, GANT chart, and so on.

  • Git... (Score:5, Informative)

    by Anonymous Coward on Thursday January 02, 2014 @10:36AM (#45845365)

    He wants to move emacs to git and not to Github. Journalists...

    • Re: (Score:3, Informative)

      by Anonymous Coward

      "hypnosec" is not a journalist. It's someone who's spamming his regurgitation blog posts to drive ad impressions.

    • Re: (Score:2)

      by monzie ( 729782 )
      and Slashdot Editors.. if there are any of them left....

      • Re: (Score:2)

        by tgd ( 2822 )

        and Slashdot Editors.. if there are any of them left....

        If it doesn't reduce ad impressions, why would the editors care?

        The criticisms people are leveling against this Ravi Mandali guy are for doing the same crap that DICE has ensured Slashdot does every day.

         

  • git, not GitHub (Score:5, Informative)

    by Anonymous Coward on Thursday January 02, 2014 @10:36AM (#45845371)

    The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?

    • Re:git, not GitHub (Score:5, Insightful)

      by fuzzyfuzzyfungus ( 1223518 ) on Thursday January 02, 2014 @11:11AM (#45845715) Journal

      The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?

      C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!

      • The original source (ESR himself) never mentioned GitHub. Just git. Can people stop conflating the two please?

        C'mon, man, get with the times. Having 'protocols' with 'definitions' that allow for 'multiple vendor-neutral implementations' is so totally outdated, man. Everybody knows that the future is snappily named proprietary services dependent on a single vendor with a nonsensical business model, ideally accessible only through an iPhone app!

        Said snappily named services discovered through a multicast DNS p

        • That sounds dangerously like a suggestion that the assorted vendor lock-in products should inter-operate with one another in some sane way... True endarkenment is only achieved when each product has some stupid dependency on the others; but not anything that would actually make the whole mess easier. Making a 'cloud' service dependent on a local MS server/client setup, for instance, is excellent; but having that 'cloud' service capable of authenticating against your AD, rather than it's own half-assed crede

          • That sounds dangerously like a suggestion that the assorted vendor lock-in products should inter-operate with one another in some sane way.

            Oh, don't worry, there's no sanity involved!

      • Re: (Score:2)

        by knarf ( 34928 )

        This. So true. The only thing to be added is an icon in the style of Dick Bruna's 'Nijntje Konijntje [wikipedia.org]' to appeal even the lowest of the lowest common of denominators.

      • You forgot that it has to be a non-free (speech and beer) iPhone app!

  • Oh god, the marketing-speak is coming from inside the open source developers. Get out! Get out now!

  • Surprised (Score:5, Funny)

    by DaveAtFraud ( 460127 ) on Thursday January 02, 2014 @10:51AM (#45845501) Homepage Journal

    I'm surprised that emacs didn't already have a version control system built into. It has everything else.

    Cheers,
    Dave

  • M-x move-from-bzr-to-github

  • Insufficient Resources (Score:2, Insightful)

    by Anonymous Coward

    Github doesn't have the resources to host something that bloated.

  • What about Mercurial? (Score:5, Insightful)

    by ebno-10db ( 1459097 ) on Thursday January 02, 2014 @11:15AM (#45845757)

    Since VC wars are almost as much fun as language wars, and I've already donned my Nomex underwear, why not Mercurial? It isn't as popular as git, but it's not going to die either (e.g. Python project uses Hg). It seems that most people or organizations that have actually sat down and evaluated Hg vs. git have chosen Hg. Examples include Google's online repository and Fog Creek's Kiln. Both now also support git, but that's because of demand by users. Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why? For all its visibility and importance, the Linux kernel is but one FOSS project, and the vast majority of FOSS devs don't work on it.

    Now for the statement that some will see as flamebait :-) but which is a sincere observation. I think the difference is the fanboi factor; people who think that git is the choice because it's from Linus, the ultimate cool kid. No, I don't think everyone who uses git does so because they're a fanboi. I suspect the main reason is going with that flow, but it's the fanbois who originally pushed that flow so hard. As your mother used to say, if all your friends decided to jump off a cliff, would you jump too? Vociferous debate welcome.

    Sincerely,
    Don Quixote

    • Comment removed based on user account deletion

    • Of course user demand is, at least from a marketing PoV, important, but why the user demand for git over Hg? Both have technical pros and cons (and fortunately for both the dev teams compete with each other), but Hg has always had a much better command line user interface, better GUI integration, and was well designed from the ground up to be portable, as opposed to a pile of shell scripts and C programs to run on Linux. Arguably git's use on the Linux kernel is a factor, but why?

      The network effect explains it. Git probably got an early boost of popularity because of who its author was. This initial momentum was enough to snowball into the most popular distributed RCS. Once it is established, learning curves and database lock-in create a barrier to other alternatives, and they apparently aren't currently "better enough" to prompt people to work through those barriers.

      For example, even if Hg has a better CLI than git as you say, I'm sure that just learning and using just the git CLI

    • Funny, I thought much the same about Bzr. Bzr has at least one GUI (bzr-gtk), is better supported on more than just Linux-based systems, is also written in Python, etc.

      Unfortunately, Bzr development has apparently stalled (hence the email from esr suggesting moving off bzr to git -- he notes that he would prefer hg, but that Git has basically won). But, bzr does everything I ask of it. I'll be continuing to use it, so long as it continues to work. When it stops, I guess I'll have to find a tool to convert a

    • Re: (Score:2)

      by bledri ( 1283728 )

      Since VC wars are almost as much fun as language wars, and I've already donned my Nomex underwear, why not Mercurial?...

      Because mercury causes autism!

    • Mercurial is missing a few key features that make it less appropriate for solving some difficult collaboration problems, and some of those turn out to be important to people outside of Linux kernel development too. That's the technical part underneath what you're dismissing as a fanboy phenomenon.

      Allowing octopus merges and making it easy to rewrite/rebase local branches are two such important features. The way those fit together into git's remote tracking branch concept is a particularly useful mental mo

  • Can't we settle this like geeks? (Score:5, Funny)

    by fuzzyfuzzyfungus ( 1223518 ) on Thursday January 02, 2014 @11:15AM (#45845761) Journal
    Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?

    Given sufficient time, I'm sure we can generalize away any petty disagreements!

    • Mercurial is actually making some strides in that direction... the hg-git [github.io] mercurial plugin lets you push/pull from git repositories, and it transparently integrates itself into the mercurial command line, not as a separate tool.

    • Why make a contentious choice between bzr and git when we could implement a new, metalevel distributed revision control system that supports revision control across multiple revision control systems, each potentially running on multiple nodes?

      Good call. I'll get started on the Emacs macro right away!

  • The usual ESR self-aggrandizement (Score:5, Interesting)

    by mvdwege ( 243851 ) <mvdwege@mail.com> on Thursday January 02, 2014 @11:23AM (#45845839) Homepage Journal

    Apparently Eric has decided he has been out of the public eye too long, as he posts yet another self-aggrandizing screed on a mailing list.

    Seriously, after the kernel configuration debacle and his hysterical rants on the Fedora list, does anyone take this man seriously anymore? Look at how he represents himself: an expert on source control systems, whose highest achievement is moving troff to a git repo. It's kconfig all over again.

  • It's baffling that such a large project would use bzr as source control. Bzr doesn't have branching. Before you yell at me, I know, there is a command to create a "branch", but it is essentially a copy of the whole repo. Unusable for any project larger than a couple files. I would not be one bit surprised if it in fact was dying.

    This is the result of picking a tool based on "what's trending this hour", "their website looks better", "look, they have an ipad app", "the ceo's son uses this" etc..

    Happens wa

  • The real question is about Emacs (Score:5, Interesting)

    by hcs_$reboot ( 1536101 ) on Thursday January 02, 2014 @11:28AM (#45845899)
    Actually, is the dying one being Emacs, instead? That would be sad - but I wonder how younger generations do appreciate Emacs which is quite tricky to get used to - while so convenient and still unequaled in 2014 when it comes to some features (hyper customization thanks to (e)Lisp, M-x features with completion, intra-shell/processes, apropos, ^x-( ), languages modes ...). It seems the major IDE or text editors did not even try to reproduce the main features of Emacs - do they ignore the Emacs logic because they have no knowledge of it, or do they simply feel those features are obsolete? For once, nobody reinvents the wheel, which is going to die eventually. Sad, really.

    • Re: (Score:3)

      by Greyfox ( 87712 )
      People don't use a lot of the old tools because they're not aware of the old tools. You never see anyone use Lex and Yacc, for example. Slightly more people seem to know about gdb and efence, but only slightly. I've been talking to a relative as he's going through a CS program and most of his work has been either Java/Eclipse or C++ on a Microsoft Visual C++ platform, with not even the cursory look at the UNIX tools that were common back in the '80s.

      • This; a million times this. The problem is exacerbated by the long-running trend towards computers as consumer appliances, instead of specialised tools. I grew up coding in BASIC on an Acorn Archimedes, which was state-of-the-art at the time; when my family finally "upgraded" to a Win98 PC, the second thing I noticed (the first being the massive jump in performance) was the lack of printed reference manuals and built-in development tools. When I was at university, the teaching language was Object Pascal

      • Re: (Score:2)

        by hey! ( 33014 )

        Lex and YACC are awesome tools, but they're quite special purpose when compared to something like an editor. Also these days its much less common to devise special purpose languages for data interchange tasks; tasks I would have used lex and yacc for twenty-five years ago I'd do in XML or JSON today.

        It took a long time to wean myself off of Emacs and onto Eclipse, but the thing that finally did it for me was refactoring support. The one thing I still use Emacs for is poking around very large data files,

    • I've been using Emacs for a couple of years now and think it's pretty good. The most important bug IMHO is its lack of concurrency. Connecting to remote machines with TRAMP is great, but having the whole app become unresponsive for a period is jarring. Also, I have to run GNUs from a separate process so I can actually do some work while it refreshes.

      Giving ELisp lexical scope is a good start in this direction, since it allows for fully encapsulated closures which won't trample over each others' namespaces.

    • The Emacs userbase is still growing (Score:5, Interesting)

      by ciaran_o_riordan ( 662132 ) on Thursday January 02, 2014 @01:17PM (#45847081) Homepage

      > I wonder how younger generations do appreciate Emacs

      Someone said that to me in 2002. I was a new Emacs user then, and I'm still using it now.

      Debian's package install stats suggest the Emacs user base is steadily growing:

      http://qa.debian.org/popcon-graph.php?packages=emacsen-common [debian.org]

      And the developer mailing list is very active and high-quality:

      https://lists.gnu.org/archive/html/emacs-devel/ [gnu.org]

      However, Hip-Hop's future is looking less certain:

      http://www.theonion.com/video/there-are-people-in-world-who-are-concerned-about,32163/ [theonion.com]

  • What prospects of Emacs left to be damaged? (Score:4, Insightful)

    by Anonymous Coward on Thursday January 02, 2014 @11:35AM (#45845979)

    Is there still any prospect at all? I left 5 years ago because they stopped improving anything for a decade.

    A decade ago it was comparably decent IDE for Java and C++, today it's nothing thanks to incomplete project management UI, incomplete file tab support, and over-reliance on ctags which can't really understand syntax and parse things properly, and their inability to work on on-the-fly static code-analysis, which requires basic threading support that (still) isn't done.

    the same could be said for Vim as well. While both remain very efficient text editors, they no longer matter because it's far more important to study and write correct code than to writing code faster, and other IDEs have improved on such parts drastically these years.

  • Just wanted to say, unrelated to the GitHub discussion, that Emacs is awesome! I've been using it since the mid-80s on 2400 baud modems and have been a big fan of Stallman and the boys. There are things I'd like, for example a GUI object browser. But overall it is f-a-n-t-a-s-t-i-c!

  • No, it doesnt (Score:2, Troll)

    by nurb432 ( 527695 )

    It needs to move to /dev/null Worthless piece of bloated garbage. Its 2014, it has no place in the modern world.

    • Just like the works of Bach and Mozart need to be trashed, they're old and bloated... Just like modern songs by the Black Eye Peas are sooo much better than say Jesu Joy of Man's Desiring or Piano Concerto #21...
  • Doesn't it have a version control in it? Possible no one has found it yet. Anyways I know mere text editors like VIM can do just fine on Mercurial.

    • Re:Emacs is an OS (Score:4)

      by munch117 ( 214551 ) on Thursday January 02, 2014 @03:53PM (#45849019)

      Like many things, Emacs doesn't have version control as much as it interfaces or wraps it. You know, dired wraps /bin/ls (and mv and rm), compile wraps e.g. /usr/bin/make, tramp wraps ftp and grep wraps .. um .. grep. And vc wraps version control:

      ;;; vc.el --- drive a version-control system from within Emacs
      ;; Supported version-control systems presently include CVS, RCS, GNU
      ;; Arch, Subversion, Bzr, Git, Mercurial, Monotone and SCCS (or its
      ;; free replacement, CSSC).

      Emacs is the glue that binds together all the little tools into a more powerful whole. And not just Unix tools, e.g. I wrote a function (3 lines of elisp) that launches Windows Explorer with the current file pre-selected. On a Mac the same key combo launches Finder. You seriously underestimate Emacs by calling it a mere OS...

      By the way, I don't use vc.el myself. Never have. Nor do I use Emacs to read mail. Unlike other editors of more monolithic design, you don't pay for what you don't use.

  • But, while ESR is likely right, my kneejerk response is to say, "No!" Why? Because ESR is such a freaking windbag, who's so damn convinced of his own moral and intellectual superiority. His whole schtick gets really tiresome after a while.

    $.02.

  • For the same reasons.

  • Emacs will settle on git, vim has settled on mercurial. Oh, how delicious!
    • XEmacs uses Mercurial. Therefore we can be sure that GNU Emacs will never, ever, use Mercurial, lest its divine purity is contaminated by contributions from the blasphemers.

  • Two complaints, one non-complaint (Score:3)

    by tlambert ( 566799 ) on Thursday January 02, 2014 @04:09PM (#45849247)

    Two complaints, one non-complaint

    Complaint #1: ESR's reasoning, and the only theoretically justifiable one in the entire blog post, is that bzr is slow. All version control systems are slow. The more you keep the modification history around, the more people you have hitting a single repo, the slower they get.

    When Apple moved from CVS to SVN, it was because of two things: The first was Linux-based Apple RAID boxes that Apple was OEM'ing from a third part had some bug where they lost data, and this messed up some of the CVS backing files. With a single backing file, as in SVN, this situation only improved because the switch came around the time the bugs in AppleRAID had already been resolved; otherwise, it would have been the whole repo, not just a couple of files, getting screwed up. The second one was that the CVS repo was slow. This was pixable by sharding it so different projects used repos on different servers. The new SVN server on the other hand, was lightening fast ... until we moved over the entire modification history from the CVS server to the SVN server, and all the CVS users stopped hitting the CVS server, and started hitting the SVN server instead. Then the SVN server was just as slow as the CVS server had been, and we were back to the status quo.

    The lesson you should take from this is that it doesn't matter your version control system is slow, because they *ALL* are, and so it doesn't make a difference what VCS you end up using, as long as the primary maintainer likes it.

    Complaint #2: ESR claims that, because it's in bzr and not git, it's harder to submit patches to EMACS. This is patently false. The older an Open Source project is, the harder it is to submit patches, and you VCS doesn't matter to this, because the difficulty isn't the VCS, it's the politics of change.

    As projects get older and older, there's kingdom building that happens, and it's nigh impossible to get a change in that's going to cross one or more boundaries between kingdoms. The more kingdoms you code changes go into, the more code it changes, the more impossible it is to get those changes in. One of the big deals here is the "I won't approve your patch until you rewrite it the way I would have written it if I'd done it, but since I don't have the time (except to review and complain, of course -- then I have buckets of time), I'm not going to take the patch". This is called "time to get a new king instead of an asshole" effect for short.

    The lesson you should take from this is that it's not the VCS, it's the politics, and yeah, if you switch VCSs, you'll get a window when not everyone is up enough on the new stuff that they can get in your way, if you're working with smart people: they will be. So switching VCSs is typically a means of cutting through red tape that shouldn't be there in the first place, and it never works for long.

    Non-complaint #1: ESR states that bzr is "old and crufty" and that "it's mailing lists are dying and patches are dwindling", and that this is somehow bad.

    It's not bad: that's what happens with mature, purpose-built tools: once the damn things work well enough, unless you have someone pushing change for changes sake to get themselves into the commit log or README file, the changes dry up, and the tool tends not to change. So activity on a mailing list or in a commit log for a mature tool is not a way to value that tool.

    Before anyone jumps on me for this posting please read this: I personally don't use bzr, so I have no skin in this game. I've used over a dozen different VCSs, and with the exception on one that ran on DOS, which I would never use again, they're all pretty much solving the same problem, and you shouldn't really give a damn about what a projects primary maintainer likes to use, as long as the thing does the job.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close