Vim is moving to GitHub

https://github.com/vim/vim

by brunosutic • 11 years ago

462 179 11 years ago

github.com

brunosutic4• 11 years ago

I personally am very happy about this. It will benefit the vim project tremendously.

sfk11• 11 years ago

I don't think that projects actually attract serious contributors by moving to GitHub.

iagooar2• 11 years ago

Would you elaborate? What is a serious contributor in your opinion?

brunosutic4• 11 years ago

Even if it attracts "just" serious code-reviewers that provide detailed bug reports that's a big win.

Alupis3• 11 years ago

I disagree.

I've been loosely involved in 2 open source projects which were previously hosted on self-hosted SVN repos.

After a move to Github, not only did the projects pick up new developers, but also gained a bit of visibility.

Github is something unique in my experience... it really is the "place to be" for developers wanting visibility (for any reason). A lot of folks use it as sort of a resume of skill and activeness in the community, and having public projects contributed to under their account serves to bolster that reputation.

to3m• 11 years ago

It's possible. But if they just attract drive-by patches that people like, that's fine too. Contributions from a wider range of people, that add features they're looking for (no matter how minor) will make the project more appealing to more people.

The GitHub workflow for this - submitting a patch to a project you're not heavily involved with - is very good, and probably a large contributor to the way GitHub is eating everything. No need to subscribe to a mailing list, and no need to get involved with discussions you might not be interested in. But you can easily commit to staying subscribed to your pull request/issue thread.

Of course, that may not suit all changes - but as a default, I think this arrangement a good one.

floatboth• 11 years ago

Yeah. Why would anyone on GitHub contribute to the original Vim when there's Neovim?

josinalvo6• 11 years ago

I'll offer you a 10$ to 5$ bet:

Take 10 migrated github repos at random (1) If they did not increase(2) the number of serious(3) contributors, I lose 10$. If they did, you lose 5$.

(1) random sampling: take a repo by using the last digits of a public number (like, say, the nasdaq index). Eliminate repo if "too small" or "not migrated", until you have 10

(2) compare 1 year before github to 1 year after. This gives you three numbers: at start of first year(A), at start of migration(B), at end of migration(C). N1=B/A, N2=C/B. If avg(N1) not > avg(N2), you win

(3) serious means 20 contribs in the year

(further terms will be settled upon if you want to bet, before you accept)

---

(btw, I think it might not mean much to VIM that it moved =P)

bstar77• 11 years ago

It's highly unlikely that it's going to do anything to improve vim. It seems this is being done out of necessity, namely google sunsetting Google Code. I could be wrong, but it's unlikely that Bram has had a change of heart regarding encouraging contributions.

NeoVim has my full attention; it's a forward thinking project that is doing everything I hoped Bram would do. With that said, it's going to take years before distros start standardizing on neovim, but it will happen.

sigzero5• 11 years ago

It may happen.

caniszczyk• 11 years ago

Nice

Zikes• 11 years ago

Is this an official migration or a rolling snapshot?

mkarklins• 11 years ago

Since 'code.google.com' is shutting down, this, most likely, will be the official repo.

brunosutic4• 11 years ago

That was created by vim creator and maintainer Bram himself. Link to where he made a post about that: https://groups.google.com/forum/#!msg/vim_dev/Io5A_Zir--k/fa...

aharris882• 11 years ago

He said that this is just to try out github for now. And for now the official development will be on Google Code. And then when he's ready to move it over, he'll wipe the current repository on github.

"To see how well this works I have created a SNAPSHOT of the repository. This way we can try it out. "

thomasdziedzic• 11 years ago

This is an official migration. Here is a link to an actual source since I was originally skeptical because I know vim uses mercurial and that there have been unsuccessful discussions in the past.

http://article.gmane.org/gmane.editors.vim.devel/49968

Looks like as a result, vim is also switching to git for development.

gpvos• 11 years ago

It is indeed official, but it's a try-out, not yet an actual migration.

NOTE: Before the actual migration the current repository on github will be wiped!

