
Vim is moving to GitHub - brunosutic
https://github.com/vim/vim
======
ggreer
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...](http://google-opensource.blogspot.com/2015/03/farewell-to-google-
code.html)

2\.
[https://groups.google.com/d/msg/vim_dev/ehzfCDccmek/PU1sTZNd...](https://groups.google.com/d/msg/vim_dev/ehzfCDccmek/PU1sTZNdsTUJ)

3\. [https://code.google.com/export-to-
github/](https://code.google.com/export-to-github/)

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

~~~
ggreer
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...](https://groups.google.com/d/msg/vim_dev/iB2YYel67io/SBHYHpSMvmAJ)

2\.
[https://groups.google.com/d/msg/vim_dev/UTOY6V6UCkk/-0lqupnc...](https://groups.google.com/d/msg/vim_dev/UTOY6V6UCkk/-0lqupnch9cJ)

3\.
[https://groups.google.com/d/msg/vim_dev/0It1ZTos_QY/63Xc9NrT...](https://groups.google.com/d/msg/vim_dev/0It1ZTos_QY/63Xc9NrTxaAJ)

4\.
[https://groups.google.com/d/msg/vim_dev/WeBBjkXE8H8/MRLPPMjV...](https://groups.google.com/d/msg/vim_dev/WeBBjkXE8H8/MRLPPMjVyYkJ)

5\.
[https://groups.google.com/d/msg/vim_dev/kG3Qaz8M9kw/YyZDzwkc...](https://groups.google.com/d/msg/vim_dev/kG3Qaz8M9kw/YyZDzwkcJMQJ)

~~~
mempko

      2. Bram responds the next day. The submitter responds to Bram a week later... 
      3. Bram responds the next day.
      4. Patch was merged after 4 months.
      5. Bram responds same day after patch is added to mailing list.
    

Looks like the response times are great!

Also it looks like a patch that is merged is put on the mailing list at the
root and not as a reply to peoples messages.

So it is hard to tell how long someone submits something and when a patch is
merged by looking at responses. You would have to find a patch someone
submitted, then find Brams "Patch" messages to find when it was merged and
compute time difference

~~~
ggreer
1\. Never merged. No replies.

2\. Never merged, though a similar patch by the same person was merged a
couple of weeks later. Try, try, again.

3\. Never merged. Waiting on Bram.

4\. Merged after 6 months, only because users constantly pestered. This patch
was 12 lines, all straightforward.

5\. Never merged. Bram said it was on his to-merge list in 2013.

All of these patches are pretty small. It shouldn't take long to reply with
"Yes", "No", or "fix this". Yet the response is often one reply, followed by
crickets. As 2 and 5 show, even the "yes" patches can fall through the cracks.

Bram's initial response can be quick, but it's often an ordeal to actually get
a patch merged, even for trivial ones. This is likely due to a combination of
Bram being a very busy person and mailing lists being terrible for this sort
of thing.

~~~
chrisbra80
1) Here the real problem is the maintainer of the syntax file who is hard to
reach. I have contacted him several times but never got fa reply. No real
problem of Vim. 2) merged February 25th. Not bad I would say (again a runtime
file problem) 3) merged with 7.4.646 4) yes, sometimes it takes a while. 5)
took long but has been merged with 7.4.652

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

~~~
gh02t
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](http://www.vim.org/scripts/script.php?script_id=4626)

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

~~~
quadrangle
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.

~~~
Karunamon
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](http://grab.by/FSI8)

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

~~~
josinalvo
I think the text for GPL is much more discouraging than the others ...

How about: "The GPL (V2 or V3) requires anyone who distributes your code - or
a derivative work - to make the source available. V3 is similar to V2, but it
also demands that, whenever the code comes "pre-installed" in a device, the
user can run a modified version in the device"

Or even: "The GPL (V2 or V3) requires anyone who distributes your code - or a
derivative work - to make the source available. V3 is similar to V2. Only
worry about the difference for code that comes "pre-installed" in a device"

~~~
Karunamon
Those edits are completely insubstantial. #1 is basically s/restrict/demand.
#2 completely obscures the actual differences with a "don't worry about it"
handwave.

The GPL is objectively a more restrictive license than BSD/MIT/Apache - just
because you think the word "restricted" is ugly doesn't change this rather
uncontroversial fact.

~~~
xorcist
I think josinalvo has a point. Can we at least agree it's not the most likely
wording that the FSF would have chosen? So while "discourage" might be too
strong, it's likely not a favorable way to put it. Perhaps a pull request
would be welcome?

~~~
Karunamon
Sure! But consider that the whole point of choosealicense is to be non-
judgmental and to explain facts, and the facts are not in question here.
Saying that the GPL is more restrictive is not some slight against the GPL, it
is a forthright explanation of its attributes.

Furthermore, the FSF are precisely the _last_ people I'd go to for a
forthright and _non judgmental_ description of the GPL and its purpose. The
FSF is at least a primary source in this matter, and furthermore an advocacy
group.

~~~
belorn
If the point of choosealicense is to be non-judgmental, they should use non-
judgmental language to do so.

So lets change the "I want it simple and permissive" text to "I want
attribution. The MIT License only requirements is that users provide
attribution back to you and don’t hold you liable."

Its a forthright and non judgmental description of the MIT license and its
purpose, and it matches perfectly with the style of the GPL description.

------
thomasdziedzic
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](http://article.gmane.org/gmane.editors.vim.devel/49968)

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

~~~
gpvos
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!_

------
yeukhon
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?

~~~
htor
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.

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

~~~
jackmaney
Not to mention the companies that use GitHub for hosting their code base in
private repos, keeping track of issues, code reviews, etc.

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

~~~
ndesaulniers
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.

~~~
Fice
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.

~~~
bacongobbler
> For increasingly many developers (potential contributors) a project
> effectively does not exist if it is not on GitHub.

I believe that's more to do with the process than the platform. Having to
remember different processes to contribute fixes/features is a pain. I can't
count how many times I had to register an account, log into their custom bug
tracker, find the darned obscure remote (looking at you, apache SVN), check
out, figure out who I have to email the patch... And then doing it all over
for a different project makes the entire process a little ridiculous. With
Github, it's ridiculously simple: Log in, fork, clone, push, PR, repeat.

> I see this dependence as very bad and dangerous for the global free software
> movement.

OTOH, having a place to call "home" for FOSS developers generates a better
sense of community. It's like hosting a conference across multiple buildings:
sure, the venue's big enough to hold X amount of people, but it doesn't seem
like there's X people attending if I can't see everyone without having to
traverse buildings.

Also,

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

~~~
Fice
I see no technical reason why GitHub could not have been implemented as a
federated system. Should we even consider convenience of a service that has
serious ethical issues?

~~~
Tiksi
I wonder how difficult it would be to federate gitlab or gogs. Set up
something like OAuth so you can log into anyone's gitlab (provided they have
to set to public) and be able to fork/clone/branch to your "home" instance of
it. Have an interface akin to github but have it pull in data from other
gitlab instances you linked/subscribed to. You could also run some sort of
public opt-in indexing service for discoverability of new projects, but the
code would be hosted on your own instance.

