Hacker News Reader

Comment by rbanffy | Hacker News Reader

Compared to the decision (and ability) to contribute to Emacs, the choice of DVCS seems to be rather unimportant.

It's about lowering the threshold so that when I need to patch your project, I can trivially clone the repo with software I already have installed and know, do my change, commit and create a patch or submit a pull request to Github or whatever with so little extra hassle that I feel compelled to do so rather than just making the change to my local tar-ball and never upstreaming the changes unless/until there's something large enough to be a pain to maintain separately.

Frankly, that ability is more important than the choice of DVCS: There's more value from most people standardising than in picking the "optimal" DVCS just because of the lowered barriers to participation.

The impression I have is that bzr is just another roadblock between a potentially interested novice and a patch accepted into the Emacs source.

(It's not by far the largest one, though, and while I think esr has a point, I also think it'd be of help for some of the current Emacs developers to publish a "How to start hacking Emacs" document, for the benefit of people like me who would love to contribute but who have absolutely no idea where or how to start.)

> help for some of the current Emacs developers to publish a "How to start hacking Emacs" documen

1. Find thing you don't like 2. M-x find-function RET function-to-fix RET 3. Hack hack hack (use C-M-x or M-x eval-buffer liberally; also, read about edebug) 4. Make diff relative to Emacs base code 5. Send diff to bug-gnu-emacs@gnu.org

What I love about hacking on Emacs is that it's so easy to find the bit of code responsible for a given feature and hack on that code in a running editor. There's nothing like it. If I'm using Firefox and don't like the address bar, I need to go dig through XUL, find the thing I don't like, and restart Firefox. Emacs? You just find the function and edit it right in the editor.

Thank you, yes, it's not so much finding the code I need to modify that's the problem, as understanding how any given single thing fits into the Emacs C source as a whole. Hacking the Lisp side I don't really have a problem with -- but if I want to, for example, extend the MESSAGE primitive so that it can check a list of messages not to emit in the minibuffer, things get very hairy, very fast. A general overview of what's what, and where, in the C source, would be extremely useful, and I haven't had much luck finding anything like that in the source distribution or online. (And, yes, I have read etc/CONTRIBUTE, etc/DEBUG, and (Info)Elisp/GNU Emacs Internals/*. And I'm pretty sure doing what I'm talking about doing to MESSAGE would be a bad idea, because it'd require a call up into Lisp space every time the primitive gets called, which can be extremely frequent especially during initialization. But I know somebody who'd like to have that functionality available, and it seemed like a relatively simple place to start, until I tried actually doing it.)

> There's nothing like it.

Smalltalk. I once crashed my Squeak environment by making "true := false".

Ten (edit: even five!) years ago I'd agree with you. Back then a source control system was a piece of software you used for keeping a versioned history of your work and to enable you to collaborate with coworkers or friends. It was a tool.

Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on?

>Now? It's A Big Deal to a lot of younger developers. It is almost totemic. If it's not Git and (ideally) Github then.. it isn't worth hacking on?

Do you really want those guys on your project?

I wonder if any of those guys would ever contribute to emacs anyway, unless we rewrite it in javascript.

You made me spill my coffee on the keyboard. It does seem Javascript people have taken over the obnoxious hipsterism from Ruby folks.

SNARK: No need to rewrite it in Javascript. Just call it "Sublime Text 5" and charge them seventy bucks a copy.

If the Emacs/Guile thing ever gets off the ground properly, ECMAScript/Emacs may become a possibility.

But remember: it's not because it's possible that it's a good idea. ;-)

Absolutely. Stigma over a (d)vcs !== (in)ability to contribute to a project.

Well, since they're constantly told on HN that unless they're visible on Github they aren't getting a job, why are you blaming them?

Long answer yes with a but. They will eventually take up the mantle from devs who age out or die. We might have something totally different than Git at that point but it's not good to dismiss them either. That is how projects die.

For core work, it's probably not that important. For trivial patches, it's probably kind of a pain in the neck. But a lot of people start with a small patch, so it's best to encourage them by making it easy.

With a repository the size of Emacs, it matters. Look at some of the other comments on this article here on HN, where people note that trivial bzr commands on the Emacs repo take way too long to run.

For me, I know to use subversion and git to a degree that I am really comfortable with (from the two I stronly prefer git). Another VCS means that I have to take a few leaps, new commands, subtle to extreme differences in workflow as well as different names for the same things. So a VCS that is well-known by people will (on average) make contributing more convenient to the average potential contributor.

After diving into Emacs' codebase, changing or tweaking a few things that bug me, there are a few walls to climb when actually contributing those changes. I.e. cleaning up the code, creating a patch/pull request, outlining changes and intentions, etc. An unfamiliar VCS adds another burden to the contributor. Remember that we are not talking about people who are paid for diving into their employer's VCS but about people who primarily work on other projects.

Reply on news.ycombinator.com