Slashdot Mirror


Emacs Needs To Move To GitHub, Says ESR

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

25 of 252 comments (clear)

  1. Git, not Github by codl · · Score: 5, Informative

    ESR's original posting does not mention Github at all.

    1. Re:Git, not Github by Desler · · Score: 5, Informative

      "The article" (the first link which is to hypnosec's spam site) also says Github. ESR's post says merely Git.

    2. Re:git, not GitHub by fuzzyfuzzyfungus · · Score: 4, Insightful

      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!

  2. GNU Savannah supports git by byolinux · · Score: 4, Informative

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

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

  3. Git... by Anonymous Coward · · Score: 5, Informative

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

    1. Re:Git... by Anonymous Coward · · Score: 3, Informative

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

    2. Re:Git... by Desler · · Score: 3, Informative

      Ravi Mandalia is "hypnosec".

    3. Re:Git... by Desler · · Score: 5, Informative

      To add, Ravi Mandali's first version of his spam site was called "Hypno Security" which just basically regurgitated a couple of paragraphs of other people's news as "articles" and started spamming it here.

      http://www.freelancer.com/u/hypnosec.html

    4. Re:Git... by Desler · · Score: 3, Funny

      No, actually worse. His grammar and factual accuracy makes the Slashdot editors look top notch.

  4. git, not GitHub by Anonymous Coward · · Score: 5, Informative

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

  5. Surprised by DaveAtFraud · · Score: 4, Funny

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

    Cheers,
    Dave

    --
    They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
    Ben
    1. Re:Surprised by Anonymous Coward · · Score: 5, Funny

      It has everything but still lacks decent editor

    2. Re:Surprised by ebno-10db · · Score: 4, Funny

      You will spend eternity in a circle of hell where you're forced to use Notepad.

  6. Re:What's bzr? by Sponge+Bath · · Score: 5, Funny

    How bizarre.

    The cathedral and the bizarre?

  7. Re:What's bzr? by dominux · · Score: 3, Informative

    it pre-dates git by a year, it was the NiH version of cvs and svn. Bzr was doing useful stuff before anyone realised Git would ever be used for anything other than the Linux kernel source tree. That isn't to say that NiH isn't sometimes a good thing, and that Canonical do daft things from time to time, but bzr wasn't a NiH reaction to Git.

  8. What about Mercurial? by ebno-10db · · Score: 5, Insightful

    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

  9. Can't we settle this like geeks? by fuzzyfuzzyfungus · · Score: 4, Funny

    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!

  10. The usual ESR self-aggrandizement by mvdwege · · Score: 4, Interesting

    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.

    --
    "I know I will be modded down for this": where's the option '-1, Asking for it'?
  11. The real question is about Emacs by hcs_$reboot · · Score: 4, Interesting

    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.

    --
    Slashdot, fix the reply notifications... You won't get away with it...
  12. Re:Pretty sure... by mellon · · Score: 3, Informative

    A heretic uses XEmacs. An apostate doesn't take the time to install Emacs where it is not available, instead using vi. A blasphemer suggests that emacs and vi are essentially interchangeable, denying emacs' uniqueness and primacy. All three prefer emacs; only pagans and barbarians prefer something else.

  13. What prospects of Emacs left to be damaged? by Anonymous Coward · · Score: 4, Insightful

    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.

  14. Re:What's bzr? by DrXym · · Score: 3, Informative
    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.

  15. Re:What's bzr? by Lemming+Mark · · Score: 3, Informative

    I thought there was a fairly complex history here, since the current bzr was (I thought) bzr-ng originally, an alternative to some original Bazaar tool. And I thought that *that* came from GNU Arch, which (speaking loosely) I gathered wasn't well understood or enjoyable to use. I don't know how much of the current behaviour dates back that far, though, so there may not be too much in common now!

  16. The Emacs userbase is still growing by ciaran_o_riordan · · Score: 4, Interesting

    > 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

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

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

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

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

  17. Re:Emacs is an OS by munch117 · · Score: 3

    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.