mizzao• 11 years ago

YES! So many old school projects hosted on janky sites that are immeasurably harder to contribute to. Looking forward to getting them all moved.

...as long as GitHub doesn't become an evil empire of some sort.

quadrangle3• 11 years ago

GitHub has done a remarkable job at being less evil than many proprietary companies… but they are doing one very annoying thing: actively undermining the free software movement by (A) getting everyone to use their proprietary tools and (B) craftily undermining the GNU GPL and related licenses by making their license-chooser and choosealicense website designed to discourage GPL use.

geon2• 11 years ago

On a site by and for programmers, it makes sense to discourage GPL in favor of permissive licenses.

lucian1900• 11 years ago

For (B), that's a good thing. Nowadays, the GPL merely prevents software from having widespread use.

tomswartz07• 11 years ago

Can you give examples of each?

Last I saw, they only (rarely) show that they have a 'GitHub Client for Win and OSX'.

Command line interface and all other Git tools are usable. Hell- when you create a new, empty repo they give you the commands to type into your terminal to upload from there.

brandonwamboldt3• 11 years ago

I disagree about point A. GitHub as a whole is proprietary, but they have an exceptionally well designed API that can be used to export issues, pull requests, and wiki data. I setup a cron to backup this data weekly in case of a catastrophic github data loss event. There are multiple open source tools to get this meta data.

I'm pretty sure there is a tool to transfer a GitHub repo and all meta data to GitLab (which is open source).

Karunamon7• 11 years ago

I think you'll find there are few arguments to be made for the open-ness of the platform (except for the religious ones) when data export is central to the platform's reason for existsnce.

Github without distributed commits isn't based on git anymore, and the other stuff is ancillary (and also easily exportable)

designed to discourage GPL use

What the hell are you on about? From choosealicense:

The GPL (V2 or V3) is a copyleft license that requires anyone who distributes your code or a derivative work to make the source available under the same terms. V3 is similar to V2, but further restricts use in hardware that forbids software alterations.

Linux, Git, and WordPress use the GPL.

This is in the middle of the front page [1]. What is discouraging or inaccurate about this?

Furthermore, the license chooser under the new repo page has the GPL as the second friggin' option [2].

Acerbic? Yes, but I don't appreciate people peddling lies.

[1] http://grab.by/FSI8

[2] http://grab.by/FSIg

Sanddancer• 11 years ago

I don't feel that they're actively underminding the GPL. I feel that they're presenting the options fairly as to what the pros and cons are for each license. Now, I'd be curious as to see if metrics would change for each license if they were to randomize the locations of the "big three", so as to give no evidence of being biased.

city414• 11 years ago

I don't think GPL needs discouragement, the dev community in large has decided they just don't like copyleft. I appreciate all that Stallman has done, but his ideas and practicality don't always align.

ta09673• 11 years ago

It need not become one to be a problem (just as it is a boon). The benefit of frictionless contributions is real, the problem of loss of federation is real just as much, and leads to the loss of community.

We're animals. The feeling of community arises when we're not alone yet feel being in private. Community is us (versus the rest). Github is a faceless "everybody" (vs. nobody left), which on the animal level translates to "me" (vs. everybody else).

It was easier to maintain a tiny community in the times of janky sites with mailing lists and diffs emailed around. Github gives you access to a larger pool of potential drive-by contributors, but you can't create a loose ring of a handful of people in /issues and /pulls. The community arises through people joining, and then failing to leave, a mailing list, and then contributing to the project through occasional replies to questions asked by beginners.

There may be seven long-term subscribers to your niche project's mailing list. When a newcomer shows up with a question, one of them might answer it before you get up. And even if they don't, their continuing passive presence on the list is still a currency that helps you push the niche project further.

Stars on a github.com repository just don't carry that much weight. Seven people might star your niche project repo. If they use their "dashboards", the entry for the new issue (the newcomer asked a support question by filing a ticket since you have no janky old school mailing list) got lost among the other tens and hundreds (even thousands) entries for individual commits and comments in repos those people have starred beside yours. They won't answer that support call for you. And, even if they did, they won't feel being part of any niche project's community either: it was just a drive-by comment on a random issue they spotted on their feed...

