Preparations for moving to github

[Bram Moolenaar]

Since Google Code is going to be shut down we need a new place for the
Vim repository. Many users have given their opinion and github appears
to be the preferred site.

This is not without disadvantages, since it means moving from Mercurial
to git. Some may like this, some not. Will take some getting used to.
I personally prefer the Mercurial commands, they are more obvious to
use. You can find help only for how a Mercurial command translates to
git, e.g. https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone

To see how well this works I have created a SNAPSHOT of the repository.
This way we can try it out. I already verified that I can push patches
there. However, for now development will remain on code.google.com.
The issues were already changed after the migration, this will continue.

Look here: https://github.com/vim

Please respond to the list if something doesn't work well.


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


--
TIM: Too late.
ARTHUR: What?
TIM: There he is!
[They all turn, and see a large white RABBIT lollop a few yards out of the
cave. Accompanied by terrifying chord and jarring metallic monster noise.]
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Elimar Riesebieter]

* Bram Moolenaar <Br...@Moolenaar.net> [2015-03-24 22:36 +0100]:

>
> Since Google Code is going to be shut down we need a new place for the
> Vim repository. Many users have given their opinion and github appears
> to be the preferred site.
>
> This is not without disadvantages, since it means moving from Mercurial
> to git. Some may like this, some not. Will take some getting used to.
> I personally prefer the Mercurial commands, they are more obvious to
> use. You can find help only for how a Mercurial command translates to
> git, e.g. https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone
>
> To see how well this works I have created a SNAPSHOT of the repository.
> This way we can try it out. I already verified that I can push patches
> there. However, for now development will remain on code.google.com.
> The issues were already changed after the migration, this will continue.
>
> Look here: https://github.com/vim
>
> Please respond to the list if something doesn't work well.

$ git tag | grep v7-4 | sort -V
....
v7-4-675
v7-4-676
v7-4-677
v7-4-678

but

$ egrep -A 4 "Add new patch number" src/version.c
{ /* Add new patch number below this line */
/**/
682,
/**/
681,

and

$ git log | head -8
commit 6ac42ad71294c4ef6d74e99668e88911e76d818f
Author: Bram Moolenaar <Br...@vim.org>
Date: Tue Mar 24 21:52:07 2015 +0100

updated for version 7.4.682
Problem: The search highlighting and match highlighting replaces the
cursorline highlighting, this doesn't look good.
Solution: Combine the highlighting. (Yasuhiro Matsumoto)

The tags don't seem to correspond to the latest patch version?

Elimar
--
On the keyboard of life you have always
to keep a finger at the escape key;-)

[Elimar Riesebieter]

* Bram Moolenaar <Br...@Moolenaar.net> [2015-03-24 22:36 +0100]:

>

> Since Google Code is going to be shut down we need a new place for the
> Vim repository. Many users have given their opinion and github appears
> to be the preferred site.
>
> This is not without disadvantages, since it means moving from Mercurial
> to git. Some may like this, some not. Will take some getting used to.
> I personally prefer the Mercurial commands, they are more obvious to
> use. You can find help only for how a Mercurial command translates to
> git, e.g. https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone
>
> To see how well this works I have created a SNAPSHOT of the repository.
> This way we can try it out. I already verified that I can push patches
> there. However, for now development will remain on code.google.com.
> The issues were already changed after the migration, this will continue.
>
> Look here: https://github.com/vim

Would be nice if the tags/commits would be signed ;-)

[Bram Moolenaar]

I do have the tags in my local git repository. Do they not get pushed
to the repository with "git push" ? v7-4-678 would be the last one that
was imported, the patches after that I pushed from my git repository.

