We're 96(!) patches behind Vim; Can I help?

[chdiza]

We're 40 patches behind Vim today.

Is there anything I can do to help get Vim patches merged in more quickly? Personally, I don't care about issuing snapshots more quickly, since I never use snapshots. But I do think we should keep in close step with Vim at the sub-snapshot level.

Unfortunately I don't know C, but I'm sure I can help in some way with patches that don't touch MacVim specific stuff. I just don't know where to start or what to do.

[chdiza]

Bram just announced that the move to Github will be official. I don't know how that impacts the issue of keeping pace.

[chdiza]

Ninety-six!!

[splhack]

I already made a pull request #74 to merge 7.4.854 and it makes easier to merge Vim from now on.

[chdiza]

Yeah, I saw that (nice work). I wish it would be accepted.

[jpetrie]

#74 got us up-to-date.

[chdiza]

We are up to date now, mercifully, but I'm concerned that the underlying issue is not yet fully addressed. The underlying issue being the gigantic gap that opens between Vim and our pull-ins of Vim between nearly every pair of updates. These huge gaps are not the norm over the whole course of MacVim's history. @b4winckler abdicated because he realized he couldn't keep these gaps as small as they should be, but they've only grown larger.

Now there are more people with push access, which potentially helps. But whether it actually helps depends on whether (a) we will consistently act to keep the gap tiny and (b) whether, in the absence of action on our part, others have the ability to pitch in. There still needs to be published somewhere a detailed, followable set of steps for: how to pull in Vim patches, advice on resolving conflicts, how to not mess up the Bram commit history, etc. This way if the people who already know how to do this get too busy, someone industrious (user or maintainer, whichever) can make a PR.

I opened this issue because I wanted to help keep the gap small. Now I have push power (thanks, @douglasdrumond! Whether this was wise is another story 😄). But I still have no idea how to help with this, in the event that the other three pushers are busy.

[jpetrie]

Well, if @splhack is correct (and I don't have any reason to believe he's not), this should be as simple as doing git remote add vim git@github.com:vim/vim.git (once) and then fetching from vim and merging to our master:

git fetch vim
git merge vim/master

Until the vim repository gets ahead of us again, I can't test this locally, but it should work as far as I know. Once I know it does I'll add the relevant documentation to the wiki someplace.

[splhack]

Right (and I'll wait to merge vim/master a bit for that at the next time 😉).

As a matter of fact, for the past year and three months (or much longer, I've just checked Bjorn's last commit), the difference between vim/master and the Vim source code in MacVim doesn't grow much. In this span it's only blur and blurradius options. We can keep these gaps as small as they should be.

[chdiza]

I meant the gap between the official Vim patchlevel and our internal Vim's patchlevel. This gap has been enormous. Until a few days ago we were over 100 patches behind: Vim was at 7.4.889 and we were at 7.4.769. We should generally merge Vim patches as soon as Bram releases them (except e.g. when they're just Windows patches).

But you're right @splhack, the Mac-specific additions or divergences from the base Vim code should continue to be kept small. Eventually, our GUI should be merged into mainline Vim alongside (or in place of) the old Carbon GUI.

[chdiza]

A few Vim patches came out today. As a test, I did the following in my macvim repo dir:

git remote add vim https://github.com/vim/vim
git fetch vim
git checkout -b upstream_vim --track vim/master
git checkout master
git merge upstream_vim

I think the first and third steps are only needed the first time. But other than that, is that the right workflow?

Obviously there will sometimes be merge conflicts.

(I added the third step because otherwise I could see no way to checkout the plain vim branch for inspection. That's right, I can barely use git.)

[splhack]

First time,

$ git remote add vim git@github.com:vim/vim.git

Merge,

$ git fetch vim
$ git merge vim/master

[chdiza]

git remote add vim git@github.com:vim/vim.git

That doesn't work. If I follow it with git fetch. I get:

Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

[splhack]

Please take a look at https://help.github.com/articles/error-permission-denied-publickey/

[chdiza]

Forgive my ignorance, but instead of hassling with keys, can't I just do git remote add vim https://github.com/vim/vim instead? Do I have to use the ssh protocol?

(I already tried this above and it seemed to work; that's why I was double checking a few posts back that I got the commands right.)

[splhack]

It's ok. I just prefer to use ssh protocol and think ssh protocol is better in the document.

[douglasdrumond]

I, too, prefer ssh because it avoids the need to type the password, but
that can be mitigated with KeyChain.

Since this is a configuration to be done locally on every developer
machine, I have no strong opinion on what to put in the instructions.

Em qua, 14 de out de 2015 01:37, Kazuki Sakamoto notifications@github.com
escreveu:

It's ok. I just prefer to use ssh protocol and think ssh protocol is
better in the document.

—
Reply to this email directly or view it on GitHub
#46 (comment).

Douglas Drumond

Androidから送信。

[douglasdrumond]

Thank you everybody for maintaining MacVim

Em qua, 14 de out de 2015 09:37, Douglas Drumond douglas@cafelinear.com
escreveu:

I, too, prefer ssh because it avoids the need to type the password, but
that can be mitigated with KeyChain.

Since this is a configuration to be done locally on every developer
machine, I have no strong opinion on what to put in the instructions.

Em qua, 14 de out de 2015 01:37, Kazuki Sakamoto notifications@github.com
escreveu:

It's ok. I just prefer to use ssh protocol and think ssh protocol is
better in the document.

—
Reply to this email directly or view it on GitHub
#46 (comment).

Douglas Drumond

Androidから送信。

Douglas Drumond

Androidから送信。

[splhack]

@jpetrie Have you tested this locally?

[jpetrie]

@splhack Yes, it seemed to work fine locally for me.