tldr: github.com is the largest open-plan office in the world.

nwah1• 11 years ago

NeoVim probably also inspired this.

sigzero5• 11 years ago

No, not at all. Zero in fact. It had to move. If it didn't have to move it wouldn't be.

farresito• 11 years ago

Nice to hear that. It's way more comfortable to report bugs in Github than mailing lists. I will make it easier to constribute, as well.

ggreer3• 11 years ago

Google Code is shutting down this year[1], so the Vim-dev mailing list discussed migration[2]. GitHub is the most popular host for open source projects, and Google Code has an export tool for it[3], so the switch makes a lot of sense.

That said, Vim's development method is rather conservative. Vim was created in 1988, but source control wasn't used until 2004 and Bram is the only one with write access. There are no pull requests. You have to send patches to the mailing list, where they are often dropped or forgotten. Hopefully, GitHub's features will modernize things a little and make it easier for more people to contribute to Vim.

1. http://google-opensource.blogspot.com/2015/03/farewell-to-go...

2. https://groups.google.com/d/msg/vim_dev/ehzfCDccmek/PU1sTZNd...

3. https://code.google.com/export-to-github/

zzalpha• 11 years ago

At minimum, it makes it a lot easier for a viable fork to pop up if necessary. For example, I'll bet it'll make it simpler for neovim to keep up-to-date with changes in the upstream.

guelo2• 11 years ago

Why would the source of the remote make a difference for fetching from an upstream?

mempko3• 11 years ago

It it true that patches are dropped or forgotten? Or is this a personal opinion?

brunosutic4• 11 years ago

It's true.. a lot of the patches are forgotten unless the submitter periodically "pings" Bram (the maintianer) about it.

The vim development model (patches + mailing list) has been pretty frustrating for some people. That's one of the reasons why NeoVim was forked.

ggreer3• 11 years ago

It's true if you're not one of the regular contributors. Even small patches for things like syntax highlighting seem to languish[1][2]. For stuff that requires feedback from Bram, sometimes there's just no response[3].

Sometimes it just takes a bunch of prodding from multiple users to get a patch merged[4]. Sometimes even that isn't effective[5].

I didn't have to look hard to find these examples. I just scrolled through vim-dev looking for "patch" next to an unfamiliar name. This is a common problem with mailing lists: old things fade into oblivion whether or not they've been dealt with. Not so with GitHub's pull requests. PRs stick around until someone closes or merges them. That one difference makes it much harder for contributions to slip through the cracks.

1. https://groups.google.com/d/msg/vim_dev/iB2YYel67io/SBHYHpSM...

2. https://groups.google.com/d/msg/vim_dev/UTOY6V6UCkk/-0lqupnc...

3. https://groups.google.com/d/msg/vim_dev/0It1ZTos_QY/63Xc9NrT...

4. https://groups.google.com/d/msg/vim_dev/WeBBjkXE8H8/MRLPPMjV...

5. https://groups.google.com/d/msg/vim_dev/kG3Qaz8M9kw/YyZDzwkc...

desireco422• 11 years ago

Woo hoo ! Awesome. Also, GitHub becomes sort of a borg. If some Russian kid decides to mess with it like Homakov did a while back, we are all screwed.

Congrats Vim.

otabdeveloper1• 11 years ago

Also, GitHub becomes sort of a borg. If some Russian kid decides to mess with it like Homakov did a while back, we are all screwed.

Congrats on you not having a clue what git is.

worklogin• 11 years ago

Consider how you'd phrase it if your comrade were standing next to you instead of being on the Internet.

I understand your point that git is git. The code wouldn't be lost. But it would be an undeniable several months of chaos if Github's servers were wiped. Every project standing up its own site... the open source world would effectively cease development for a short time.

na85• 11 years ago