--
The Law of VIM:
For each member b of the possible behaviour space B of program P, there exists
a finite time t before which at least one user u in the total user space U of
program P will request b becomes a member of the allowed behaviour space B'
(B' <= B).
In other words: Sooner or later everyone wants everything as an option.
-- Vince Negri

[Taro MURAOKA]

> I do have the tags in my local git repository. Do they not get pushed
> to the repository with "git push" ? v7-4-678 would be the last one that
> was imported, the patches after that I pushed from my git repository.

Please try "--tags" option to push. Like this:

$ git push --tags


Regards

[Elimar Riesebieter]

* Bram Moolenaar <Br...@Moolenaar.net> [2015-03-24 23:36 +0100]:

>
> Elimar Riesebieter wrote:
[...]

> > The tags don't seem to correspond to the latest patch version?
>
> I do have the tags in my local git repository. Do they not get pushed
> to the repository with "git push" ? v7-4-678 would be the last one that
> was imported, the patches after that I pushed from my git repository.

There are two more methods of "pushing" in git:

$ git help commit
$ git help tag

git commit -a -m "patch 6.4.678" --gpg-sign="your key"
git git config --global user.signingkey "your key"
git tag -s v7-4-682 -m "patch 7.4.682: The search highlighting and \

match highlighting replaces the cursorline highlighting, this \
doesn't look good."

Elimar
--
Do you smell something burning or is it me?

[Oblomov]

On Tuesday, March 24, 2015 at 10:36:32 PM UTC+1, Bram Moolenaar wrote:
> Since Google Code is going to be shut down we need a new place for the
> Vim repository. Many users have given their opinion and github appears
> to be the preferred site.
>
> This is not without disadvantages, since it means moving from Mercurial
> to git. Some may like this, some not. Will take some getting used to.
> I personally prefer the Mercurial commands, they are more obvious to
> use. You can find help only for how a Mercurial command translates to
> git, e.g. https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone

How about using BitBucket instead of GitHub? It might be a less preferrable options to some, but (1) it works largely the same way and (2) it supports mercurial directly.

[Marius Gedminas]

On Tue, Mar 24, 2015 at 11:36:02PM +0100, Bram Moolenaar wrote:
>
> I do have the tags in my local git repository. Do they not get pushed
> to the repository with "git push" ?

No, one always has to use 'git push && git push --tags'.

It's one of the biggest warts of Git IMHO.

(This being git there are of course a myriad of other options, like
'git push origin HEAD --tags' to push both the current branch and all the
tags, or 'git push --follow-tags', which only pushes reachable
_annotated_ tags created with 'git tag -a', but doesn't push regular
lightweight tags created with 'git tag'.)

(For the record, I still prefer Git to Mercurial and am very happy with
the decision to migrate to GitHub.)

Marius Gedminas
--
It's not illegal to disagree with my opinions (*).
[...]
(*) Although it obviously _should_ be. Mwhaahahahahaaa... You unbelievers
will all be shot when the revolution comes!
-- Linus Torvalds

[Bram Moolenaar]

Yes, that's an alternative. I moved Zimbu there and it seems to have
worked without trouble. Everyone who has cloned the repo still has to
manually update the remote site, thus it's not completely automatic.

Still, most users appear to prefer github. I had some problems doing
the import and the github staff was very responsive. The main problem
appears to be with the import itself (e.g., all Issue dates are reset,
there is only a comment about the original date and reporter). And yes,
you need to learn git commands.

--
Why isn't there mouse-flavored cat food?

[Bram Moolenaar]

See, that's why git is more difficult than Mercurial, so many hidden
flags and options.

--
In Africa some of the native tribes have a custom of beating the ground
with clubs and uttering spine chilling cries. Anthropologists call
this a form of primitive self-expression. In America we call it golf.

[MURAOKA Taro]

2015-03-25 19:21 GMT+09:00 Bram Moolenaar <Br...@moolenaar.net>:
>> $ git push --tags
>
> See, that's why git is more difficult than Mercurial, so many hidden
> flags and options.

Yes, I agree entirely.
Additionally, there are many sub-commands and options
which are hard to imagine feature/behavior from its name.

OTOH, I feel that git's background structure is
very simple and easy to understand.

[Bruno Sutic]

On Tuesday, March 24, 2015 at 10:36:32 PM UTC+1, Bram Moolenaar wrote:

This is great news.
From what I can tell, the reactions to this post on reddit vim group, twitter and hacker news have been very positive.

I volunteered to help in the previous thread about moving away from Google Code.. so if help is needed with drafting or testing new git-related help pages, I'm still in.

The pages that will likely need git equivalents are:
- http://www.vim.org/mercurial.php
- http://www.vim.org/develop.php

I'm curious, when a switch is made, will Github's "pull request" feature be used? Or will code contributions still be done with patches via mailing list?

I'd guess a move to "pull request" workflow will be done since it's so effortless on github, but maybe I'm jumping the gun here.

[Christian Brabandt]

Am 2015-03-25 16:21, schrieb Bruno Sutic:
> - http://www.vim.org/develop.php

I don't know yet, what the process will look like. Until now, I have
been using mercurials mq extension
but not sure how to proceed here. Perhaps using feature branches is all
what is needed...

> I'm curious, when a switch is made, will Github's "pull request"
> feature be used? Or will code contributions still be done with patches
> via mailing list?

I don't know. But notice the first pull request just arrived:
https://github.com/vim/vim/pull/349

If pull requests are not wanted, they would need to be disabled. Don't
know if
this would be possible.

@Bram, perhaps it is necessary to split the runtime directory into a
separate
github repository, so they could be easier handled.

> I'd guess a move to "pull request" workflow will be done since it's so
> effortless on github, but maybe I'm jumping the gun here.

I don't know yet. Depends entirely on Bram.

Best,
Christian

[John Szakmeister]

On Wed, Mar 25, 2015 at 11:47 AM, Christian Brabandt <cbl...@256bit.org> wrote:
> Am 2015-03-25 16:21, schrieb Bruno Sutic:

[snip]

>> I'm curious, when a switch is made, will Github's "pull request"
>> feature be used? Or will code contributions still be done with patches
>> via mailing list?
>
>
> I don't know. But notice the first pull request just arrived:
> https://github.com/vim/vim/pull/349
>
> If pull requests are not wanted, they would need to be disabled. Don't know
> if
> this would be possible.

Just wanted to answer this: it's not possible to disable pull requests
on GitHub.

-John

[Ben Fritz]

On Wednesday, March 25, 2015 at 10:21:41 AM UTC-5, Bruno Sutic wrote:
> I'm curious, when a switch is made, will Github's "pull request" feature be used? Or will code contributions still be done with patches via mailing list?
>
> I'd guess a move to "pull request" workflow will be done since it's so effortless on github, but maybe I'm jumping the gun here.

I'd like to take this a step further:

If pull requests will NOT be used, then does GitHub offer anything at all that we cannot get elsewhere? I.e. does it give any benefits beyond the fact that a lot of people are using Git?

If Bram starts using pull requests, sure GitHub makes sense because a lot of people already have accounts there. But if not...BitBucket supports Git, Kiln supports Git and also adds the grouping of multiple repositories into one project, and there may be others.

I think it would be nice to have an "official" Mercurial mirror, which isn't possible at GitHub. And I think an official mirror will be harder to maintain if we need to use multiple sites for it, especially if each site has a separate bug tracker.

By the way, I originally was going to suggest Kiln because of their "Kiln Harmony" feature which allowed using either Mercurial or Git on the *same repository*, but apparently they have quietly disabled that feature for new accounts (according to their support team in an email I sent asking about it when I couldn't find the feature). No word on whether the feature may be coming back, which is a shame, since it could solve the debate rather quickly by not needing to choose at all.

[Desmond Daignault]

There are some helpers for git hub that may be useful. I use this one: https://github.com/ingydotnet/git-hub works with cygwin on windows, and is perfect for linux environment.

[LCD 47]

On 25 March 2015, Ben Fritz <fritzo...@gmail.com> wrote:
> On Wednesday, March 25, 2015 at 10:21:41 AM UTC-5, Bruno Sutic wrote:
> > I'm curious, when a switch is made, will Github's "pull request"
> > feature be used? Or will code contributions still be done with
> > patches via mailing list?
> >
> > I'd guess a move to "pull request" workflow will be done since it's
> > so effortless on github, but maybe I'm jumping the gun here.
>
> I'd like to take this a step further:
>
> If pull requests will NOT be used, then does GitHub offer anything
> at all that we cannot get elsewhere? I.e. does it give any benefits
> beyond the fact that a lot of people are using Git?
>
> If Bram starts using pull requests, sure GitHub makes sense because
> a lot of people already have accounts there. But if not...BitBucket
> supports Git, Kiln supports Git and also adds the grouping of multiple
> repositories into one project, and there may be others.
>
> I think it would be nice to have an "official" Mercurial mirror, which
> isn't possible at GitHub. And I think an official mirror will be
> harder to maintain if we need to use multiple sites for it, especially
> if each site has a separate bug tracker.

Mirroring can be done with a hook, either client-side (a post-commit
Git hook on Bram's machine that commits and pushes to Mercurial), or
server-side (a webhook on GitHub).

Having multiple bug trackers is probably a bad idea, but bug
trackers can be disabled on the mirror sites.

> By the way, I originally was going to suggest Kiln because of their
> "Kiln Harmony" feature which allowed using either Mercurial or Git on
> the *same repository*, but apparently they have quietly disabled that
> feature for new accounts (according to their support team in an email
> I sent asking about it when I couldn't find the feature). No word on
> whether the feature may be coming back, which is a shame, since it
> could solve the debate rather quickly by not needing to choose at all.

/lcd

[Ernie Rael]

On 3/25/2015 12:12 AM, Marius Gedminas wrote:

On Tue, Mar 24, 2015 at 11:36:02PM +0100, Bram Moolenaar wrote:

I do have the tags in my local git repository.  Do they not get pushed
to the repository with "git push" ?

No, one always has to use 'git push && git push --tags'.

It's one of the biggest warts of Git IMHO.

(This being git there are of course a myriad of other options,

I recently saw this: (to add some humor to your day)

...on twitter, "generates a random man page for a made-up
git command... more or less indistinguishable from the official docs"

http://git-man-page-generator.lokaltog.net/

[Ernie Rael]

On 3/25/2015 10:18 AM, LCD 47 wrote:
> On 25 March 2015, Ben Fritz <fritzo...@gmail.com> wrote:
>>
>> I think it would be nice to have an "official" Mercurial mirror, which
>> isn't possible at GitHub. And I think an official mirror will be
>> harder to maintain if we need to use multiple sites for it, especially
>> if each site has a separate bug tracker.
> Mirroring can be done with a hook, either client-side (a post-commit
> Git hook on Bram's machine that commits and pushes to Mercurial), or
> server-side (a webhook on GitHub).

I'd welcome an auto mirror. But, depending on implementation (I guess),
I'd be concerned about reliability and increased maintenance demands.
Anyone have experience with this?

-ernie

[Birger J. Nordølum]

On Tuesday, March 24, 2015 at 10:36:32 PM UTC+1, Bram Moolenaar wrote:

A bit late to the game. But staying free and open, I think a consideration to were the code is hosted, is something to have in mind.

Recently the libreCMC project chose[1] to go with NotABug.org[2], which is hosted on an open solution[3], and run by the community. It's Git still, and not Mercurial.

Not to say Github isn't good. I however prefer a more open platform.

Just my two cents on the matter..


Sincerely,
Birger J.


[1] http://librecmc.org/librecmc/wiki?name=Source+Repository
[2] https://notabug.org
[3] http://gogs.io

[Christian Brabandt]

Hi Ernie!

On Mi, 25 Mär 2015, Ernie Rael wrote:
> ...on twitter, "generates a random man page for a made-up
> git command... more or less indistinguishable from the official docs"
>
> http://git-man-page-generator.lokaltog.net/

Hah, that one is great!

Best,
Christian
--
Abstinenz:
die Kunst, das nicht zu mögen, was man ohnehin nicht kriegt.

[Christian Brabandt]

Hi Bruno!

Anybody knows, if it is possible to forward issues and pull requests to
the vim-dev mailinglist?

Best,
Christian

--
Müde macht uns die Arbeit, die wir liegenlassen, nicht die, die wir
tun.
-- Marie von Ebner-Eschenbach

[Christian Brabandt]

Hi John!

Okay, I hope this ok for Bram. We already have 3 pull requests (for this
playground repository, that will be wiped...)

Best,
Christian
--
Es ist unmöglich, Staub aufzuwirbeln, ohne daß einige Leute husten.
-- Erwin Piscator

[LCD 47]

On 25 March 2015, Christian Brabandt <cbl...@256bit.org> wrote:
> Hi Bruno!
>
> On Mi, 25 Mär 2015, Bruno Sutic wrote:

[...]

> > This is great news.
> > From what I can tell, the reactions to this post on reddit vim
> > group, twitter and hacker news have been very positive.
> >
> > I volunteered to help in the previous thread about moving away from
> > Google Code.. so if help is needed with drafting or testing new
> > git-related help pages, I'm still in.
> >
> > The pages that will likely need git equivalents are:
> > - http://www.vim.org/mercurial.php
> > - http://www.vim.org/develop.php
> >
> > I'm curious, when a switch is made, will Github's "pull request"
> > feature be used? Or will code contributions still be done with
> > patches via mailing list?
> >
> > I'd guess a move to "pull request" workflow will be done since it's
> > so effortless on github, but maybe I'm jumping the gun here.
>
> Anybody knows, if it is possible to forward issues and pull requests
> to the vim-dev mailinglist?

Create an account for vim-dev, subscribe it to receive notifications
for the Vim repository, and set the email address to the list...

/lcd

[Amadeus Demarzi]

I am very excited that Github is being considered. It has become something of a standard for open source software these days, for better or worse, it's what most people are using which I think is good for Vim.

For those of you unfamiliar with Git, I HIGHLY recommend reading this free book:

http://git-scm.com/book/en/v2

It'll only take an afternoon to read and you can probably skip the sections on Git on the Server if you'd like, but it should provide a very stable foundation to understanding Git.

If a dumb front end javascript guy like me can figure it out, you guys should have no problem.

[Ben Fritz]

On Wednesday, March 25, 2015 at 12:18:46 PM UTC-5, LCD 47 wrote:

> On 25 March 2015, Ben Fritz wrote:
> > On Wednesday, March 25, 2015 at 10:21:41 AM UTC-5, Bruno Sutic wrote:
> > > I'm curious, when a switch is made, will Github's "pull request"
> > > feature be used? Or will code contributions still be done with
> > > patches via mailing list?
> > >
> > > I'd guess a move to "pull request" workflow will be done since it's
> > > so effortless on github, but maybe I'm jumping the gun here.
> >
> > I'd like to take this a step further:
> >
> > If pull requests will NOT be used, then does GitHub offer anything
> > at all that we cannot get elsewhere? I.e. does it give any benefits
> > beyond the fact that a lot of people are using Git?
> >
> > If Bram starts using pull requests, sure GitHub makes sense because
> > a lot of people already have accounts there. But if not...BitBucket
> > supports Git, Kiln supports Git and also adds the grouping of multiple
> > repositories into one project, and there may be others.
> >
> > I think it would be nice to have an "official" Mercurial mirror, which
> > isn't possible at GitHub. And I think an official mirror will be
> > harder to maintain if we need to use multiple sites for it, especially
> > if each site has a separate bug tracker.
>
> Mirroring can be done with a hook, either client-side (a post-commit
> Git hook on Bram's machine that commits and pushes to Mercurial), or
> server-side (a webhook on GitHub).
>
> Having multiple bug trackers is probably a bad idea, but bug
> trackers can be disabled on the mirror sites.
>

I'm sure a hook would make it much easier for Bram to maintain a mirror.
Would it actually work on the server side, though, since it requires a
plugin to be installed to actually push from git to Hg or vice versa?

I agree multiple bug trackers would be a bad idea, but I also think
going to ONE location for both bug tracker and the repository is ideal.

If Bram is using pull requests then maybe it's worth the extra hassle,
due to having so many users already on GitHub. But if Bram is not going
to use pull requests, then I think finding a provider that supports the
following features would be best:

* Ability to link a git and Mercurial repository together under one
project/folder
* Ability to have a shared issue tracker.

Optional: automatic mirroring/conversion/syncing between the two systems

I don't think BitBucket can do linked/organized repositories (there is
an open issue:
https://bitbucket.org/site/master/issue/2323/create-a-way-to-group-repositories)
and I KNOW GitHub doesn't support Mercurial. I *think* Kiln can do these
things (but maybe not the automatic mirror unless they re-enable their
Harmony feature). Does anyone know of other sites that can do all these
things and make it easy?

[Martin Lundberg]

Not sure if I'm missing something but to organize multiple repositories all you have to do is to create a Github organization described here https://help.github.com/articles/creating-a-new-organization-account/

[Bram Moolenaar]

Bruno Sutic wrote:

> This is great news.
> From what I can tell, the reactions to this post on reddit vim group, twitter and hacker news have been very positive.
>
> I volunteered to help in the previous thread about moving away from
> Google Code.. so if help is needed with drafting or testing new
> git-related help pages, I'm still in.
>
> The pages that will likely need git equivalents are:
> - http://www.vim.org/mercurial.php
> - http://www.vim.org/develop.php

Yes, we'll need to update this once it's working. The current repo can
be used to try things out. Just keep in mind that it's most likely
going to be wiped (esp. if I manage to make a mistake). Some issues are
already outdated, need to re-import them.

We'll need a new page for git. The mercurial page can be updated to
explain how to use Mercurial locally with github. Feel free to propose
something, keeping the step-by-step style.

> I'm curious, when a switch is made, will Github's "pull request"
> feature be used? Or will code contributions still be done with patches
> via mailing list?
>
> I'd guess a move to "pull request" workflow will be done since it's so
> effortless on github, but maybe I'm jumping the gun here.

I'll consider pull requests a convenient way for people to make a patch
available. We'll have to see how this can be copied to the vim-dev list
(without causing spamming). It's possible to grab a diff of the pull
request, so I can at least keep working the old way. Obviously pressing
the "merge" button won't work, it doesn't create a patch and makes
things go out of sync. But several people consider the merge button a
bad idea anyway (pull requests are often unfinshed work).

--
ARTHUR: Charge!
[They all charge with swords drawn towards the RABBIT. A tremendous twenty
second fight with Peckinpahish shots and borrowing heavily also on the
Kung Fu and karate-type films ensues, in which some four KNIGHTS are
comprehensively killed.]
ARTHUR: Run away! Run away!

[Bram Moolenaar]

Christian Brabandt wrote:

[...]

> @Bram, perhaps it is necessary to split the runtime directory into a
> separate
> github repository, so they could be easier handled.

How is that easier? Most users will want just one repo to pull from and
rebuild their local Vim, possibly with some local changes.

If runtime file maintainers want to, they can create their own
repository and send me the updated file once in a while.

--
A hamburger walks into a bar, and the bartender says: "I'm sorry,
but we don't serve food here."

[Bruno Sutic]

Hi Christian,
yes, I think it's possible to forward emails to a mailing list.

Someone who has access to the vim organization repository can setup a vim-dev email address and configure this.

In the screenshot below I tried to indicate where in the settings you can find these options:
http://imgur.com/uejBuep

An email address has to be verified (via clicking the confirmation link in an email). If this is a problem for a mailing list, I'm guessing github support may be able to bypass the verification step.

[Manuel Ortega]

On Tue, Mar 24, 2015 at 5:36 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

Since Google Code is going to be shut down we need a new place for the
Vim repository.  Many users have given their opinion and github appears
to be the preferred site.

Darn.

It would be nice if, when this gets finalized, the new repo trims out ancient stuff like 7.0, 7.1, and 7.2.  There's no reason for everyone to have to clone all that and carry it around on disk.  Yes, I know about shallow clones, but they're pretty wonky, especially wrt making PRs from a shallow clone to the main repo (not that Bram is going to look at them).

-Manny

[Ben Fritz]

On Wednesday, March 25, 2015 at 3:35:21 PM UTC-5, Martin Lundberg wrote:
> Not sure if I'm missing something but to organize multiple repositories all you have to do is to create a Github organization described here https://help.github.com/articles/creating-a-new-organization-account/

You're missing that my point was to create a Mercurial repository and a Github repository accessible from the same place, obviously related to each other, and preferably with a shared bug tracker.

Github might have repository organization like that, but it does NOT support Mercurial.

But it sounds like Bram is looking at using pull requests after all. So the sheer number of users on Github may be reason enough to go there for now.

I guess I'd like to see an official Hg mirror. But I guess I can set up my own intermediary to push/pull from Github and push/pull to and from that on my own machine if I decide to keep using Hg.

[Dominique Pellé]

I disagree. Keep the whole history:

* the whole history would bloat if had many revisions of binary files,
but that's not the case, so it should not take much more space to
keep the whole history.
* Vim is not that big. At least it's much smaller than Linux where
all history is kept in git.
* The whole history is useful at least for bisections, or find out when
a piece of code was changed and why.

Dominique

[Anton Bobrov]

On Wednesday, March 25, 2015 at 6:47:48 PM UTC+3, Christian Brabandt wrote:
> I don't know yet, what the process will look like. Until now, I have
> been using mercurials mq extension
> but not sure how to proceed here.

There is a stgit (http://procode.org/stgit/) with similar functionality.

[LCD 47]

It might. It's a common problem, if you google for "deployment from
GitHub" there are >1 mil. results. GitHub has ready-made "webhooks" for
all sort of transfer tasks and notifications, there were ~100 of them
last time I checked, and I think you can even add your own (based, of
course, on GitHub's API). But I'd say simple is likely to be better
than complex. A client-side script on Bram's machine (and on all
commiters', if any other than Bram) would be more robust, and would work
just as well.

In principle it's possible to use git-hg bridges to work on Git
repositories with Mercurial, and the other way around. It mostly
works, but I wouldn't trust that for a repository as complex as Vim's.
What I had in mind was more mundane: a single set of files that would
be both a Git and a Mercurial repository. Git and Mercurial could
be made to ignore each other, by adding .git to .hgignore and by
adding .hg to .gitignore. Then a post-commit hook in Git could simply
commit the changes it just, err, committed to Mercurial. Some minimal
porcelain code could make sure only commits to the master branch would
get mirrored, so that things like squashes and amends could happen
undisturbed in feature branches. Tags could be mirrored the same
way (although I don't remember if that could be done from the same
post-commit hook).

Then the actual pushing of the Mercurial side of the repository to
Bitbucket (or whatever) could be done, say, every 15 minutes from cron.
Pushing a repository without changes is harmless, and a failed push
would just be retried at the next cron run. There's no need for the
cron job to be aware when or how the repository gets updated.

This would be simple and robust. It only needs minimal discipline
from the commiters, and doesn't need maintenance. I doubt you can do
substantially better with a webhook on the server side.

> I agree multiple bug trackers would be a bad idea, but I also think
> going to ONE location for both bug tracker and the repository is ideal.
>
> If Bram is using pull requests then maybe it's worth the extra hassle,
> due to having so many users already on GitHub. But if Bram is not going
> to use pull requests, then I think finding a provider that supports the
> following features would be best:
>
> * Ability to link a git and Mercurial repository together under one
> project/folder
> * Ability to have a shared issue tracker.
>
> Optional: automatic mirroring/conversion/syncing between the two systems
>
> I don't think BitBucket can do linked/organized repositories (there is
> an open issue:
> https://bitbucket.org/site/master/issue/2323/create-a-way-to-group-repositories)
> and I KNOW GitHub doesn't support Mercurial. I *think* Kiln can do these
> things (but maybe not the automatic mirror unless they re-enable their
> Harmony feature). Does anyone know of other sites that can do all these
> things and make it easy?

/lcd

[Manuel Ortega]

On Thu, Mar 26, 2015 at 12:43 AM, Dominique Pellé <dominiq...@gmail.com> wrote:

Manuel Ortega <manny...@gmail.com> wrote:
>
> It would be nice if, when this gets finalized, the new repo trims out
> ancient stuff like 7.0, 7.1, and 7.2.  There's no reason for everyone to
> have to clone all that and carry it around on disk.  Yes, I know about
> shallow clones, but they're pretty wonky, especially wrt making PRs from a
> shallow clone to the main repo (not that Bram is going to look at them).
>
> -Manny

I disagree.  Keep the whole history:

* the whole history would bloat if had many revisions of binary files,
  but that's not the case, so it should not take much more space to
  keep the whole history.
* Vim is not that big. At least it's much smaller than Linux where
  all history is kept in git.

It's smaller than Linux, therefore it's not too big?  It's far too big for the kind of thing it is.  It's a plain text editor; a user shouldn't have 50MB worth of useless things (much from *eleven* years ago) hanging around.

Especially when 10% of that consists of patches to remedy accidental breakages of "tiny" builds :)

* The whole history is useful at least for bisections, or find out when
  a piece of code was changed and why.

Surely nobody needs 7.0 or 7.1 for bisection anymore.  7.3, OK.  *Maybe* 7.2.  And anyway, bisection doesn't require that it all be in one repo (unless one believes the ability to "hg bisect" is a requirement of bisecting, which it is not).

 > or find out when  a piece of code was changed and why.

Bram can (and should) put older parts under github.com/vim/70 and github.com/vim/71, and then anyone who wants to go spelunking back in time can still do so.

It's time to weigh the benefits of keeping ancient code in the main repo against the benefits of a small repo.  Keeping the *whole* history benefits a very small number of people on very rare occasions.  Making a smaller repo benefits everyone on nearly all occasions, and at most mildly inconveniences the very few people on those very rare occasions.

Actually I would be fine with the following:  perhaps there can be one giant development repo, and one "distribution" repo that only contains 7.4's history.  The latter would get changes to the former merged in (perhaps automatically).  While that was impossible with Hg (I think), this should be possible if the switch to git becomes official, right?

-Manny

[Ingo Karkat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26-Mar-2015 14:32, Manuel Ortega wrote:
> It's smaller than Linux, therefore it's not too big? It's far too
> big for the kind of thing it is. It's a plain text editor; a user
> shouldn't have 50MB worth of useless things (much from *eleven*
> years ago) hanging around.

With the broadband connections that most of us now fortunately have,
50 MB is nothing. People stream / download entire HD movies all the
time. Java projects using Maven routinely download half of the
Internet to get to a build :-)

> Surely nobody needs 7.0 or 7.1 for bisection anymore. 7.3, OK.
> *Maybe* 7.2. And anyway, bisection doesn't require that it all be
> in one repo (unless one believes the ability to "hg bisect" is a
> requirement of bisecting, which it is not).

I find the information when something was last changed very valuable.

> Bram can (and should) put older parts under github.com/vim/70

> <http://github.com/vim/70> and github.com/vim/71
> <http://github.com/vim/71>, and then anyone who wants to go

> spelunking back in time can still do so.
>
> It's time to weigh the benefits of keeping ancient code in the main
> repo against the benefits of a small repo. Keeping the *whole*
> history benefits a very small number of people on very rare
> occasions. Making a smaller repo benefits everyone on nearly all
> occasions, and at most mildly inconveniences the very few people on
> those very rare occasions.

I'd argue the other way: Most people don't care about the full
download (which needs to be done only once on initial checkout). There
may be some poor fellows with poor connections; if you or some other
volunteer would like to provide lighter repo versions, just do so.
Bram already is a bottleneck in development; please don't make him
work harder by adding yet more complexity in repo maintenance!

- -- regards, ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVFAzlAAoJEA7ziXlAzQ/voX0H/24Ep5qaSKLGaXYl1GV9cdG1
PB1a+YbT93NxKes/9SrLt/N2yChauyUliY76c69MHyT4wBCTQ7PFul0tT69mJJYr
YyB7d81Js0vzJbba8/3b6lzxWgXZwfdMZhY/evjLAONWOz9kDZYURSif0O4uWm1T
pfZBqm/IeJuWPO2zglfVtlt8cjoHxvXtJ63DI//TJUkFX6wXV9VqucAXEstvHhar
q3oXCxWqrx/t4P0ZBRWNKH/bQKX2gmYgefAPsrZBg9VWqV//PgViG0DAQLFr2iAW
48nDkSg4EUahbLyFmWbjLjKP0m69+xlbP97hi7fNO0VVIlMnakrhK0q7bB23qFo=
=dMfm
-----END PGP SIGNATURE-----

[Christian Brabandt]

Am 2015-03-25 21:48, schrieb Bram Moolenaar:
> Christian Brabandt wrote:
>
> [...]
>
>> @Bram, perhaps it is necessary to split the runtime directory into a
>> separate
>> github repository, so they could be easier handled.
>
> How is that easier? Most users will want just one repo to pull from
> and
> rebuild their local Vim, possibly with some local changes.

Well, it could be co-maintained, taking burden from you to merge runtime
file changes,
or documentation updates and you could concentrate on the code.

Best,
Christian

[James McCoy]

On Mar 25, 2015 7:18 PM, "Manuel Ortega" <manny...@gmail.com> wrote:
>
> On Tue, Mar 24, 2015 at 5:36 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>>
>>
>> Since Google Code is going to be shut down we need a new place for the
>> Vim repository.  Many users have given their opinion and github appears
>> to be the preferred site.
>
>
> Darn.
>
> It would be nice if, when this gets finalized, the new repo trims out ancient stuff like 7.0, 7.1, and 7.2.  There's no reason for everyone to have to clone all that and carry it around on disk.

$ git clone https://github.com/vim/vim
...
$ cd vim
$ du -hs .git .
685M    .git
47M     .
$ git gc --aggressive
...
$ du -hs .git .
34M     .git
47M     .

For reference, are similar numbers for a fresh Mercurial clone:

$ du -hs .hg .
55M     .hg
47M     .

I'm not sure if there's something that can be done so that the initial git clone has similar results as the post-gc results, but an extra 34M of disk space isn't worth the added complexity of juggling multiple repos.

Note that I also find bisecting to be very useful and have used it many times when working on Vim, so I am also in the camp of not hampering that functionality because of a one time cost.

[Guyzmo]

Hi there,

On Thu, Mar 26, 2015 at 09:32:32AM -0400, Manuel Ortega wrote:
> On Thu, Mar 26, 2015 at 12:43 AM, Dominique Pellé <dominiq...@gmail.com wrote:
> > Manuel Ortega <manny...@gmail.com> wrote:
> > or find out when a piece of code was changed and why.
> Bram can (and should) put older parts under github.com/vim/70 and
> github.com/vim/71, and then anyone who wants to go spelunking back in time
> can still do so.

usually a nice way of working that out is to use some branch-release
strategy. Basically, when you're working towards version N:

- you use a branch `devel-N`,
- then when it's ready for freeze-time, you branch it as `freeze-N`
- then when it's ready for release you squash all the commits of the
branch within the release branch
- then you fork the release branch towards `devel-N+1` and start over

that way, when you want to get the release branch you just git clone
(or fork) the `release` branch (or master or whatever the name you give
it) but not the other ones. Until you don't fetch older branches, you're
all set.

That was just for the "getting all history" point. I still believe that
vim's history is not huge, and shouldn't be an issue. Just get mozilla's
sources and there you'll get some fun :-)

my 2 cents,

--
Guyzmo

[Manuel Ortega]

On Thu, Mar 26, 2015 at 9:43 AM, Ingo Karkat <sw...@ingo-karkat.de> wrote:

> Bram already is a bottleneck in development; please don't make him

work harder by adding yet more complexity in repo maintenance!

It's quite obvious that almost nobody on this list cares about adding complexity for Bram; it they did, they would not be insisting that he switch over to git rather than just moving the repo to BB and beind done with it.

-Manny

[Ingo Karkat]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've followed this entire thread; Bram explicitly asked for feedback,
and showed his openness about switching to GitHub (and thereby Git);
he's even considering using pull requests (which I'm quite fond of; it
could streamline the current process of posting patches (and
occasionally updates to them)). He could have simply said "Mercurial
is set", and GitHub would have been out.

I was referring to continuous overhead (like pruning the repo);
whereas switching version control systems is a one-time effort only.

- -- regards, ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVFEdJAAoJEA7ziXlAzQ/vxq4H/1fh5hKDSRq6tSZqXloQIW/I
KiIVRFSdsREWR2I5clB1tNpqHcS5p9R7TX5+gZnh6bayLzI8iSNtPNS+X80HUaaY
BDkJJcq2mRPI2+f43MVPHTaS6IboSQ6Sm1mWlBEZpehMpyFmCLyKWDB6XWwZAdni
G9n3ufBm/hxNxO/tpmvUuxo/SbCYfJPIh1fVFv1ipZfobFSUI8W72wZDVbrMUTMp
sF5xajeo7uW3R8lv18iP+5mteI2NyV7cVa/y0KdmhCD6bhahL+UsUmPS00sY/5dB
Lf6LfSDTjcYFaS79WOJ7AemJZZlnIu98Fd0JJMbP9Qz9c0sDiw9eMiBXuZuRbwY=
=b7ra
-----END PGP SIGNATURE-----

[Bram Moolenaar]

Isn't there a way to clone only up to some time ago, e.g., the 7.4
release? I rather leave this a decision on the user side than on the
server side (meaning that history would be lost forever).

--
An indication you must be a manager:
You give constructive feedback to your dog.

[Elimar Riesebieter]

* James McCoy <jame...@jamessan.com> [2015-03-26 11:26 -0400]:

[...]

> $ git clone https://github.com/vim/vim
> ...
> $ cd vim
> $ du -hs .git .
> 685M .git
> 47M .
> $ git gc --aggressive
> ...
> $ du -hs .git .
> 34M .git
> 47M .
>
> For reference, are similar numbers for a fresh Mercurial clone:
>
> $ du -hs .hg .
> 55M .hg
> 47M .
>

[...]

* Bram Moolenaar <Br...@Moolenaar.net> [2015-03-26 21:00 +0100]:

>
> Manuel Ortega wrote:
[...]

> > It would be nice if, when this gets finalized, the new repo trims out
> > ancient stuff like 7.0, 7.1, and 7.2. There's no reason for everyone to

> > have to clone all that and carry it around on disk. Yes, I know about
> > shallow clones, but they're pretty wonky, especially wrt making PRs from a
> > shallow clone to the main repo (not that Bram is going to look at them).
>
> Isn't there a way to clone only up to some time ago, e.g., the 7.4
> release? I rather leave this a decision on the user side than on the
> server side (meaning that history would be lost forever).

As James pointed out: There is not that much space needed! So please
keep the history as it is quite easy to filter tags the user wants
to work on.

Elimar

--
Experience is something you don't get until
just after you need it!

[John Szakmeister]

On Thu, Mar 26, 2015 at 11:26 AM, James McCoy <jame...@jamessan.com> wrote:
[snip]

> $ git gc --aggressive
> ...
> $ du -hs .git .
> 34M .git
> 47M .

Just wanted to point out that there's really no need for
"--aggressive" here. "git gc" without it will often produce similar
results in less time. :-)

-John

[Kana Natsuno]

On Friday, March 27, 2015 at 5:00:19 AM UTC+9, Bram Moolenaar wrote:
> Isn't there a way to clone only up to some time ago, e.g., the 7.4
> release? I rather leave this a decision on the user side than on the
> server side (meaning that history would be lost forever).

git clone --depth 1

[James McCoy]

I initially ran just "git gc" and there was no change in disk space.  I'm using a new enough git that it periodically kicks off a background "git gc" after a normal git command. Maybe clone is one those cases.

[Manuel Ortega]

While "git gc" will *sometimes* produce similar results to "git gc --aggressive", it very, very often in my experience does not.  This is perhaps one of those cases.

-Manny 

[Ben Fritz]

On Tuesday, March 24, 2015 at 4:36:32 PM UTC-5, Bram Moolenaar wrote:
>
> Look here: https://github.com/vim
>
> Please respond to the list if something doesn't work well.
>

When I click the "branches" tab I get a Unicorn! error page saying "This page is taking way too long to load."

Somehow I don't think that's a good thing. Is this because of something weird in the Vim repository? Some temporary fluke? Some problem with the conversion?

[James McCoy]

It's not just the Vim repo. Github is being DDoSed: https://status.github.com/messages

Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>

[Jan Larres]

James McCoy <jame...@jamessan.com>:

> $ git clone https://github.com/vim/vim
> ...
> $ cd vim
> $ du -hs .git .
> 685M .git
> 47M .
> $ git gc --aggressive
> ...
> $ du -hs .git .
> 34M .git
> 47M .

The Google Code to GitHub exporter seems to do a pretty bad job at finding
good deltas; I've seen other projects that were exported with it and had a
similarly bloated repository. I would probably be a good idea to contact
GitHub support and ask them to perform an aggressive gc on the server so that
first-time cloners don't have to download so much junk.

-Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
The most dangerous phrase in the language is, "We've always done it this
way."
-- Grace Hopper

[Marius Gedminas]

On Fri, Mar 27, 2015 at 04:42:31PM +1300, Jan Larres wrote:
> James McCoy <jame...@jamessan.com>:
> > $ git clone https://github.com/vim/vim
> > ...
> > $ cd vim
> > $ du -hs .git .
> > 685M .git
> > 47M .
> > $ git gc --aggressive
> > ...
> > $ du -hs .git .
> > 34M .git
> > 47M .
>
> The Google Code to GitHub exporter seems to do a pretty bad job at finding
> good deltas; I've seen other projects that were exported with it and had a
> similarly bloated repository. I would probably be a good idea to contact
> GitHub support and ask them to perform an aggressive gc on the server so that
> first-time cloners don't have to download so much junk.

I pinged @GitHub on Twitter and they say they've fixed this on the server
side: https://twitter.com/vmg/status/581144886826672130

'git clone' now needs to download only 32 megs, yay!

mg@platonas: /tmp $ git clone https://github.com/vim/vim vim2
Cloning into 'vim2'...
remote: Counting objects: 51714, done.
remote: Total 51714 (delta 0), reused 0 (delta 0), pack-reused 51714
Receiving objects: 100% (51714/51714), 32.43 MiB | 527.00 KiB/s, done.
Resolving deltas: 100% (41960/41960), done.
Checking connectivity... done.

[1m11s]
mg@platonas: /tmp $ du -chs vim2/.git
35M vim2/.git
35M viso

mg@platonas: /tmp $ du -chs vim2
81M vim2
81M viso

Marius Gedminas
--
Si fractum non sit, noli id reficere.

[John Szakmeister]

On Thu, Mar 26, 2015 at 8:48 PM, Manuel Ortega <manny...@gmail.com> wrote:
[snip]

> While "git gc" will *sometimes* produce similar results to "git gc
> --aggressive", it very, very often in my experience does not. This is
> perhaps one of those cases.

--aggressive is really about letting Git go back and giving it a clean
slate about delta choices, rather that aggressively compressing the
data--which is why using this option slows things down considerably.
The default depth settings are quite large with --aggressive, and it
*can* make a big difference, especially if it came from somewhere else
(converted from another source). It looks like it was really needed
it here--see Jan Larres's email. In practice though, most
repositories see little benefit, IMHO--the greatly increased running
time of the gc operation wasn't worth the 0-2MB of cost savings that I
often saw.

There was actually discussion of removing the option a while back, but
I'm glad they kept it around for situations like this one. FWIW, when
it has been useful, running it once was usually good enough.

/me going back to lurk mode now. :-)

-John

[Alejandro Exojo]

El Thursday 26 March 2015, Christian Brabandt escribió:
> Am 2015-03-25 21:48, schrieb Bram Moolenaar:
> > Christian Brabandt wrote:
> >
> > [...]
> >
> >> @Bram, perhaps it is necessary to split the runtime directory into a
> >> separate
> >> github repository, so they could be easier handled.
> >
> > How is that easier? Most users will want just one repo to pull from
> > and
> > rebuild their local Vim, possibly with some local changes.

The runtime directory could be a submodule inside the main repository.

> Well, it could be co-maintained, taking burden from you to merge runtime
> file changes,
> or documentation updates and you could concentrate on the code.

Yes, please. It would help to prevent that things like these happen again:

https://groups.google.com/forum/#!topic/vim_dev/MszvcBd8p1Q

Compare how this two have evolved:

https://github.com/vim-jp/vim-cpp/commits/master/syntax/cpp.vim
https://github.com/vim/vim/commits/master/runtime/syntax/cpp.vim

I personally have not even thought of contributing to runtime files because of
this "workflow".

--
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net

[Bram Moolenaar]

I'm very glad to see that Github staff is this responsive.
It gives confidence.

Now I have the problem that it appears many people are already using the
try-out import. I might want to delete it and do it for real
soon. Problem is that Google code doesn't support the read-only state
yet, only an ugly redirect (you can see this on my Zimbu project:
code.google.com/p/zimbu). And the repo still works, this is a weird state
that I don't want to put Vim into.


--
MONK: ... and the Lord spake, saying, "First shalt thou take out the Holy Pin,
then shalt thou count to three, no more, no less. Three shalt be the
number thou shalt count, and the number of the counting shalt be three.
Four shalt thou not count, neither count thou two, excepting that thou
then proceed to three. Five is right out. Once the number three, being
the third number, be reached, then lobbest thou thy Holy Hand Grenade of
Antioch towards thou foe, who being naughty in my sight, shall snuff it.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Bram Moolenaar]

Right, that is what I was looking for. So whoever just wants a
convenient way to pull the latest version can use this as the fastest
method. We should add this to the instructions (e.g. for users who have
limited bandwidth).

--
I wonder, do vegetarians eat fruit bats?

[Peter Aronoff]

On Friday, March 27th, 2015 at 9:11AM, Bram Moolenaar wrote:
>
> Kana Natsuno wrote:
>
> > On Friday, March 27, 2015 at 5:00:19 AM UTC+9, Bram Moolenaar wrote:
> > > Isn't there a way to clone only up to some time ago, e.g., the 7.4
> > > release? I rather leave this a decision on the user side than on the
> > > server side (meaning that history would be lost forever).
> >
> > git clone --depth 1
>
> Right, that is what I was looking for. So whoever just wants a
> convenient way to pull the latest version can use this as the fastest
> method. We should add this to the instructions (e.g. for users who have
> limited bandwidth).

For users who do this, when they update, I believe they will need the
following:

git pull --update-shallow

Otherwise, any normal update (via `git pull` or `git fetch`) will pull down
everything.

Peter
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

[Manuel Ortega]

On Fri, Mar 27, 2015 at 9:13 AM, Peter Aronoff <telem...@arpinum.org> wrote:

On Friday, March 27th, 2015 at 9:11AM, Bram Moolenaar wrote:
>
> Kana Natsuno wrote:
>
> > On Friday, March 27, 2015 at 5:00:19 AM UTC+9, Bram Moolenaar wrote:
> > > Isn't there a way to clone only up to some time ago, e.g., the 7.4
> > > release?  I rather leave this a decision on the user side than on the
> > > server side (meaning that history would be lost forever).
> >
> > git clone --depth 1
>
> Right, that is what I was looking for.  So whoever just wants a
> convenient way to pull the latest version can use this as the fastest
> method.  We should add this to the instructions (e.g. for users who have
> limited bandwidth).

For users who do this, when they update, I believe they will need the
following:

    git pull --update-shallow

Otherwise, any normal update (via `git pull` or `git fetch`) will pull down
everything.

No, that's not the case.  You can just do a regular git pull.  I do this all the time with other repos that I shallowly clone, such as Homebrew.

If you *want* to pull in the full history after starting with a shallow clone, then you need to add flags.  E.g., `git fetch --unshallow`.

-Manny 

[Peter Aronoff]

On Friday, March 27th, 2015 at 9:47AM, Manuel Ortega wrote:
> No, that's not the case. You can just do a regular git pull. I do this
> all the time with other repos that I shallowly clone, such as Homebrew.
>
> If you *want* to pull in the full history after starting with a shallow
> clone, then you need to add flags. E.g., `git fetch --unshallow`.

Ok. You may very well be right, but I know I've had trouble updating
shallow clones without that extra flag. In short, such repos often end up
in "broken merge" state, in my experience after trying to update. It's
possible that I was doing something *else* wrong, but I can't really think
of what. As I recall, I only ran "git pull".

Thanks, Peter

[Ben Fritz]

I'd just like to point out that all you githeads arguing over the various different options on pull and fetch and whether they break or keep your repository intact, are making me VERY sad about losing Mercurial.

Bram, is there a chance you'd be willing to also push to a Mercurial mirror using one of the various bridge methods, either automatically via repository hook or manually when you push patches to the public repo?

If so, are we definitely set on GitHub? Has anyone found a hosting site that allows you to have one landing page for both a git and a Hg repository?

[Christian Brabandt]

Hi Ben!

If I have understood correctly, it's easy enough to setup a mirror
somewhere else. If that is straightforward, I could set it up for github
to mirror somewhere else (bitbucket?)

Bram, would you like to create an official vim account at bitbucket or
do you want me to do it?

Best,
Christian
--

[Ben Fritz]

On Friday, March 27, 2015 at 11:28:42 AM UTC-5, Christian Brabandt wrote:
>
> If I have understood correctly, it's easy enough to setup a mirror
> somewhere else. If that is straightforward, I could set it up for github
> to mirror somewhere else (bitbucket?)
>

Yes, it's pretty easy to set up clones elsewhere. I thought it would be
nice to have a single project page though, with a single issue tracker,
etc. rather than pointing to two separate sites that don't obviously
relate to each other in any way. Am I alone in that desire?

I've been playing around a little bit, but wasn't *quite* ready to share
just yet. I still have some playing to do but here's what I've seen:

BitBucket, as we've discussed, allows both Git and Mercurial
repositories. It is possible to create a "team" and then create multiple
repositories under this team. This would allow a single project page for
both the git and Hg repositories. The built-in issue tracker is for
single repositories only, HOWEVER BitBucket integrates with the JIRA
tool which we could use as a single shared bug tracker
( https://bitbucket.org/site/master/issue/5654/share-issue-tracker-amongst-projects).
JIRA is free to use for open-source projects so we'd be able to do
that without paying any money to Atlassian
( https://www.atlassian.com/software/views/open-source-license-request ).
But that's where I stopped looking into it, I don't know how easy JIRA
is, or how easy it is to find it from the team project page. I plan to
grab a free trial to see how that looks at some point in the next couple
days.

Kiln may be another option, with a similar setup, although their site is
more geared toward commercial software. we'd create a "project" and put
a Hg and a git repository under that project. Their issue tracker is
FogBugz. It isn't made explicit on their website, but I talked with a
sales rep. over at Fog Creek who said they do give free accounts to
open-source projects (going beyond the default "2 free users" accounts).
I did run into a problem there, where although the repositories can be
public, and issues can be created anonymously, there isn't an obvious
way to make the issue tracker publicly browse-able. The rep. I talked to
is getting back to me on whether that is possible.

Sadly Kiln's "Harmony" project, which allowed accessing the SAME
repository transparently using either Git or Mercurial, with no bridges
needed, has been retired for new accounts. So it would still be a manual
mirroring process. It would just be all on one project page.

If we go with a non-GitHub provider, the drawback is that pull requests
from GitHub won't be done automatically. But a manual "pull, merge,
commit, push" will obviously still work. And it sounded like Bram wanted
to export pull requests as patches anyway. And, nothing would stop
people from creating a BitBucket or whatever account and creating pull
requests over there.

Plus, you know, maybe someday it will "just work":
https://bitbucket.org/site/master/issue/3288/remote-pull-requests-to-google-code-and

[Bram Moolenaar]

Ben Fritz wrote:

> I'd just like to point out that all you githeads arguing over the
> various different options on pull and fetch and whether they break or
> keep your repository intact, are making me VERY sad about losing
> Mercurial.

Keep in mind that 95% of the users will only use the very simple
commands. For myself I have copied and adjusted the small scripts I
used for Mercurial. Typing "git pull" and "hg pull" isn't that much
different...

> Bram, is there a chance you'd be willing to also push to a Mercurial
> mirror using one of the various bridge methods, either automatically
> via repository hook or manually when you push patches to the public
> repo?

I do not plan to push to more than one repository, as the use is very
limited. But if someone wants to setup an automatic mechanism to mirror
a repository, e.g. on Bitbucket, that's fine. We can mention this on
the vim.org pages. Although using Mercurial to pull from Github is
likely to work for most people.

> If so, are we definitely set on GitHub? Has anyone found a hosting
> site that allows you to have one landing page for both a git and a Hg
> repository?

Github is preferred by most users. There is not going to be a place
that 100% of the users are 100% happy with. Of course there will be
some pain when switching over, it is unavoidable. Also when sticking
with Mercurial (as I have experienced with Zimbu already).

--
User: I'm having problems with my text editor.
Help desk: Which editor are you using?
User: I don't know, but it's version VI (pronounced: 6).
Help desk: Oh, then you should upgrade to version VIM (pronounced: 994).

[Bram Moolenaar]

Looks like Vim on bitbucket is taken. You could ask them if they can
make it available. Or we can use vim-mirror, to make clear it's not the
main one. It would be great if you can set this up (less work for me
:-).

--
ARTHUR: But if he was dying, he wouldn't bother to carve
"Aaaaarrrrrrggghhh". He'd just say it.
BROTHER MAYNARD: It's down there carved in stone.
GALAHAD: Perhaps he was dictating.

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Benjamin Fritz]

On Fri, Mar 27, 2015 at 12:18 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:

> > Bram, is there a chance you'd be willing to also push to a Mercurial

> > mirror using one of the various bridge methods, either automatically

> > via repository hook or manually when you push patches to the public

> > repo?

>

> I do not plan to push to more than one repository, as the use is very

> limited.  But if someone wants to setup an automatic mechanism to mirror

> a repository, e.g. on Bitbucket, that's fine.  We can mention this on

> the vim.org pages.  Although using Mercurial to pull from Github is

> likely to work for most people.

>

What about if you just needed to do a one-time setup, to automatically

push to Hg when you push to your public Git repository, using a

repository hook and one of the bridges?

Then (if you really start using pull requests) you could pull from

either system easily as well.

> > If so, are we definitely set on GitHub? Has anyone found a hosting

> > site that allows you to have one landing page for both a git and a Hg

> > repository?

>

> Github is preferred by most users.  There is not going to be a place

> that 100% of the users are 100% happy with.  Of course there will be

> some pain when switching over, it is unavoidable.  Also when sticking

> with Mercurial (as I have experienced with Zimbu already).

>

Github is preferred by most *git* users. Because they already use git

and already have a Github account.

But Github doesn't support Mercurial AT ALL. Sure there is hg-git but it

isn't always smooth, and Hg users will still be limited to git clones on

Github for contributing.

If we use Bitbucket (or another service that supports both), nobody

needs to learn a new tool. And we can combine both repositories together

under one project page. People could clone server-side from either

repository depending on their system of choice, and that decision

wouldn't impact their ability to easily contribute back.

Of course, I suppose we could always link to two sites from one vim.org

page. But I'd rather any Hg repository be just as "valid" as the Github

one, not some read-only mirror nobody looks at. But it sounds like that

is the way it is heading.

[James McCoy]

On Mar 27, 2015 1:32 PM, "Benjamin Fritz" <fritzo...@gmail.com> wrote:
> If we use Bitbucket (or another service that supports both), nobody
> needs to learn a new tool. And we can combine both repositories together
> under one project page. People could clone server-side from either
> repository depending on their system of choice, and that decision
> wouldn't impact their ability to easily contribute back.
>
> Of course, I suppose we could always link to two sites from one vim.org
> page. But I'd rather any Hg repository be just as "valid" as the Github
> one, not some read-only mirror nobody looks at. But it sounds like that
> is the way it is heading.

Why should this be different than any other open source project?  If you want to contribute, you need to learn the tools that are being used. When tools change, then something different needs to be learned. It's not up to the project to accommodate every user's individual desires.

I didn't know Mercurial when Vim switched to it from CVS, but I've learned to use it.  Other projects I contribute to use git. Thanks to that I'm now comfortable with both Mercurial and git.

Change happens.

Having a canonical repo for Vim's code is important. Introducing multiple repos for a single codebase just increases the risk of errors. I've never encountered a project which officially supports more than one (especially with differing VCS). Unofficial mirrors I've seen, but people using those communicate suggested changes back by using patches and email.

[Ben Fritz]

On Friday, March 27, 2015 at 1:21:48 PM UTC-5, James McCoy wrote:
> Why should this be different than any other open source project?  If
> you want to contribute, you need to learn the tools that are being
> used. When tools change, then something different needs to be learned.
> It's not up to the project to accommodate every user's individual
> desires.
>

Because so far the ONLY reason I've seen for moving to git AT ALL is "it
makes the git users happy." Why are the git users more important than
the Mercurial users?

And generally projects move to obviously better or easier tools, when
there is consensus that the tools are obviously better or easier.

We're talking about moving to a tool with equivalent features, but that
is harder to learn, easier to screw up, and has more complications to
keep in mind. And we had no consensus for the move. What we had was a
bunch of "hey you should move to github!" drive-by posts, followed up by
responses as to why we shouldn't, and then Bram came out and said "well
I moved us to Github even though I like git better, because most people
wanted that".

Personally I disagree with the move to git AT ALL. We should have stayed
on the system we were using, and shutting down the hosting provider is
not a good excuse to change systems. It's a good excuse to find a new
hosting provider. It's not even like GitHub has obvious benefits over
BitBucket or anywhere else. In fact it has obvious drawbacks: we are
REQUIRED to change systems if we go there.

But it looks like reasoned decision making is being overwhelmed by git's
inertia for yet another project. Don't bother setting up a mirror if
it's just a throwaway read-only copy no better than a glorified FTP
server. If I want to I can pull directly from Github with hg-git.
Dealing with that will be easier than dealing with multiple separate
repository locations.

[Amadeus Demarzi]

Ben: I would argue that Github provides a huge variety of useful tools to manage Vim that will net a major net positive going forward.

Having a central place for issues and patches that is very familiar to many developers will help to make the barrier of entry for new contributors far lower as well. I don't think that should be discounted at all. It's not to just make users happy.

We can't forget either that a MAJOR part of the Vim plugin ecosystem lives on Github already.

While I don't have any data to back up this post. the fact that there are a lot of 'driveby' posts referencing github shows that many people actively follow this mailing list, and just because they may not post often, doesn't mean they aren't interested in the future of vim.

Saying that git is easier to screw up is a bit misleading. There's a learning curve with any new tool, but that doesn't necessarily mean it's more prone to screw ups. There are right and wrong ways to use any tools. I am just some punk kid who writes javascript all day, and I can easily grasp Git, it's not that hard.

I've been maintaining a vim fork on Github for a while. The conversion was fairly simple, so I don't see that as a major drawback either.

[Navdeep Parhar]

On 03/27/2015 12:00, Ben Fritz wrote:
> On Friday, March 27, 2015 at 1:21:48 PM UTC-5, James McCoy wrote:
>> Why should this be different than any other open source project? If
>> you want to contribute, you need to learn the tools that are being
>> used. When tools change, then something different needs to be learned.
>> It's not up to the project to accommodate every user's individual
>> desires.
>>
>
> Because so far the ONLY reason I've seen for moving to git AT ALL is "it
> makes the git users happy." Why are the git users more important than
> the Mercurial users?

+1 to this part. vim was already being developed as an open source
project and all contributors, lurkers, and people with private patches
against vim had learned the tools that were being used and had figured
out their workflows. Everything was just fine. The project was forced
to change hosting providers but imho changing the VCS was unnecessary.

Regards,
Navdeep

[Manuel Ortega]

We can't forget either that a MAJOR part of the Vim plugin ecosystem lives on Github already.

I don't know why people keep bringing this up.  It's (a) not even clear that it is true, and (b) even if it is true, it strikes me as completely irrelevant to the question of where to host vim.  Who cares where the plugins are?  Is one's day going to be made more difficult because one had to type in a non-github URL to go fetch a plugin?  It's not as if there need to be PRs between a plugin repo and the Vim repo.

On 03/27/2015 12:00, Ben Fritz wrote:

On Friday, March 27, 2015 at 1:21:48 PM UTC-5, James McCoy wrote:

Why should this be different than any other open source project?  If
you want to contribute, you need to learn the tools that are being
used. When tools change, then something different needs to be learned.
It's not up to the project to accommodate every user's individual
desires.

Because so far the ONLY reason I've seen for moving to git AT ALL is "it
makes the git users happy." Why are the git users more important than
the Mercurial users?

Indeed, we haven't even seen *that* reason.  All we've seen is "it makes the vocal git users happy".  I don't know why people keep saying "the majority of vim users prefer git/github".  This has in no way been established.  The "poll" this thread created shouldn't be assumed to be a representative sample; it gets self-selected respondants, particularly of two types: people who *really* get excited about git/github, and curmudgeons who don't feel like changing without a compelling reason.  For all we know, the github-preferrers are merely a loud minority.  For all we know, the curmudgeons are a loud minority.  People need to stop taking it for granted that we know the majority of Vim users who clone repos want Vim to go to github.

-Manny

[Bruno Sutic]

> Indeed, we haven't even seen *that* reason.  All we've seen is "it makes the vocal git users happy".  I don't know why people keep saying "the majority of vim users prefer git/github".  This has in no way been established.  The "poll" this thread created shouldn't be assumed to be a representative sample; it gets self-selected respondants, particularly of two types: people who *really* get excited about git/github, and curmudgeons who don't feel like changing without a compelling reason.  For all we know, the github-preferrers are merely a loud minority.  For all we know, the curmudgeons are a loud minority.  People need to stop taking it for granted that we know the majority of Vim users who clone repos want Vim to go to github.
>
>
> -Manny

Hey guys,
I'm strongly in favor of switching to github and using git. It will bring huge benefits to the project in terms of "eyeballs" looking at the source code, reporting bugs and getting involved in smaller tasks like testing & trying out new code etc.

Here's a couple objective arguments that back these statements:
- Comparison of trends for git vs mercurial: http://www.google.com/trends/explore#q=git%2C%20mercurial&cmpt=q&tz=

- Comparison of github vs bitbucket trends: http://www.google.com/trends/explore#q=github%2C%20bitbucket&cmpt=q&tz=

- lastly, it has been mentioned a couple times vim plugin community is already on github. The objective statement that proves this: github currently has 42,636 vim related repositories, bitbucket has only 1652 (this is based on a simple search for "vim" on both github and bitbucket).

[Manuel Ortega]

The trend comparison has nothing to do with Vim users ("Vim users" is the relevant class, not "computer users" or "developers of something or other").  And the home of Vim plugins has nothing to do with anything.

-Manny

[Ben Fritz]

On Friday, March 27, 2015 at 4:06:47 PM UTC-5, Bruno Sutic wrote:
> - lastly, it has been mentioned a couple times vim plugin community is
> already on github. The objective statement that proves this: github
> currently has 42,636 vim related repositories, bitbucket has only 1652
> (this is based on a simple search for "vim" on both github and
> bitbucket).

Does this "simple search" include the automatically created mirrors that
Vundle created for each and every vim.org plugin? Authors that have no
presence on Github whatsoever nevertheless have their plugin on github
due to this.

Does it count the individual forks? How about private forks? On GitHub,
IIUC, you cannot create a private fork of a public repository. I think
this is quite possible on BitBucket. Would these show up in a search?

And I know gundo and probably a few other plugins have a github
presence...but also a BitBucket presence. Which is their "primary", if
they even have a primary, I have no idea.

Even if these numbers are accurate, your arguments basically boil down
to "Git is popular. Let's do the popular thing and move to Git."

Now that I've proven myself a curmudgeon (thanks, Manuel :-)), I present
only reason beyond current fashion trends I can think of why it makes
sense to move to git:

Bram does his own thing when you send him a patch. He has even said pull
requests will probably become patches in his new workflow. Mercurial is
designed to keep all data, always. git is designed to forget data when
it's not needed anymore. So when Bram commits a patch, you can easily
tell git to forget the changesets that led up to that patch. It's harder
with Mercurial (though not impossible, using "evolve" or "strip" or
similar).

Maybe none of this matters. Bram, have you definitely decided you're
taking Vim to GitHub? Do we all just need to shut up and accept it?

[Marshall Ward]

Bram-
Just a quick comment, followed by a maintenance question:

First:

Despite being a long time git and github user, I would still vote that you go with your personal preference by sticking with hg. I feel that much of the vim development cycle is built on your personal style of development, and keeping that going is much more important to me than a choice of VCS and web host.

Also, as a (naturalised) Aussie, I feel some obligation to root for Atlassian/bitbucket :).

But the serious question:

How will this work for syntax maintainers? In the past, we just send patches to the maintainers, who would then pass them along to you. Should we now send pull requests directly to the repo, and the maintainer can just vertify that it works?

[Bram Moolenaar]

Marshall Ward wrote:

> Bram-
> Just a quick comment, followed by a maintenance question:
>
> First:
>
> Despite being a long time git and github user, I would still vote that
> you go with your personal preference by sticking with hg. I feel that
> much of the vim development cycle is built on your personal style of
> development, and keeping that going is much more important to me than
> a choice of VCS and web host.

I won't need to learn much git, I already verified that I can modify the
scripts I use for Mercurial to work with git.

> Also, as a (naturalised) Aussie, I feel some obligation to root for
> Atlassian/bitbucket :).

Bitbucket also appears to be a nice place. I moved Zimbu there, both to
try it out and because for Zimbu I use Mercurial commands directly. It
still requires changing the location of the repository, for which I
don't think there is a command, it requires editing the hgrc file.

> But the serious question:
>
> How will this work for syntax maintainers? In the past, we just send
> patches to the maintainers, who would then pass them along to you.
> Should we now send pull requests directly to the repo, and the
> maintainer can just vertify that it works?

Nothing will change for now. Including syntax files is not much work.
Maintainers can make pull requests, but this still requires generating
an email to notify me (or someone else) and very likely results in just
getting the diff and including that. Using the merge button on Github
is not going to happen, it results in my master version going out of
sync.

--
Dreams are free, but there's a small charge for alterations.

[ZyX]

On Wednesday, March 25, 2015 at 11:48:42 PM UTC+3, Bram Moolenaar wrote:
> Christian Brabandt wrote:
>
> [...]
>
> > @Bram, perhaps it is necessary to split the runtime directory into a
> > separate
> > github repository, so they could be easier handled.
>
> How is that easier? Most users will want just one repo to pull from and
> rebuild their local Vim, possibly with some local changes.

NeoVim project tried to do this and found it non-comfortable to keep them in
sync (I mean, any contributor which needs to change both code and
documentation needs to create two separate pull requests).

Thus if runtime will be separated at least runtime/doc should be kept in main
repository. Submodules suggested later cannot solve this issue at all.

>
> If runtime file maintainers want to, they can create their own
> repository and send me the updated file once in a while.
>
> --
> A hamburger walks into a bar, and the bartender says: "I'm sorry,
> but we don't serve food here."

[Fredrik Gustafsson]

On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> NeoVim project tried to do this and found it non-comfortable to keep them in
> sync (I mean, any contributor which needs to change both code and
> documentation needs to create two separate pull requests).
>
> Thus if runtime will be separated at least runtime/doc should be kept in main
> repository. Submodules suggested later cannot solve this issue at all.

I fail to understand why submodules cannot solve this problem. Would you
care to elaborate?

--
Fredrik Gustafsson

phone: +46 733-608274
e-mail: iv...@iveqy.com
website: http://www.iveqy.com

[ZyX]

So, you are not going to receive emails from github? Github emails contains
links to the generated diffs as well, they are kept in sync with the pull
request.

Bitbucket also has this functionality (example:

curl -L https://bitbucket.org/api/2.0/repositories/vimcommunity/vim-pi/pullrequests/15/patch

), but it does not bother sending links to the generated patches.

[ZyX]

On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote:
> On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> > NeoVim project tried to do this and found it non-comfortable to keep them in
> > sync (I mean, any contributor which needs to change both code and
> > documentation needs to create two separate pull requests).
> >
> > Thus if runtime will be separated at least runtime/doc should be kept in main
> > repository. Submodules suggested later cannot solve this issue at all.
>
> I fail to understand why submodules cannot solve this problem. Would you
> care to elaborate?

Please show me an example of the PR which will update *both* the main
repository and the submodule. If this is possible then submodules can solve
this problem, but I have never seen this functionality.

[Fredrik Gustafsson]

On Sun, Mar 29, 2015 at 04:04:23AM -0700, ZyX wrote:
> On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote:
> > On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> > > NeoVim project tried to do this and found it non-comfortable to keep them in
> > > sync (I mean, any contributor which needs to change both code and
> > > documentation needs to create two separate pull requests).
> > >
> > > Thus if runtime will be separated at least runtime/doc should be kept in main
> > > repository. Submodules suggested later cannot solve this issue at all.
> >
> > I fail to understand why submodules cannot solve this problem. Would you
> > care to elaborate?
>
> Please show me an example of the PR which will update *both* the main
> repository and the submodule. If this is possible then submodules can solve
> this problem, but I have never seen this functionality.

Thanks I see your point. You first have to make a pull request to the
submodule and then a new pull request telling the parent repo to use
that new submodule commit. This can of course lead to a state where we
have dead code in the submodule. That is, code not used in the parent
repo yet because it haven't been merged but the code in the submodule
has.

That is if we don't apply commits in the same order for the submodule
and the parent.

So I see a problem in needing to do a two step pull request cycle, and a
possibility for dead code inte the submodule.

This is bad, maybe bad enough, technically it would work though. Or am I
missing some additionally pitfall?

[guyzmo]

On Sun, Mar 29, 2015 at 04:04:23AM -0700, ZyX wrote:

> On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote:
> > On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> > > NeoVim project tried to do this and found it non-comfortable to keep them in
> > > sync (I mean, any contributor which needs to change both code and
> > > documentation needs to create two separate pull requests).
> > >
> > > Thus if runtime will be separated at least runtime/doc should be kept in main
> > > repository. Submodules suggested later cannot solve this issue at all.
> > I fail to understand why submodules cannot solve this problem. Would you
> > care to elaborate?
> Please show me an example of the PR which will update *both* the main
> repository and the submodule. If this is possible then submodules can solve
> this problem, but I have never seen this functionality.

then use git subtree.

http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging
https://medium.com/@v/git-subtrees-a-tutorial-6ff568381844
http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
https://help.github.com/articles/about-git-subtree-merges/

HTH,

--
Guyzmo

[ZyX]

On Sunday, March 29, 2015 at 2:10:09 PM UTC+3, Fredrik Gustafsson wrote:
> On Sun, Mar 29, 2015 at 04:04:23AM -0700, ZyX wrote:
> > On Sunday, March 29, 2015 at 1:57:31 PM UTC+3, Fredrik Gustafsson wrote:
> > > On Sun, Mar 29, 2015 at 03:55:55AM -0700, ZyX wrote:
> > > > NeoVim project tried to do this and found it non-comfortable to keep them in
> > > > sync (I mean, any contributor which needs to change both code and
> > > > documentation needs to create two separate pull requests).
> > > >
> > > > Thus if runtime will be separated at least runtime/doc should be kept in main
> > > > repository. Submodules suggested later cannot solve this issue at all.
> > >
> > > I fail to understand why submodules cannot solve this problem. Would you
> > > care to elaborate?
> >
> > Please show me an example of the PR which will update *both* the main
> > repository and the submodule. If this is possible then submodules can solve
> > this problem, but I have never seen this functionality.
>
> Thanks I see your point. You first have to make a pull request to the
> submodule and then a new pull request telling the parent repo to use
> that new submodule commit. This can of course lead to a state where we
> have dead code in the submodule. That is, code not used in the parent
> repo yet because it haven't been merged but the code in the submodule
> has.
>
> That is if we don't apply commits in the same order for the submodule
> and the parent.
>
> So I see a problem in needing to do a two step pull request cycle, and a
> possibility for dead code inte the submodule.

This is not dead code, this is primary out-of-sync documentation (since unlike
NeoVim Vim does not have that much supporting code in runtime: NeoVim has
various providers there, Vim only things like runtime/syntax.vim).

>
> This is bad, maybe bad enough, technically it would work though. Or am I
> missing some additionally pitfall?

Double and linked PRs are the primary problem. Also note that mercurial
developers consider this a “feature of last resort”. Don’t know why exactly,
but I believe they know what they are doing.

There are another problems with submodules:

1. They are checked out in “detached HEAD” state. This means that you need to
do development in another clone or constantly do `git checkout` in
submodules (once per each `git submodule update` call).
2. Every time submodule is updated upstream must be updated as well. This means
additional work for maintainers (can be redirected to a script though).
3. If Vim will start using submodules from some commit *and* will still have
in-repository `runtime` directory in preceding commit it would be impossible
to use `git checkout` to switch to older commit.
4. Switching to some commit will now always be `git checkout` followed by
`git submodule update`.
5. You can’t merge submodule changes. For top-level repository submodule is
effectively just a binary file with SHA and if you do merging you need to be
careful regarding what the result of the merge will be and what it should be.

[ZyX]

This still has downsides comparing to single repository:

1. PRs to runtime will now be scattered between /runtime/ repository and /
repository.
2. Duplicate history entries in /runtime/ and /.
3. Requirement to do two-way synchronization between / and /runtime/.

a. Still any change to /runtime/ needs corresponding change to /.
b. Yet changes to / may need to be pushed to /runtime/.

Note that both solutions (submodules and subtrees) only make sense if

1. Bram is going to give more people RW permissions for /runtime/ repository.
2. Somebody will set up a hook which will do the synchronization.

Have not yet heard about the 1 and it is the only thing which may justify the
separation.

[Fredrik Gustafsson]

On Sun, Mar 29, 2015 at 05:15:08AM -0700, ZyX wrote:
> This is not dead code, this is primary out-of-sync documentation (since unlike
> NeoVim Vim does not have that much supporting code in runtime: NeoVim has
> various providers there, Vim only things like runtime/syntax.vim).

That would then require that not to add a submodule to the parent which
contain changes that not have their corresponding part merged into the
parent yet.

Not impossible but not very practical. I believe this is the real
dealbreaker. It all depends on how tightly coupled the runtime is with
the parent repo.

Thanks for clarifying this. Let me comment purely technical:

>
> There are another problems with submodules:
>
> 1. They are checked out in “detached HEAD” state. This means that you need to
> do development in another clone or constantly do `git checkout` in
> submodules (once per each `git submodule update` call).

You don't have to do a checkout to a branch unless you need to work on
that submodule. And I can't really see how this could be done in any
other way. Do you have a better solution than the "checkout to detached
state?"

With git there's possibilities to automatically point a submodule to a
branch today, but that's stupid because things will break.

> 2. Every time submodule is updated upstream must be updated as well. This means
> additional work for maintainers (can be redirected to a script though).

No. You don't need to update the parent just because the submodule is
updated. However if you want the parent to use the new version of the
submodule then you've to update the parent.

This a really good design if you need to work with a submodule with a
different release cycle, for example a third party library.

> 3. If Vim will start using submodules from some commit *and* will still have
> in-repository `runtime` directory in preceding commit it would be impossible
> to use `git checkout` to switch to older commit.

Yes, this is sad. Work is beeing done to remove this obstacle (and you
can checkout an older commit, but you first have to remove the directory
containing the submodule (don't worry, it will be restored when you
checkout a commit using that submodule again)).

> 4. Switching to some commit will now always be `git checkout` followed by
> `git submodule update`.

yes

> 5. You can’t merge submodule changes. For top-level repository submodule is
> effectively just a binary file with SHA and if you do merging you need to be
> careful regarding what the result of the merge will be and what it should be.

You can merge submodules, but not from the point of the parent repo
which will see the submodule as a binary file.


Let me add that I've no reason for promote vim using submodules, but I
want the discussions to be hold with the correct technical background.

[guyzmo]

On Sun, Mar 29, 2015 at 05:29:51AM -0700, ZyX wrote:
> This still has downsides comparing to single repository:
> 1. PRs to runtime will now be scattered between /runtime/ repository and / repository.
> 2. Duplicate history entries in /runtime/ and /.
> 3. Requirement to do two-way synchronization between / and /runtime/.
> a. Still any change to /runtime/ needs corresponding change to /.
> b. Yet changes to / may need to be pushed to /runtime/.

well, there's no real duplication of history, as the /runtime history
would be the branch's history, matching the other repository as remote
only.

The real downside of subtrees is that there's no way to enforce
separation of commits sent to the subtree from the main repository, it's
all up to the user, and that's a shame. Even though I believe that some
pre-push hook on the server side could forbid commits that spread to the
subtree and the main tree.

> Note that both solutions (submodules and subtrees) only make sense if
> 1. Bram is going to give more people RW permissions for /runtime/
> repository.
> 2. Somebody will set up a hook which will do the synchronization.
> Have not yet heard about the 1 and it is the only thing which may
> justify the separation.

Though I just commented on the fact that subtrees are overall more
convenient than submodules. I don't really really understand what
improvement the project would earn by splitting up vim's repository,
though I might have missed a couple of messages in the thread ;-)

-----

BTW, to change subject, I thought that in order to make the PR system
work with "traditional" email-patch vim work, a pull request webhook
could be written to send the patch file to the mailing list, with the
author in copy, as github is offering all PR as patches as well:

https://github.com/vim/vim/pull/352.patch

cf webhook documentation:

https://developer.github.com/webhooks/

Cheers,

--
GUyzmo

[Bram Moolenaar]

ZyX wrote:

[...]

> > > But the serious question:
> > >
> > > How will this work for syntax maintainers? In the past, we just send
> > > patches to the maintainers, who would then pass them along to you.
> > > Should we now send pull requests directly to the repo, and the
> > > maintainer can just vertify that it works?
> >
> > Nothing will change for now. Including syntax files is not much work.
> > Maintainers can make pull requests, but this still requires generating
> > an email to notify me (or someone else) and very likely results in just
> > getting the diff and including that. Using the merge button on Github
> > is not going to happen, it results in my master version going out of
> > sync.
>
> So, you are not going to receive emails from github? Github emails contains
> links to the generated diffs as well, they are kept in sync with the pull
> request.

We could forward both issues and pull requests to the vim-dev list.
Like we currently do for issues on code.google.com.
If this is too spammy we can disable it.

--
BRIDGEKEEPER: What is your favorite colour?
GAWAIN: Blue ... No yelloooooww!

"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Nikolay Pavlov]

2015-03-29 18:56 GMT+03:00 Bram Moolenaar <Br...@moolenaar.net>:
>
> ZyX wrote:
>
> [...]
>
>> > > But the serious question:
>> > >
>> > > How will this work for syntax maintainers? In the past, we just send
>> > > patches to the maintainers, who would then pass them along to you.
>> > > Should we now send pull requests directly to the repo, and the
>> > > maintainer can just vertify that it works?
>> >
>> > Nothing will change for now. Including syntax files is not much work.
>> > Maintainers can make pull requests, but this still requires generating
>> > an email to notify me (or someone else) and very likely results in just
>> > getting the diff and including that. Using the merge button on Github
>> > is not going to happen, it results in my master version going out of
>> > sync.
>>
>> So, you are not going to receive emails from github? Github emails contains
>> links to the generated diffs as well, they are kept in sync with the pull
>> request.
>
> We could forward both issues and pull requests to the vim-dev list.
> Like we currently do for issues on code.google.com.
> If this is too spammy we can disable it.

I am wondering whether it is possible to forward replies from vim-dev
to github (*at least* when user does “Reply to all”).

With code.google.com issue tracker it was not uncommon situation when
such forwarding resulted in discussion started in the issue tracker
continued in vim-dev list where original author does not see it.

Note that GH allows editing comments and original post itself both by
author and by people with RW access. Edits are not sent to the user
currently and I think they will neither be sent to the mailing list.
Also GH allows subscribing to the whole issue tracker. Thus *assuming
used solution is the same as the former one with Google issue tracker*
to avoid possible discussions that can be based on outdated posts and
are not seen by some of the original authors (who are not subscribed
here) it is better to either officially ban issue reports on vim-dev
or disable issue tracker.

Though I hope “reply all” reply will copy reply to GH avoiding the main problem.

[Nikolay Pavlov]

2015-03-29 15:55 GMT+03:00 Fredrik Gustafsson <iv...@iveqy.com>:
> On Sun, Mar 29, 2015 at 05:15:08AM -0700, ZyX wrote:
>> This is not dead code, this is primary out-of-sync documentation (since unlike
>> NeoVim Vim does not have that much supporting code in runtime: NeoVim has
>> various providers there, Vim only things like runtime/syntax.vim).
>
> That would then require that not to add a submodule to the parent which
> contain changes that not have their corresponding part merged into the
> parent yet.
>
> Not impossible but not very practical. I believe this is the real
> dealbreaker. It all depends on how tightly coupled the runtime is with
> the parent repo.
>
> Thanks for clarifying this. Let me comment purely technical:
>>
>> There are another problems with submodules:
>>
>> 1. They are checked out in “detached HEAD” state. This means that you need to
>> do development in another clone or constantly do `git checkout` in
>> submodules (once per each `git submodule update` call).
>
> You don't have to do a checkout to a branch unless you need to work on
> that submodule. And I can't really see how this could be done in any
> other way. Do you have a better solution than the "checkout to detached
> state?"

I am speaking exactly about doing the development which will result in
/runtime/ changes.

Note: if that was mercurial you can simply create a new branch head;
it is supposed to be merged at the time main repository is merged. Git
does not have mercurial branches so this is not an option.

>
> With git there's possibilities to automatically point a submodule to a
> branch today, but that's stupid because things will break.
>
>> 2. Every time submodule is updated upstream must be updated as well. This means
>> additional work for maintainers (can be redirected to a script though).
>
> No. You don't need to update the parent just because the submodule is
> updated. However if you want the parent to use the new version of the
> submodule then you've to update the parent.

This means losing one of the main points (/runtime/ is considered to
be updated more often then /, so some people do not want to wait until
Bram merges it in /).

>
> This a really good design if you need to work with a submodule with a
> different release cycle, for example a third party library.

Which is the job for the package manager and not submodules.
Submodules are for the case when you do development in all projects,
and such projects are both not too closely tied to keep in one
repository and not too loosely tied to make them completely separate
projects.

>
>> 3. If Vim will start using submodules from some commit *and* will still have
>> in-repository `runtime` directory in preceding commit it would be impossible
>> to use `git checkout` to switch to older commit.
>
> Yes, this is sad. Work is beeing done to remove this obstacle (and you
> can checkout an older commit, but you first have to remove the directory
> containing the submodule (don't worry, it will be restored when you
> checkout a commit using that submodule again)).

Blindly removing directory will result in possibility of losing
changes. Regular check out will fail if git is not able to merge
uncommitted changes into new revision, but this is not the case if you
remove changes yourself.

Also main point is that it would be impossible to do *with `git
checkout`* not *at all*. I have not stressed this, but this point is
actually about “using old commits will become rather inconvenient”.

>
>> 4. Switching to some commit will now always be `git checkout` followed by
>> `git submodule update`.
>
> yes
>
>> 5. You can’t merge submodule changes. For top-level repository submodule is
>> effectively just a binary file with SHA and if you do merging you need to be
>> careful regarding what the result of the merge will be and what it should be.
>
> You can merge submodules, but not from the point of the parent repo
> which will see the submodule as a binary file.

Which is what I mean about being careful. You need to merge it in the
other location *and then make sure that you pointed out the /runtime/
merge commit when merging /*. Also I smell merge conflicts out of
nothing.

>
>
> Let me add that I've no reason for promote vim using submodules, but I
> want the discussions to be hold with the correct technical background.

Note that most of the issues I am pointing out are issues because we
are discussing splitting documentation from source code. It would make
sense to move xxd to a submodule because changes to xxd which result
in changes to Vim (not to mention the opposite) are very rare and xxd
is not used without Vim (if you absolutely need exactly xxd output it
is completely possible to configure hexdump to make it; writing script
which dumps binary file out of the output is trivial).

[LCD 47]

On 29 March 2015, Nikolay Pavlov <zyx...@gmail.com> wrote:
> 2015-03-29 18:56 GMT+03:00 Bram Moolenaar <Br...@moolenaar.net>:
> >
> > ZyX wrote:
> >
> > [...]
> >
> >> > > But the serious question:
> >> > >
> >> > > How will this work for syntax maintainers? In the past, we
> >> > > just send patches to the maintainers, who would then pass them
> >> > > along to you. Should we now send pull requests directly to the
> >> > > repo, and the maintainer can just vertify that it works?
> >> >
> >> > Nothing will change for now. Including syntax files is not
> >> > much work. Maintainers can make pull requests, but this still
> >> > requires generating an email to notify me (or someone else) and
> >> > very likely results in just getting the diff and including that.
> >> > Using the merge button on Github is not going to happen, it
> >> > results in my master version going out of sync.
> >>
> >> So, you are not going to receive emails from github? Github emails
> >> contains links to the generated diffs as well, they are kept in
> >> sync with the pull request.
> >
> > We could forward both issues and pull requests to the vim-dev list.
> > Like we currently do for issues on code.google.com. If this is too
> > spammy we can disable it.
>
> I am wondering whether it is possible to forward replies from vim-dev
> to github (*at least* when user does “Reply to all”).

If you reply to the notification messages from GitHub your reply is
posted to the issue tracker.

I don't know if you need to reply from the addres you're subscribed
from for that to work though. Does the GitHub tracker accept messages
form people without a GitHub account? It probably doesn't.

> With code.google.com issue tracker it was not uncommon situation when
> such forwarding resulted in discussion started in the issue tracker
> continued in vim-dev list where original author does not see it.
>
> Note that GH allows editing comments and original post itself both by
> author and by people with RW access. Edits are not sent to the user
> currently and I think they will neither be sent to the mailing list.

Both true.

> Also GH allows subscribing to the whole issue tracker. Thus *assuming
> used solution is the same as the former one with Google issue tracker*
> to avoid possible discussions that can be based on outdated posts and
> are not seen by some of the original authors (who are not subscribed
> here) it is better to either officially ban issue reports on vim-dev
> or disable issue tracker.
>
> Though I hope “reply all” reply will copy reply to GH avoiding the
> main problem.

/lcd

[Christian Brabandt]

On Fr, 27 Mär 2015, Bram Moolenaar wrote:

> Christian Brabandt wrote:

> > On Fr, 27 Mär 2015, Ben Fritz wrote:
> >
> > > I'd just like to point out that all you githeads arguing over the
> > > various different options on pull and fetch and whether they break or
> > > keep your repository intact, are making me VERY sad about losing
> > > Mercurial.

> > >
> > > Bram, is there a chance you'd be willing to also push to a Mercurial
> > > mirror using one of the various bridge methods, either automatically
> > > via repository hook or manually when you push patches to the public
> > > repo?
> > >

> > > If so, are we definitely set on GitHub? Has anyone found a hosting
> > > site that allows you to have one landing page for both a git and a Hg
> > > repository?
> >

> > If I have understood correctly, it's easy enough to setup a mirror
> > somewhere else. If that is straightforward, I could set it up for github
> > to mirror somewhere else (bitbucket?)
> >
> > Bram, would you like to create an official vim account at bitbucket or
> > do you want me to do it?
>
> Looks like Vim on bitbucket is taken. You could ask them if they can
> make it available. Or we can use vim-mirror, to make clear it's not the
> main one. It would be great if you can set this up (less work for me
> :-).

I have setup a mercurial mirror here:
https://bitbucket.org/vim-mirror/vim
(as a bonus, this is a clone of the official google code repository, so
it contains all commits from there).

Issues are not allowed, and although I have documented in the repository
settings that this is a mirror of github, I do not see it, when visiting
the project. Oh well...

It's using a post-commit hook to follow github master branch and a
cronjob that is regularly updating the repository (several times a day
so it should be fairly accurate). Bram hasn't committed anything there
yet, so I am not sure, it is working as expected.

Let's see what happens ;)

Best,
Christian

[Ernie Rael]

It's certainly nice to change 1 line in my existing clone's hgrc and
once again have access to the latest and greatest.

(I liked that last change "ignore git files", if only it were so easy ;-)

-ernie

[LCD 47]

On 30 March 2015, Christian Brabandt <cbl...@256bit.org> wrote:
> I have setup a mercurial mirror here:
> https://bitbucket.org/vim-mirror/vim
> (as a bonus, this is a clone of the official google code repository, so
> it contains all commits from there).

[...]

Your manual commits are shown as "draft". A quick search seems to
imply this is a configuration problem:

http://stackoverflow.com/questions/20648510/draft-commits-on-mercurial/20669697#20669697

/lcd

[Christian Brabandt]

Hi LCD!

This bug report
https://bitbucket.org/site/master/issue/8678/draft-status-on-commits
indicates, this might be caused by an old installation of mercurial.
(There is no hg phases command available)

The server pushing the commits is a 12.04 Ubuntu LTS and it's mercurial
is of version 2.0.2. That seems to be a little bit outdated, a sid box
here has 3.1

We talked about upgrading the server's operating system before, but I
don't know, when this will happen. If this causes trouble, I'll have to
go through the process of updating the server, but I'd rather avoid that
for now.

Best,
Christian
--
Das Evangelium durch ein Wunder beweisen heißt etwas Widersinniges
durch etwas Naturwidriges zu beweisen.
-- Denis Diderot

[Marius Gedminas]

On Mon, Mar 30, 2015 at 07:16:40PM +0200, Christian Brabandt wrote:
> On Mo, 30 Mär 2015, LCD 47 wrote:
> > On 30 March 2015, Christian Brabandt <cbl...@256bit.org> wrote:
> > > I have setup a mercurial mirror here:
> > > https://bitbucket.org/vim-mirror/vim
> > > (as a bonus, this is a clone of the official google code repository, so
> > > it contains all commits from there).
> > [...]
> >
> > Your manual commits are shown as "draft". A quick search seems to
> > imply this is a configuration problem:
> >
> > http://stackoverflow.com/questions/20648510/draft-commits-on-mercurial/20669697#20669697
>
> This bug report
> https://bitbucket.org/site/master/issue/8678/draft-status-on-commits
> indicates, this might be caused by an old installation of mercurial.
> (There is no hg phases command available)
>
> The server pushing the commits is a 12.04 Ubuntu LTS and it's mercurial
> is of version 2.0.2. That seems to be a little bit outdated, a sid box
> here has 3.1

You can get 3.3.2 for Ubuntu 12.04 from this PPA:
https://launchpad.net/~mercurial-ppa/+archive/ubuntu/releases?field.series_filter=precise

> We talked about upgrading the server's operating system before, but I
> don't know, when this will happen. If this causes trouble, I'll have to
> go through the process of updating the server, but I'd rather avoid that
> for now.

Marius Gedminas
--
Do not meddle in the affairs of sysadmins,
they are quick to anger and have no need for subtlety.

[Markus Heidelberg]

Hi,

if switching to Git, we could seriously consider cleaning up the
repository, now it might be the last chance for quite a while.

I have collected some possibilities for improvement - some simple, some
a bit more complicated, but if found the proper commands/scripts, the
automated tasks should work without much hassle.

* Remove the three branches, they are unneeded and inconsistent. No
content will be lost by these actions.
- 'vim73' points to the 7.3 release, create the missing tag v7-3 instead
(similar to the already existing v7-0 v7-1 v7-4)
- 'vim72' points to 7.2.446
- 'vim' only contains the file README.txt, also remove the tag 'start' then

* Add missing tags
v7-0003
v7-0004
v7-0005
v7-0006
v7-0013
v7-0014
v7-0190
v7-0215
=> But the versions vefore 7.0 are strange anyway with many commits
with equal message.

v7-0-076

v7-1-083

v7-2
v7-2-054

v7-3-001
v7-3-139
v7-3-140
v7-3-141

v7-4-679

* Fix wrong tags.
- Remove the "fix" suffix, the source state in this commit fits to the
7.2.167 patch:
v7-2-167fix

- Move to the correct commit:
v7-0-225

v7-2-080
v7-2-082
v7-2-168
v7-2-176
v7-2-232

These tags were applied to the 7.3 branch instead of the 7.2 line.
v7-2-433 is the last tag before 7.3 adaptions:
v7-2-436
v7-2-437
v7-2-438
v7-2-439
v7-2-440
v7-2-441
v7-2-442
v7-2-443
v7-2-446

* Only keep 1 history root:

This command shows there are 3 roots:

$ git log --max-parents=0 --oneline
137d25c Correct Japanese menus to avoid error while loading them after 7.2.432.
7d32e70 First step in the Vim 7.3 branch. Changed version numbers.
a25c048 Initial revision

"Initial revision" is the correct root.

This command shows two merge commits. There the branches with own root
are merged into the main branch:

$ git log --merges --oneline
eb4b96f Fold Vim 7.2 default branch back to trunk to avoid two heads. (Tony Mechelynck)
f97f3c9 Merged change from default branch: Correct Japanese menus.

The trees of commits f97f3c9 and v7-2-434~2 are identical.

-> The merge commit f97f3c9 for the Japanese menu corrections could be
changed to an ordinary commit, getting rid of one false root commit
137d25c.

-> The false root commit 7d32e70, which starts the 7.2 branch, could
be avoided by branching off from commit 6fcc06c (Updated runtime
files.), which is the direct descendant of v7-2-433.

* Remove empty commits:
For each HG tag ("Added tag ... for changeset ...", adding to the
.hgtags file) there is an empty and useless commit in the git repo.


For the following actions, Bram would have to slightly adapt his
scripts/configuration to continue using the new style.
Some snippets of the update script of my old git mirror may help:
http://repo.or.cz/w/vim_mainline.git/blob/refs/heads/stuff:/update-vim.sh

* Rename tags to match the normal version notation:
s/-/./g
e.g. v7-4-683 -> v7.4.683

* Unify name and mail for author and commiter, see:
$ git shortlog --email -s

These should all be the same person for the current history.

* Replace tabs in commit messages to make "git log" indent properly.
Example with bad indentation:

updated for version 7.4.682
Problem: The search highlighting and match highlighting replaces the
cursorline highlighting, this doesn't look good.
Solution: Combine the highlighting. (Yasuhiro Matsumoto)

* Format commit messages to work properly with git commands for the log summary,
e.g. "git shortlog" or "git log --oneline". The output of these commands is ugly at the moment.

That means adding a blank line after the first line and ideally using
a descriptive one-liner for the first line. This is the format
recommended for Git repositories.

e.g. from this:
Patch 7.2.446
Problem: Crash in GUI when closing the last window in a tabpage. (ryo7000)
Solution: Remove the tabpage from the list before freeing the window.

to this (from vim_mainline.git):
[7.2.446] Crash in GUI when closing the last window in a tabpage. (ryo7000)

Problem: Crash in GUI when closing the last window in a tabpage. (ryo7000)

Solution: Remove the tabpage from the list before freeing the window.

Patch 7.2.446

There may be better conversions without duplicating the problem
description.

* Add the patch description for commits before 7.2.328
Unfortunately these commit messages do not include the patch
description, this was from the conversion to HG. Has nothing to do
with migration to Git, but maybe the effort is worth it.


Some suggestions for development beyond:

* Apply authorship information to the commit metadata.

* Rethink versioning
Currently every commit (patch) is being tagged, but these are no releases.


If interested in this cleanup, I and maybe others could assemble the
needed git and shell commands. Some of these tasks I consider as quite
obligatory.

Markus

[LCD 47]

On 1 April 2015, Markus Heidelberg <markus.h...@web.de> wrote:
> Hi,
>
> if switching to Git, we could seriously consider cleaning up the
> repository, now it might be the last chance for quite a while.
>
> I have collected some possibilities for improvement - some simple,
> some a bit more complicated, but if found the proper commands/scripts,
> the automated tasks should work without much hassle.

[...]

This is a very well thought-out list, +1.

/lcd

[Christian Brabandt]

Am 2015-04-01 01:24, schrieb Markus Heidelberg:
> If interested in this cleanup, I and maybe others could assemble the
> needed git and shell commands. Some of these tasks I consider as quite
> obligatory.

Yes please!

Best,
Christian

[Roland Eggner]

High Markus!

+1

Until now in the vim project mercurial is used just for deployment of vim
versions. The many possibilities to save workload are _not yet_ used.
Instead, a significant effort is made to separate the runtime part -- I fail to
see any benefit of this separation, I see only troubles and additional workload
caused by this separation: patches split over multiple commits, patches not
sufficient for building vim.

Thank you Markus! Based on your work, after a well thought _one-time_ effort,
we can use git as a tool, which _saves_ workload for Bram and everybody else
involved, rather than to add workload.

Most interesting: Bram gets the option to automate _completely_ the
management of the todo list by usage of git. The todo list can become
autogenerated by git, initially in part, and some day completely:
• Another git branch can correspond to every entry in the todolist, just
a useful scheme for the names of this “todo” and “work in progress” branches
is needed. If Bram prefers mails or pull requests for submitting of patches
does not matter, both ways are possible, the latter probably with less
workload for him: he could use just “git pull” or “git am”. And if the
commit author field needs adjustment because the full name of the author is
missing in the mail From: header, there is “git commit --amend”. git itself
and many other small and large software projects are managed with such
a workflow -- probably with good reasons.
• This way git can tie together reliably the names of the original patch author
and other contributors, multiple versions of patches, the changeset the
patches are based on, and an arbitrary number of comments (a git commit can
contain a message without a patch). Todo list entries can get a unique
identity -- no need any more to search them in mailboxes, no more erroneous
assignments of patches. Other contributors can test patches easier.
• When Bram decides to include a patch in the master branch, he just merges the
regarding branch, solves merge conflicts sometimes, runs “make test“
sometimes, and adds his improvements and final polish. This last step is
important for the success of vim and could become more visible (optionally
separate commits), we could learn more easily from Brams expertise.

I imagine, this can save so much workload for Bram, that the todo list can start
to shrink, rather than to grow for ever .. an exciting vision :)


--
Roland Eggner

[Ben Fritz]

I'm not sure why everyone seems to think the Vim development process is going to change drastically just because Bram is moving Vim to Github. A lot of that stuff you're daydreaming about is also possible with Mercurial, and Bram has resisted significant changes there for a long time. Although I cannot speak for Bram, if that's the reason you're all so gleeful about the move then I think you're going to be even more disappointed than those of us wishing he'd just stick with Hg.

[Christian Brabandt]

Hi Ben!

Well, depending on what will we or Bram can agree on, it's not
necessarily about cleaning up some repository metadata, so that working
with it, will be easier. (Look at the ugly commit messages from the git
log output) That might as well include a change in the commit workflow,
but only if Bram agrees that there is a problem, that he would like to
see fixed as well.

And I would certainly like to see some of the points mentioned by Markus
addressed. I also appreciate the suggestion to create a script, that can
do this cleanup mostly automatic. That could be run against the snapshot
repository@github so that we can see, that it works and what the results
would look like. (I don't feel competent enough to do that myself)

Best,
Christian
--
Stell Dir vor, es ist Krieg und der Fernseher ist kaputt.