I'd much prefer that over github, as my account sits idle there, while my
gitlab gets plenty of use. I suppose it's something I should look into.

~~~
sytse
More thought about federation of GitLab here
[http://feedback.gitlab.com/forums/176466-general/suggestions...](http://feedback.gitlab.com/forums/176466-general/suggestions/5097708-implement-
cross-server-federated-merge-requests)

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

~~~
sfk
I don't think that projects actually attract _serious_ contributors by moving
to GitHub.

~~~
Alupis
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.

~~~
sfk
And is it a good thing to outsource one's resume to a company that _somehow,
at some point has to justify a $100.000.000 investment by Andreesen &
Horowitz_?

How are they going to do that? By selling private repos?

~~~
Alupis
> How are they going to do that? By selling private repos?

Well, yes. Github makes most of their revenue from Github Enterprise ($5,000+
per year) for large organizations.

~~~
sfk
And that revenue is large enough to justify the investment?

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

------
Zikes
Is this an official migration or a rolling snapshot?

~~~
brunosutic
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...](https://groups.google.com/forum/#!msg/vim_dev/Io5A_Zir--
k/faPCHWYfvyAJ)

~~~
aharris88
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. "

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

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

~~~
feld
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...

------
nwah1
NeoVim probably also inspired this.

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

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

~~~
JoshTriplett
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.

~~~
SEJeff
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](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.

~~~
JoshTriplett
Interesting; thanks for the correction. Last time I'd seen that discussion, I
thought the conclusion was that it was a _supported_ mirror (as in, the GNOME
project would keep it up to date), just not an _endorsed_ mirror (as in, the
GNOME project doesn't officially recommend its use).

~~~
SEJeff
Guess it depends on whom you ask :)

------
wijagels
This is great, should get some visibility for the project

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

~~~
alxndr
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.

------
walkingolof
Has VIM made any signification improvement in recent memory ?

~~~
yetanotherjosh
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.

------
caniszczyk
Nice

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