Please keep this caustic junk on reddit where it belongs.

sfk11• 11 years ago

Git has nothing to do with it: A while ago Homakov had an exploit that gave him write privileges to all GitHub repos.

It's remarkable that no one really seems to care.

homakov2• 11 years ago

Russian kid :D

desireco422• 11 years ago

Hey you :) did they hired you already?!

feld2• 11 years ago

maybe they can tag releases more frequently instead of having a ridiculous amount of patches for each release

   % grep SHA256 /usr/ports/editors/vim/distinfo | wc -l
        559

That's a ridiculous amount of patches that need to be applied.

feld2• 11 years ago

turns out this is because FreeBSD's vim port is really bleeding edge / development and not using stable releases. But really, it shouldn't go 500 patches and still have no new release cut...

wijagels• 11 years ago

This is great, should get some visibility for the project

SEJeff3• 11 years ago

I really do wonder if there will ever be even a semi-official emacs repository on github. I suspect not, but think it would be interesting to see if people contributed to emacs using PRs.

JoshTriplett8• 11 years ago

Official or semi-official? Never, unless github's server goes FOSS at some point. When someone attempted to get github mirrors of GNOME or GCC declared "official", the official response was that anything hosted on a proprietary git hosting site should never be official.

SEJeff3• 11 years ago

Afraid you're somewhat incorrect on the GNOME repos. I happen to be one of the org members for the GNOME org on github:

https://github.com/gnome

It isn't the primary, but it is very much an official mirror. GNOME and the FSF often disagree, even if RMS will have you think otherwise.

kuschku• 11 years ago

GitHub? Probably not. But a local instance of GitLab? A lot more realistic, considering it’s Open Source and quite similar to GitHub actually.

sytse3• 11 years ago

Would love to see that :)

yeukhon• 11 years ago

Slightly off topic, but I am actually surprised "vim" was not a taken user name. Does GitHub grant special projects like vim its name if the name is taken but inactive?

aharris882• 11 years ago

That's a great question.

htor• 11 years ago

I believe you can email github and ask for a certain user name and they'll give it to you if it has no or very little activity. For instance, Ken Thompson joined github a little while ago and he got the user name 'ken'. Don't know how he did that, but I guess it helps being Ken Thompson.

o_syn• 11 years ago

On an unrelated note, why haven't there been any more modal editors?

For example, you could enter a "bold formatting" mode, where you could say type "fun" and it results in "𝐟𝐮𝐧". All these are Unicode characters, so you wouldn't need a separate document format like Word.

Presumably one can have a "math" mode where you could type math like you would type regular text obviating the dollar signs and backslashes in LaTeX.

As I understand it, LaTeX has an incredibly complicated architecture with multiple layers of macros before the lowest layer of TeX primitives. You could replace all that with Unicode symbols.

In math mode you could type "in" and get the Unicode symbol "∊". Then you would be able to copy-paste math and send it over email, instant messaging et cetera, and easily type it with a WYSIWYG editor using a traditional keyboard. Of course, there would be numerous problems with typesetting integration limits, fractions et cetera but I think these can be solved using Unicode and clever programming.

I currently do not solve say Group Theory problems on my computer because LaTeX is way too inconvenient.

I think on a hypothetical editor with a math "mode", one could touch-type math. Maybe I'm missing something and there are insurmountable obstacles to implementing such a solution. If so, I would be happy if someone could point out what they are.

Having different modes seems like a very powerful feature, and I'm just surprised the last editor using modes was written 40 years ago.

cocoablazing5• 11 years ago

Take a look at LyX.

gh02t• 11 years ago

What you're describing is an interesting idea and LyX is sort of like that. Mathematica also works pretty similarly, it has different ways of representing and entering equivalent expressions visually (e.g., TraditionalForm or DisplayForm). You can switch modes for a particular cell and the underlying meaning is preserved. There's also a special escape sequence for entering symbols and a lot of symbols have an equivalence with their obvious operators, for instance "x ∈ X" is equivalent to "Element[x, X]".

That said, it's really awful at copy-pasting into other programs my experience. But it does a decent job of exporting explicitly, like for instance with TeXForm.

Also, a slightly different thing you can do in Vim is to use the conceal feature to visually "collapse" LaTeX escapes into their unicode characters. For example, the document says "\lambda", but it will display as λ (unless you position the cursor on the same line, so that you can edit it). I find it helps reduce visual clutter a bit.

http://www.vim.org/scripts/script.php?script_id=4626

iamcurious• 11 years ago

There are no insurmountable obstacles to what you are asking. At least none that I can see now, but I do see some things that wouldn't be convenient.

First, when using other commands one should be able to input in bold as well. For instance, while searching. Otherwise, one wouldn't be able to search for the bold version since it is encoded differently.

Second, search and other commands should be aware that "f" and "𝐟" represent the same letter. Otherwise, each search becomes a game of trying all the styles to see what gets results.

Third, and this is a matter of taste, I prefer to keep the presentation separated from the structure as much as possible. I much rather write \myStyle{fun} and keep writing. Later, when the writing part is done, I can define \myStyle as bold or whatever makes sense.

slashnull• 11 years ago

What an interesting happenstance...

I just ported all my stuff to Neovim earlier this week and everything works out of the box. I just had to cp everything vim to nvim (.vim -> .nvim, .vimrc -> .nvimrc, etc).

Unfortunately there are no immediate benefits, but I agree with Neovim's long-term goals, so I suppose I'l be there when we get async plugins written in Lua.

Fice5• 11 years ago

Why is everyone so happy about the whole open source community becoming dependent on a single commercial company?

ndesaulniers• 11 years ago

It's trivial to push your local copy to bitbucket, or even your own git server. Lock in is not really an issue, in my opinion.

Fice5• 11 years ago

For increasingly many developers (potential contributors) a project effectively does not exist if it is not on GitHub. And, being a huge centralized service, GitHub is very susceptible to censorship (e.g. repos being taken down via DMCA or Russia blocking GitHub until they started to cooperate with the censors). I see this dependence as very bad and dangerous for the global free software movement.

lfowles2• 11 years ago

Indeed, the only thing that could make it better is if issues were integrated into git somehow. Maybe just another branch similar to wiki/gh-pages?

_lbaq• 11 years ago

Has VIM made any signification improvement in recent memory ?

yetanotherjosh• 11 years ago

Has my Grandpa's hammer been significantly improved in recent memory? Nope, still in my toolbox and still my favorite hammer. Ok, ok, not a good analogy but my point is that not everything actually needs constant improvement. There is a cultural bias towards newness and improvement in technology, naturally, but frankly using ViM is one way I manage to escape that on a daily basis and be thankful for stuff that works as well for me today as it did 15 years ago.

zem• 11 years ago

sure! to pick a few highlights, there was tree-style undo, integrated spellchecking and intellisense in v7, folding, diff mode and integrated remote editing and the commandline window in v6, syntax highlighting and vimscript in v5.

http://vimdoc.sourceforge.net/htmldoc/version7.html for the whole list.

bandrami• 11 years ago

The inclined plane has shown very little improvement in recent years, too.

What exactly would you like changed? I mean, the termlib stuff could be cleaned up, but that's a universal problem more than anything else.

shmerl• 11 years ago

I was just considering switching to neovim since it supports 24 bit color in the terminal.

alxndr• 11 years ago

I made the switch a week or two ago, and it was pretty painless. Kept most of my previous configuration, but only brought it over once I used it and missed it (to find out what I'm acutally using).

The one thing I haven't set up yet is YouCompleteMe (or an autocomplete replacement that uses neovim's threading), as at a quick glance it looked like it would be more than just a few minutes' setup.

mreiland• 11 years ago

oh god, what happens if someone adds the vim repo to vundle?

Please don't do it, the space time continuum will collapse.

DO NOT TRY THIS AT HOME, AT WORK, OR ANYWHERE.

Vim is moving to GitHub

Related Stories