Google Code shuts down

[Bruno Sutic]

It appears google code is shutting down:
http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html

Any thoughts on where will vim source code repo be moved?
I know I'd be more than delighted if it was hosted on Github.

[ze...@tuxproject.de]

Am 2015-03-12 18:27, schrieb Bruno Sutic:

> Any thoughts on where will vim source code repo be moved?
> I know I'd be more than delighted if it was hosted on Github.

Bitbucket please. They have Mercurial.

Git sucks.

[Gary Johnson]

SourceForge has Mercurial, too, and importation tools.

Regards,
Gary

[Manuel Ortega]

On Thu, Mar 12, 2015 at 1:46 PM, Gary Johnson <gary...@spocom.com> wrote:

On 2015-03-12, zeug wrote:
> Am 2015-03-12 18:27, schrieb Bruno Sutic:
>
> >Any thoughts on where will vim source code repo be moved?
> >I know I'd be more than delighted if it was hosted on Github.
>
> Bitbucket please. They have Mercurial.

SourceForge has Mercurial, too, and importation tools.

But SourceForge has way too much down time.  (Homebrew just had to give up on them finally).  And their web interface for browsing hg repos is beyond terrible.

Vim is distributed via hg, so it should probably go to Bitbucket.

-Manny

[Guyzmo]

On Thu, Mar 12, 2015 at 10:46:03AM -0700, Gary Johnson wrote:
> On 2015-03-12, zeug wrote:
> > Am 2015-03-12 18:27, schrieb Bruno Sutic:
> >
> > >Any thoughts on where will vim source code repo be moved?
> > >I know I'd be more than delighted if it was hosted on Github.
> > Bitbucket please. They have Mercurial.

> SourceForge has Mercurial, too, and importation tools.

and insecure archive download, and I've heard of malware install as
well. SF is not quite what it used to be. And there's an "export to
github button" on google code.

> > Git sucks.

For the mercurial option, I'd be almost neutral because I find that the
differences between both tools are really minor (it's not like considering
SVN or Git :-p), they're distributed, they're branch based and they're
nice to use. And vim sources are already in mercurial, anyway ;-)

That said, I use everyday git, and once every couple of new moon
mercurial, and only for projects I do not commit to (like firefox
or pentadactyl sources).

Anyway, I'm not a committer, but I had a few times to work against the
sources, and more often compile from them, so that's my 2 cents!

--
Guyzmo

[Ben Fritz]

On Thursday, March 12, 2015 at 12:46:32 PM UTC-5, Gary Johnson wrote:
> On 2015-03-12, zeug wrote:
> > Am 2015-03-12 18:27, schrieb Bruno Sutic:
> >
> > >Any thoughts on where will vim source code repo be moved?
> > >I know I'd be more than delighted if it was hosted on Github.
> >
> > Bitbucket please. They have Mercurial.
> >
>

> SourceForge has Mercurial, too, and importation tools.
>

Some advantages I see for BitBucket:

1. Bug tracker looks nicer (though I've never used the Sourceforge bug trackers, maybe those are nice as well; anyway both look better than Google Code's)
2. You can download tags/branches of source code as a zip file, you don't necessarily even need Mercurial installed to grab source and compile
3. Not as many (or any?) ads

I plan to move my small collection of plugins (and TOhtml) over to BitBucket. Now that Google is retiring Google Code, I have some motivation to get moving on that...

[LCD 47]

There are official export tools from Google to both Bitbucket and
SourceForge:

http://code.google.com/p/support-tools/

At this point however Bitbucket looks healthier than SourceForge.

/lcd

[Taro MURAOKA]

It is not difficult to migrate/sync the repository from mercurial to git.

We (vim-jp) have been maintaining a mirror on github already.

https://github.com/vim-jp/vim

[LCD 47]

Please, don't start this again. Search the archives for the
previous Git vs. Mercurial pissing contests, and for why neither
actually matters. :)

/lcd

[Bram Moolenaar]

How about reliability? The Vim website has been down several hours in
the past weeks.

--
'I generally avoid temptation unless I can't resist it."
-- Mae West

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

[Bram Moolenaar]

Suggestions are welcome.

It's possible to use a local Mercurial repository with Github, right?
So the instructions on how to get Vim would only need to change the URL.

--
Proverb: A nightingale that forgets the lyrics is a hummingbird.

[William Binns-Smith]

Hey all, I'm a developer (and Vim addict) for Bitbucket over at Atlassian. Let me know if you need anything should you decide Bitbucket be the next home for Vim. We'd love to have you!

Will

[Bruno Sutic]

On Thursday, March 12, 2015 at 8:28:45 PM UTC+1, Bram Moolenaar wrote:
> Bruno Sutic wrote:
>
> > It appears google code is shutting down:
> > http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
> >
> > Any thoughts on where will vim source code repo be moved?
> > I know I'd be more than delighted if it was hosted on Github.
>
> Suggestions are welcome.
>
> It's possible to use a local Mercurial repository with Github, right?
> So the instructions on how to get Vim would only need to change the URL.

Github unfortunately does not have support for Mercurial repos.
However, it is possible to use Mercurial locally and push to any git repo with a tool like this: https://github.com/schacon/hg-git

But yes, I think a move to Github would mean more than just changing the URL in the instructions.
If it's any worth, I'd gladly volunteer and invest time to help with this.

Since suggestions are welcome, I'd like to propose a couple arguments for moving to github and why would that ease vim adoption and installation for new users:

- the overwhelming majority of vim plugins are hosted on github. In fact, it seems vim plugins "exist" only on vim.org and github.
- all the vim plugin managers support short name specification for github plugins. In short, it looks like the vim (plugin) community is already on github.
- google trends on git vs mercurial are pretty clear http://www.google.com/trends/explore#q=git%2C%20mercurial&cmpt=q&tz=
- google trends on github vs bitbucket are even clearer http://www.google.com/trends/explore#q=github%2C%20bitbucket&cmpt=q&tz=
- github.com gets DDOSed occasionally (which is handled really seriously). But the github pages (web-page hosting) are a separate service and are rock solid

I tried to keep to arguments as much as possible and I hope they make sense!

[Gary Johnson]

On 2015-03-12, Bram Moolenaar wrote:
> Gary Johnson wrote:
>
> > On 2015-03-12, zeug wrote:
> > > Am 2015-03-12 18:27, schrieb Bruno Sutic:
> > >
> > > >Any thoughts on where will vim source code repo be moved?
> > > >I know I'd be more than delighted if it was hosted on Github.
> > >
> > > Bitbucket please. They have Mercurial.
> > >
> > > Git sucks.
> >
> > SourceForge has Mercurial, too, and importation tools.
>
> How about reliability? The Vim website has been down several hours in
> the past weeks.

I wanted to consider all the options, but from your experience and
that of others here, it looks like SourceForge would not be a good
choice.

I prefer Mercurial over git, so I'm not wild about using GitHub, but
that's mostly a personal thing.

Regards,
Gary

[Christian Brabandt]

Hi Bram!

On Do, 12 Mär 2015, Bram Moolenaar wrote:

> Gary Johnson wrote:
>
> > On 2015-03-12, zeug wrote:
> > > Am 2015-03-12 18:27, schrieb Bruno Sutic:
> > >
> > > >Any thoughts on where will vim source code repo be moved?
> > > >I know I'd be more than delighted if it was hosted on Github.
> > >
> > > Bitbucket please. They have Mercurial.
> > >
> > > Git sucks.
> >
> > SourceForge has Mercurial, too, and importation tools.
>
> How about reliability? The Vim website has been down several hours in
> the past weeks.

No SourceForge please. That website is unusable in my opinion. github or
bitbucket would be fine for me although I have a slight preference for
github (and it seems github has more services available through its API
(e.g. travis for CI, several others...)

Best,
Christian
--
Wer mit Gott Freund sein will, muß allein bleiben oder die ganze Welt
zu seinem Freund machen.
-- Mahatma Gandhi

[Erik Falor]

My 2 cents:

I just signed up for a Bitbucket account, and all of the new-user
tutorials I'm presented with encourage me to start a git repo. In
fact, I've only seen Mercurial mentioned once so far. Is Bitbucket
leaning towards git now, or is that just my impression?

Based upon my experience with Vim plugins and plugin managers, I get
the distinct feeling that the larger proportion of plugins are hosted
in git repositories these days, specifically on GitHub. For that
matter, even the NeoVim guys are on GitHub.

A cursory search for "vim plugin" on GitHub brings up 4,620 results.
Whereas on Bitbucket I found only 230 results.

At any rate, my vote is to take this opportunity to migrate to git. I
feel that while git and Mercurial are on even footing feature-wise,
Vim is the only project I use which is hosted in a Mercurial repo, to
the point that my Mercurial skills are seriously atrophied. I'm
confident that is the experience for the majority of Vim users.

I don't have a preference between Bitbucket vs. GitHub. Both
services seem robust and healthy.

--
Erik Falor
Registered Linux User #445632 http://linuxcounter.net

[Ben Fritz]

On Thursday, March 12, 2015 at 3:27:43 PM UTC-5, ewfalor wrote:
>
> I just signed up for a Bitbucket account, and all of the new-user
> tutorials I'm presented with encourage me to start a git repo. In
> fact, I've only seen Mercurial mentioned once so far. Is Bitbucket
> leaning towards git now, or is that just my impression?
>

I don't think so. BitBucket started out as the GitHub equivalent to
Mercurial. It still supports Mercurial just fine. I think it's just that
more people these days use git, so naturally they'll write tutorials
toward that, especially for people who might not know BitBucket supports
git.

> Based upon my experience with Vim plugins and plugin managers, I get
> the distinct feeling that the larger proportion of plugins are hosted
> in git repositories these days, specifically on GitHub. For that
> matter, even the NeoVim guys are on GitHub.
>
> A cursory search for "vim plugin" on GitHub brings up 4,620 results.
> Whereas on Bitbucket I found only 230 results.
>

That's very misleading. One of the plugin managers (I forget which one)
set up a GitHub mirror of every vim.org plugin, whether the developers
wanted it or not. Many of the vim plugins on github are only there to
support automatic downloading via git in that plugin manager.

> At any rate, my vote is to take this opportunity to migrate to git.

I absolutely, unequivocally disagree. I think it would be a huge pain to
do the move but would give us very little benefit.

> I feel that while git and Mercurial are on even footing feature-wise,

Exactly. You can do pretty much anything in one, with the other. There
are even plugins for interoperability. And the repository is *already*
in Mercurial, so there is little to gain from switching.

> Vim is the only project I use which is hosted in a Mercurial repo, to
> the point that my Mercurial skills are seriously atrophied. I'm
> confident that is the experience for the majority of Vim users.
>

I don't think you can possibly speak for "the majority of Vim users"
based on the fact that you personally use Git.

And, Mercurial is a tool that makes it very hard to shoot yourself in
the foot. Git makes it very easy to lose data permanently, even when
you're doing something like a *push* which should *never* lose data in
my opinion. Mercurial also is a lot easier to pick up with fewer
concepts that need understanding. So I think people who occasionally
need to dabble in Mercurial are probably better off than people who
occasionally need to dabble in git.

> I don't have a preference between Bitbucket vs. GitHub. Both services
> seem robust and healthy.
>

So let's do BitBucket, so that we only need to change a hosting
provider, rather than needing to also change the version control system
as well. Mercurial is likewise very robust and healthy.

I seem to remember reading somewhere about a hosting provider that
provides one interface with both Git and Mercurial back-ends on the same
project...but I can't remember what that hosting provider was, or
whether they offer free hosting at all. Does anyone know what I might be
thinking about?

[Dmitriy Zaporozhets]

At least it will be great to get project to git. I really respect Mercurial but last time I used it was 4 years ago. Since all plugins are already in git - why not use this opportunity to switch to git. If done you have a choice of several good hosting solutions.

[Ernie Rael]

On 3/12/2015 12:58 PM, Bruno Sutic wrote:
> On Thursday, March 12, 2015 at 8:28:45 PM UTC+1, Bram Moolenaar wrote:
>> Suggestions are welcome.
>>
>> It's possible to use a local Mercurial repository with Github, right?
>> So the instructions on how to get Vim would only need to change the URL.
> Github unfortunately does not have support for Mercurial repos.
> However, it is possible to use Mercurial locally and push to any git repo with a tool like this: https://github.com/schacon/hg-git

I've heard that hg-git is ok for simple use, just today I saw in the
mercurial mailing list
=================
> I've been using hg-git to manage Github projects for a few years, and wish it was a "non-problem". Sample some of the 49 open issues athttps://bitbucket.org/durin42/hg-git/issues?status=new&status=open to see why it is a problem.
>
> I appreciate all of the wonderful volunteer work that's gone into hg-git, but production ready it definitely is not.
=================

[Erik Falor]

[Whoops, meant to reply to the list, too. Sorry for the spam, Ben]

On Thu, Mar 12, 2015 at 02:38:23PM -0700, Ben Fritz wrote:
> I think it's just that
> more people these days use git,

This is my point, no more, no less. I don't think that Mercurial is
technically inferior to git. It is simply less popular and therefore
less familiar to the majority of Vim tinkerers.

> > A cursory search for "vim plugin" on GitHub brings up 4,620 results.
> > Whereas on Bitbucket I found only 230 results.
> >
>
> That's very misleading. One of the plugin managers (I forget which one)
> set up a GitHub mirror of every vim.org plugin, whether the developers
> wanted it or not. Many of the vim plugins on github are only there to
> support automatic downloading via git in that plugin manager.

I wasn't aware that may a reason why so Vim plugins are better
represented on GitHub. On the other hand, this serves to reinforce my
contention that the wider community leans toward git.

> > At any rate, my vote is to take this opportunity to migrate to git.
>
> I absolutely, unequivocally disagree. I think it would be a huge pain to
> do the move but would give us very little benefit.

I'm not so sure that it would be such a pain.

As has already been pointed out in another message in this thread, the
vim-jp group already has a git mirror of the repo. And Bitbucket
themselves blogged that converting to git will take "no time".

https://blog.bitbucket.org/2011/10/05/converting-hg-repositories-to-git/

> > Vim is the only project I use which is hosted in a Mercurial repo, to
> > the point that my Mercurial skills are seriously atrophied. I'm
> > confident that is the experience for the majority of Vim users.
> >
>
> I don't think you can possibly speak for "the majority of Vim users"
> based on the fact that you personally use Git.

I'm not advocating for git because it is my personal preference. I'm
advocating for git because, aside from Vim, it is the only VCS I need
to use to participate in open-source projects.

In other words, I prefer git because it is ubiquitous, not because I
think it is better than an alternative.

From its ubiquitousness I draw my conclusion about what the majority
of Vim users encounter. I don't believe that I just happen to be the
only person in the world who has made it this far without more
encounters with Mercurial. As you said, more people these days use
git.

> And, Mercurial is a tool that makes it very hard to shoot yourself in
> the foot. Git makes it very easy to lose data permanently, even when
> you're doing something like a *push* which should *never* lose data in
> my opinion.

Having used git for a number of years, I've never found myself in that
unhappy situation. Neither do I dispute that Mercurial may be superior
to git in this regard. But this risk sounds too hypothetical to use as
a sound basis from which to reject git.

But I would be happy to revise my opinion on this point. Perhaps you
know of an example of a project which permanently lost important data
that way? The closest thing I found to what you describe is this
article:

http://www.cs.cmu.edu/~davide/howto/git_lose.html

> Mercurial also is a lot easier to pick up with fewer
> concepts that need understanding. So I think people who occasionally
> need to dabble in Mercurial are probably better off than people who
> occasionally need to dabble in git.

That may be, but my argument is that there are far more of the former
kind of people than the latter. Since they've already picked up git,
why make them pick something else up?

[Ernie Rael]

I believe ease of use is most important. Vim is currently on mercurial;
so consider those newcomers to vim source. What percentage use git, if
it's less than 50% that would suggest mercurial. And going from merc to
git is additional hassle for current vim source users; though some of
them would welcome the change and over time be less hassled.

-ernie

[Andre Sihera]

Seriously, is using that kind of flippant and arrogant remark the best
argument
you can come up with? Contempt for one of the many legions of dedicated
foreign
volunteers who keep Vim maintained and encourage its use by their local
communities
is not welcome.

***

You may not like the fact, but it is a fact: Mercurial was the system
chosen by
a *previous* generation of Vim developers. While it has served the
project well
in the past, such tools represent neither the present nor the *future*
because
newer generations simply embrace what they know and what is relevant to
their
time (like Mercurial was to the generation that chose it). Be it C#
compared to
C, the MP3 instead of the CD (or vinyl record), whatever.

In order to attract new generations of developers, and the ideas and
talent that
comes with them, we *must* move with the tools and times of those
developers.
Otherwise Vim will die along with the dedicated team of people that
currently
maintain it. More importantly, Vim won't expand in order to protect its
own future.

If Mercurial can be used reliably and, in as much as is possible,
transparently,
within local repositories while git is used as the server, that
represents the
best solution does it not? Those who prefer Mercurial can continue to
use it; new
developers who *only* know git will be attracted to us, and those in the
middle
will now have a choice whether to migrate their Mercurial skills to git
or not. A
win for most people don't you think?

Whether we like it or not, git is the present, and also the foreseeable
future.
Change, as we all know, is hard enough to embrace at the best of times.
So to not
grasp a "less painful" opportunity such as this to update our core
infrastructure
and thus attract a new generation of developers and ideas I think would
be the
equivalent of killing Vim's future before the fact.

[Andre Sihera]

On 13/03/15 04:58, Bruno Sutic wrote:
> But yes, I think a move to Github would mean more than just changing the URL in the instructions.
> If it's any worth, I'd gladly volunteer and invest time to help with this.

That's an excellent start. You may well be taken up or your offer!

Please continue to keep yourself visible on the mailing list so others
can feel safe in the knowledge that this important issue is covered.

Cheers.

[Guyzmo]

On Fri, Mar 13, 2015 at 09:53:58AM +0900, Andre Sihera wrote:
> On 13/03/15 03:41, LCD 47 wrote:
> >On 12 March 2015, Taro MURAOKA<koron....@gmail.com> wrote:
> >>> It is not difficult to migrate/sync the repository from mercurial to git.
> >>> > We (vim-jp) have been maintaining a mirror on github already.
> >>> > https://github.com/vim-jp/vim
> > Please, don't start this again. Search the archives for the
> >previous Git vs. Mercurial pissing contests, and for why neither
> >actually matters.:)

> Seriously, is using that kind of flippant and arrogant remark the best
> argument you can come up with?

it's neither flippant or arrogant, it's just referring to earlier
trolls^Wdiscussions that happened on the list that you can refer
to if you're interested in *why* mercurial is still the preference.

> You may not like the fact, but it is a fact: Mercurial was the system
> chosen by a *previous* generation of Vim developers. While it has
> served the project well in the past, such tools represent neither the
> present nor the *future* because newer generations simply embrace what
> they know and what is relevant to their time (like Mercurial was to
> the generation that chose it).

Hell… That's the most non-constructive, the most irrelevant, the most
inacurrate remark you could make. Yes, Mercurial is less popular than
git, but it's not a question of 'generation', both git and mercurial
were first released the *same* month:

https://en.wikipedia.org/wiki/Mercurial
https://en.wikipedia.org/wiki/Git_(software)

The reason git gained more popularity is mostly because the linux kernel
is using it, and because github had more traction/popularity than other
online repository service. But technically speaking, mercurial and git
are both great.

And in the end it all comes down to a question of taste.

> Be it C# compared to C, the MP3 instead of the CD (or vinyl record),
> whatever.

You're right, let's rewrite vim in C#, because C is of another
generation.

--
Guyzmo

[陈世用]

It's time to move forward. Github please!

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Charles]

I think both mercurial/git and github/bitbucket are both great options
so the problem is less technical and more preference.
I suggest to put an online vote and see which option the majority of
vim community prefer.

[Christian J. Robinson]

On Fri, 13 Mar 2015, Charles wrote:

> I think both mercurial/git and github/bitbucket are both great
> options so the problem is less technical and more preference. I
> suggest to put an online vote and see which option the majority of
> vim community prefer.

I agree with this. My preference would be bitbucket.

- Christian

--
I didn't get the documentation for the manuals.
Christian J. Robinson <hep...@gmail.com> http://christianrobinson.name/

[Navdeep Parhar]

On Thu, Mar 12, 2015 at 08:39:08PM -0600, Christian J. Robinson wrote:
> On Fri, 13 Mar 2015, Charles wrote:
>
> >I think both mercurial/git and github/bitbucket are both great options so
> >the problem is less technical and more preference. I suggest to put an
> >online vote and see which option the majority of vim community prefer.
>
> I agree with this. My preference would be bitbucket.

I would prefer bitbucket too.

The "source of truth" vim repository is in mercurial right now and
everyone here has already figured out how to use their favorite VCS with
it. So a move to bitbucket won't disrupt anyone's workflow too much.
But a move to git *will* affect those of us who have had no reason (and
don't have a desire) to learn git. Why not do the minimally disruptive
thing and move to bitbucket?

Regards,
Navdeep

[Andre Sihera]

On 13/03/15 11:36, Charles wrote:

Please, don't start this again.  Search the archives for the
>> > >previous Git vs. Mercurial pissing contests, and for why neither
>> > >actually matters.:)

>> > Seriously, is using that kind of flippant and arrogant remark the best
>> > argument you can come up with?

>>
>> it's neither flippant or arrogant, it's just referring to earlier
>> trolls^Wdiscussions that happened on the list that you can refer
>> to if you're interested in *why* mercurial is still the preference.
>>

I, and I am sure some others here, have little or no respect for
people who only believe that such language as "pissing contests"
is either constructive or appropriate. Flippant and arrogant, yes.

Do you also consider this discussion a "pissing contest"? I suppose
you also consider the opinions of contributors to this discussion
"piss"?

Incidentally, I repeat: "Mercurial was the choice for the previous
generation of Vim developers". I did *NOT* say that Mercurial was
itself an older tool than git, or any other tool. I say again that
git has advanced where Mercurial has not, and this is significant
when trying to get a new generation of developers to contribute to
this project, and is important for securing Vim's future.

What would be constructive is putting your personal opinions aside
and to consider the wider picture which includes *everybody*,
Mercurial supporter or not.

[吴祖姜]

2015-03-13 11:00 GMT+08:00 Navdeep Parhar <npa...@gmail.com>:

The "source of truth" vim repository is in mercurial right now and
everyone here has already figured out how to use their favorite VCS with
it.  So a move to bitbucket won't disrupt anyone's workflow too much.
But a move to git *will* affect those of us who have had no reason (and
don't have a desire) to learn git.  Why not do the minimally disruptive
thing and move to bitbucket?

It's not a question of VCS, It's about a better *Environment/community* for Vim's development.

I think Github is a good place.

Best Regards,
Bill

[Andre Sihera]

On 13/03/15 05:24, Christian Brabandt wrote:
> On Do, 12 Mär 2015, Bram Moolenaar wrote:
>> > Gary Johnson wrote:
>>> > > On 2015-03-12, zeug wrote:
>>>> > > > Am 2015-03-12 18:27, schrieb Bruno Sutic:
>>>>> > > > >Any thoughts on where will vim source code repo be moved?
>>>>> > > > >I know I'd be more than delighted if it was hosted on Github.
>>>> > > > Bitbucket please. They have Mercurial.
>>>> > > > Git sucks.
>>> > > SourceForge has Mercurial, too, and importation tools.
>> > How about reliability? The Vim website has been down several hours in
>> > the past weeks.
> No SourceForge please. That website is unusable in my opinion. github or

> bitbucket would be fine for me although I have a slight preference for...

A lot of people have expressed simply technical reasons for choosing a
successor to Google code. However, more than the technical reasons, the
financial stability and political strategy of the company must not be
forgotten.

I was never happy with the choice of Google code. I am deeply suspicious
of any company that professes support for any non-profit making objective
while itself being purely profit motivated. As Google so predictably
demonstrated, as soon as their financial and political incentive
disappeared from hosting free projects they just mercilessly pulled the
plug. If possible, this kind of situation should be avoided in the future.

Sourceforge
-----------

Sourceforge used to be free (in the "open source" sense") and were
completely
ad driven. However, they are now a closed platform and, more recently, were
bought by Dice Holdings (www.diceholdingsinc.com). This company's profit
motivation has *nothing* to do with software. Dice Holdings provide
recruitment information for job searching websites, several of which
they own.
Dice Holdings bought Sourceforge just as a money-motivated acquisition, and
several new measures they introduced seem to be hurting the trustworthiness
of Sourceforge as a platform. In the future they will probably dump
Sourceforge
as soon as it is not profitable, whether or not it is valuable to
developers.

Github
------

Github started off as completely self-funding. In fact, up until 2012 they
remained completely independent. However, in 2012 they received $100M of
venture capital from Andreessen Horowitz and now have a CEO and full
management team. When they inevitably go public on the stock market then it
is questionable whether they will consider "free repositories" as a viable
business model. However, as it is their main line of business they are a
safer bet than either Google was or Sourceforge is.


BitBucket
---------

BitBucket was created and is owned by Atlassian Pty, Australia. They are a
wholly employee-owned company and raise money through sales and through the
controlled employee sale of shares to venture capitalists. They has
protected their technology and ensured that they remain technology focussed.
For open source projects, this is where they are better than Github, as
their
long-term support for free projects looks more certain. Their revenue is
also
very strong and is not Venture capital dependent, which means that they can
afford to back open source projects. They support both git and Mercurial and
appear to support migration between the two.

[zixu mo]

Bram Moolenaar於 2015年3月13日星期五 UTC+8上午3時28分45秒寫道：

Please move to github , Git is better than mercurial, and github is more powerful than bitbucket

[James McCoy]

On Fri, Mar 13, 2015 at 01:31:19PM +0900, Andre Sihera wrote:
> A lot of people have expressed simply technical reasons for choosing a
> successor to Google code. However, more than the technical reasons, the
> financial stability and political strategy of the company must not be
> forgotten.

I agree with this sentiment and the bulk of your message.

> Sourceforge
> -----------
>
> Sourceforge used to be free (in the "open source" sense") and were

They returned to running open source infrastructure a few years ago when
they switched to Allura. That being said, the rest of your
categorization still stands and are reasons why I have shied away from
using Sourceforge in recent years.

I understand why people are lobbying for GitHub from the
community/network effect perspective. Aside from a significant number
of projects using GitHub, there's also a fair amount of products that
integrate with GitHub (like travis-ci.org). There are far fewer that
integrate with Bitbucket and/or mercurial.

That alone isn't much of a reason, though, if Bram isn't going to take
advantage of those integrations. It has already been shown that people
will use the tools they like and are comfortable with, regardless of
where the Vim project is hosted.

Both Bitbucket and GitHub offer significant improvements over Google
Code but only time will tell if that actually helps the community
interact with Bram and vice-versa. It doesn't matter how many bells and
whistles there are if Bram doesn't feel like they offer any benefit to
his workflow.

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

[LCD 47]

On 13 March 2015, Andre Sihera <andre....@hotmail.co.jp> wrote:
> On 13/03/15 03:41, LCD 47 wrote:
> >On 12 March 2015, Taro MURAOKA<koron....@gmail.com> wrote:
> >> It is not difficult to migrate/sync the repository from mercurial
> >> to git.
> >>
> >> We (vim-jp) have been maintaining a mirror on github already.
> >>
> >> https://github.com/vim-jp/vim
> >
> > Please, don't start this again. Search the archives for the
> >previous Git vs. Mercurial pissing contests, and for why neither
> >actually matters.:)

> Seriously, is using that kind of flippant and arrogant remark the best
> argument you can come up with? Contempt for one of the many legions of
> dedicated foreign volunteers who keep Vim maintained and encourage its
> use by their local communities is not welcome.

[...]

I'm so very sorry for misrepresenting what happened the last time
around. I really should have said something along the lines of:
"pissing contest, bike shedding, and name calling".

http://en.wiktionary.org/wiki/bikeshedding

Also, brilliant illustration of my point. For that, I thank you.

/lcd

[Taro MURAOKA]

I have a suggestion.

We should create/obtain an organization which have good simple name like "vim" on bitbucket/github, for accesibility and convenience of end-users.

[LCD 47]

On 13 March 2015, Andre Sihera <andre....@hotmail.co.jp> wrote:

> On 13/03/15 11:36, Charles wrote:
> >>>Please, don't start this again. Search the archives for the
> >>>>> > >previous Git vs. Mercurial pissing contests, and for why
> >>>>> > >neither actually matters.:)
> >>>> > Seriously, is using that kind of flippant and arrogant remark
> >>>> > the best argument you can come up with?
> >>>
> >>> it's neither flippant or arrogant, it's just referring to earlier
> >>> trolls^Wdiscussions that happened on the list that you can

> >>> refer to if you're interested in*why* mercurial is still the

> >>> preference.
> >>>
>
> I, and I am sure some others here, have little or no respect for
> people who only believe that such language as "pissing contests" is
> either constructive or appropriate. Flippant and arrogant, yes.
>
> Do you also consider this discussion a "pissing contest"? I suppose
> you also consider the opinions of contributors to this discussion
> "piss"?

Question: "Google Code is closing, where do we move Vim?"

Answer: "Lets's switch to Git, Git is better than Mercurial!
No, let's keep Mercurial, Mercurial is better than Git!"

How would you call this, constructive, effective, and to the point?

> Incidentally, I repeat: "Mercurial was the choice for the previous
> generation of Vim developers". I did *NOT* say that Mercurial was
> itself an older tool than git, or any other tool. I say again that
> git has advanced where Mercurial has not, and this is significant
> when trying to get a new generation of developers to contribute to
> this project, and is important for securing Vim's future.
>
> What would be constructive is putting your personal opinions aside
> and to consider the wider picture which includes *everybody*,
> Mercurial supporter or not.

/lcd

[Fredrik Gustafsson]

On Thu, Mar 12, 2015 at 02:38:23PM -0700, Ben Fritz wrote:

> And, Mercurial is a tool that makes it very hard to shoot yourself in
> the foot. Git makes it very easy to lose data permanently, even when
> you're doing something like a *push* which should *never* lose data in
> my opinion. Mercurial also is a lot easier to pick up with fewer
> concepts that need understanding. So I think people who occasionally
> need to dabble in Mercurial are probably better off than people who
> occasionally need to dabble in git.

I don't care about if vim uses mercurial or git, but please don't use
FUD as an argument.

It's _very hard_ to loose data with git, and you can't loose data with a
push.

What you probably mean is that a push -f would move your branch pointer,
possible to a branch that does not contain all commits. Now this is
stupid to do if it's a public branch, so hopefully this will be denied
by the server (if the server is setup correctly).

Second, if a commit become unrefered by any branch or tag, it will be
garbage collected, but first after 2 weeks.

Third, you have a list of all commits you've been on, so a it's not hard
to look up the previous branch position.


--
Fredrik Gustafsson

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

[Martin Lundberg]

I also believe GitHub is the correct decision since it's pretty much standard and is so because people love it. If the two alternatives are GitHub and BitBucket I see GitHub as an improvement and BitBucket as a continuation of what we have to today.

I've used a lot of plug-ins over the years and the only time I've ever been on BitBucket was for FuzzyFinder which is abandoned by its author.

BitBucket is a great alternative if you need private repositories for free but I guess that's not something vim is after.

[Xavier de Gaye]

On 03/12/2015 08:28 PM, Bram Moolenaar wrote:
>
> Bruno Sutic wrote:
>
>> It appears google code is shutting down:
>> http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
>>
>> Any thoughts on where will vim source code repo be moved?
>> I know I'd be more than delighted if it was hosted on Github.
>
> Suggestions are welcome.
>
> It's possible to use a local Mercurial repository with Github, right?
> So the instructions on how to get Vim would only need to change the URL.

The Python developers have also discussed recently about moving to GitHub
versus BitBucket. See this thread:
http://thread.gmane.org/gmane.comp.python.devel/150459/focus=150639

In one of the 100 mails of this thread, one of the core developers raised the
issue that GitHub might not be an ethical company due to its
<quote>allegedly toxic and bullying culture</quote>, see :
http://article.gmane.org/gmane.comp.python.devel/150484

This should also be taken into account by the Vim community.


-- Xavier

[Andre Sihera]

On 13/03/15 18:11, Xavier de Gaye wrote:
> The Python developers have also discussed recently about moving to GitHub
> versus BitBucket. See this thread:
> http://thread.gmane.org/gmane.comp.python.devel/150459/focus=150639
>
> In one of the 100 mails of this thread, one of the core developers
> raised the
> issue that GitHub might not be an ethical company due to its
> <quote>allegedly toxic and bullying culture</quote>, see :
> http://article.gmane.org/gmane.comp.python.devel/150484
>
> This should also be taken into account by the Vim community.
>

Even though I didn't say it explicitly in my analysis of the three
companies,
I implied absolutely that due to the investor pressure of the $100M
investment
Github could start prioritising their investors (and the image portrayed to
investors) over their traditional business values. A good article about the
incident in question, which happened around March 2014, is on TechCrunch:

http://techcrunch.com/2014/03/15/julie-ann-horvath-describes-sexism-and-intimidation-behind-her-github-exit/

It looks like the recent river of money into the company (with which the
girl
in question was probably hired) is already creating a "toxic culture"
and the
company hasn't even floated on the stock market yet. After they go
public, who
knows what they might do to their core services, regardless of the current
situation.

I agree that Vim, given the choice (and I believe it has a choice)
should not
indirectly support companies that put profit before the ethics of the
services
they provide.

[Bram Moolenaar]

Despite all the popularity of github, it doesn't seem to be able to do
something as simple as sending a user a message. Do I need to fork a
repostitory and send a pull request just to get someone's attention?

--
Nothing is impossible for the man who doesn't have to do it.

[Peter Aronoff]

On Friday, March 13, 2015 at 12:53PM, Bram Moolenaar wrote:
> Despite all the popularity of github, it doesn't seem to be able to do
> something as simple as sending a user a message. Do I need to fork
> a repostitory and send a pull request just to get someone's attention?

You can get users' attention by sending them messages--in a manner of
speaking. If you write a note, in a commit message or a comment on any
issue, pull request or commit comment on the website, and include a user's
name with an @ in front of it, e.g. @telemachus (my username), then that
user will see it through the web interface.

I'm not sure what the equivalent is on other code hosting sites that you're
familiar with, but if you're looking for something like a button to send
a user an email, I don't think that GitHub or Bitbucket has that.

Hope this helps, 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

[guyzmo]

On Fri, Mar 13, 2015 at 08:09:24AM -0400, Peter Aronoff wrote:
> On Friday, March 13, 2015 at 12:53PM, Bram Moolenaar wrote:
> > Despite all the popularity of github, it doesn't seem to be able to do
> > something as simple as sending a user a message. Do I need to fork
> > a repostitory and send a pull request just to get someone's attention?
> You can get users' attention by sending them messages--in a manner of
> speaking. If you write a note, in a commit message or a comment on any
> issue, pull request or commit comment on the website, and include a user's
> name with an @ in front of it, e.g. @telemachus (my username), then that
> user will see it through the web interface.

and anyway why want to send a message through the platform, whereas all
commits have emails, which makes it easy to directly contact the author
of an user. Many people contacted me that way through github, so it
should be easy enough.

BTW, to close the discussion about github vs bitbucket, why not create
both a github git repo and a bitbucket merc repo, and have a hook that
makes sure both are kept in sync? All in all the real master repo will
be wherever Bram is committing to, but the other repo could be a mirror
of that.

And for user contributions, the pull requests from git could be synced
as new branches on the merc repo on bitbucket (if that's what Bram
chooses), in a way that is convenient enough for Bram to review and
decide to merge or not.

That way, we please everyone, vim uses the two best source control
technologies, and vim does not rely on a single hosting provider for
the sources, tacking advantage of the *DISTRIBUTED* aspect of the DVCS.

My 2 cents,

--
Guyzmo

[LCD 47]

On 13 March 2015, guyzmo <guyzm...@m0g.net> wrote:
> On Fri, Mar 13, 2015 at 08:09:24AM -0400, Peter Aronoff wrote:
> > On Friday, March 13, 2015 at 12:53PM, Bram Moolenaar wrote:
> > > Despite all the popularity of github, it doesn't seem to be able
> > > to do something as simple as sending a user a message. Do I
> > > need to fork a repostitory and send a pull request just to get
> > > someone's attention?
> > You can get users' attention by sending them messages--in a manner
> > of speaking. If you write a note, in a commit message or a comment
> > on any issue, pull request or commit comment on the website, and
> > include a user's name with an @ in front of it, e.g. @telemachus (my
> > username), then that user will see it through the web interface.
>
> and anyway why want to send a message through the platform, whereas
> all commits have emails, which makes it easy to directly contact the
> author of an user. Many people contacted me that way through github,
> so it should be easy enough.

Yes, you can pretty much do everything by email, and the platform
will keep things in synch. For example, you can receive notifications
for comments to the issue tracker, answer them by email, and the answer
will be sent to the tracker. If you mention issue numbers (f.i. #1123)
or commit IDs in comments they will be automatically cross-referenced,
and if you mention an issue number in a commit ("closes #1123") the
corresponding issue will be closed automatically. You can of also run
all git operations on your machine without ever using the web platform.

Last but definitely not least: you can run automatic builds and
tests whenever you push a commit.

> BTW, to close the discussion about github vs bitbucket, why not create
> both a github git repo and a bitbucket merc repo, and have a hook that
> makes sure both are kept in sync? All in all the real master repo
> will be wherever Bram is committing to, but the other repo could be a
> mirror of that.
>
> And for user contributions, the pull requests from git could be synced
> as new branches on the merc repo on bitbucket (if that's what Bram
> chooses), in a way that is convenient enough for Bram to review and
> decide to merge or not.
>
> That way, we please everyone, vim uses the two best source control
> technologies, and vim does not rely on a single hosting provider for
> the sources, tacking advantage of the *DISTRIBUTED* aspect of the
> DVCS.
>
> My 2 cents,

+1

/lcd

[Jan Larres]

Bram Moolenaar <Br...@Moolenaar.net>:

> Despite all the popularity of github, it doesn't seem to be able to do
> something as simple as sending a user a message. Do I need to fork a
> repostitory and send a pull request just to get someone's attention?

GitHub removed the messaging functionality a few years ago as they didn't
think that having yet another inbox would be very useful. They recommend to
use email instead, and almost every account I've seen so far does have an
email address listed.

As for other ways of getting peoples' attention others have already mentioned
options like mentioning them in a commit message or comment using the @name
format.

-Jan

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

[guyzmo]

another feature that makes working with pull requests less painful, it's
that now you can get them from their own feature branche, by adding the
following to the github remote:

fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

then `git fetch` will retrieve all the pr as branches. Almost making it
feel gerrit-like.

> Last but definitely not least: you can run automatic builds and
> tests whenever you push a commit.

> > And for user contributions, the pull requests from git could be synced
> > as new branches on the merc repo on bitbucket (if that's what Bram
> > chooses), in a way that is convenient enough for Bram to review and
> > decide to merge or not.

> +1

And this is what I mean when keeping both bitbucket and github in sync,
all the PRs from github can be fetched automagically on the bitbucket
repository, and integrated to the vim workflow.

Of course, it's a very rough idea, but there's been a few people really
motivated to get vim's source on git/github, so you guys just do that?

:-)

HTH,

--
Guyzmo

[Christian Brabandt]

Hi guyzmo!

On Fr, 13 Mär 2015, guyzmo wrote:

> another feature that makes working with pull requests less painful, it's
> that now you can get them from their own feature branche, by adding the
> following to the github remote:
>
> fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
>
> then `git fetch` will retrieve all the pr as branches. Almost making it
> feel gerrit-like.

Oh that is nice.

> > Last but definitely not least: you can run automatic builds and
> > tests whenever you push a commit.
> > > And for user contributions, the pull requests from git could be synced
> > > as new branches on the merc repo on bitbucket (if that's what Bram
> > > chooses), in a way that is convenient enough for Bram to review and
> > > decide to merge or not.
> > +1
>
> And this is what I mean when keeping both bitbucket and github in sync,
> all the PRs from github can be fetched automagically on the bitbucket
> repository, and integrated to the vim workflow.

Does that also include the issue/bug tracker? Will that also be
synchronized? Or do we have to disable the bug tracker in one location
and send the people to the other?

> Of course, it's a very rough idea, but there's been a few people really
> motivated to get vim's source on git/github, so you guys just do that?

While I also think, that would be the best solution (does anybody has
the skills to setup those 2 synchronized repositories?), it basically
comes down to what makes Bram most comfortable and how he can work the
best.

All the rest is just icing on the cake that will make other interested
people easier to get involved with, but that shouldn't be the main
reason for switching.

Best,
Christian
--
Letzte Worte eines Chemikers:
"Die Säure ist absolut harmlos."

[guyzmo]

On Fri, Mar 13, 2015 at 02:18:36PM +0100, Christian Brabandt wrote:
> On Fr, 13 Mär 2015, guyzmo wrote:
>
> > another feature that makes working with pull requests less painful, it's
> > that now you can get them from their own feature branche, by adding the
> > following to the github remote:
> > fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
> >
> > then `git fetch` will retrieve all the pr as branches. Almost making it
> > feel gerrit-like.
> Oh that is nice.

Indeed! you can almost work exclusively without ever connecting to
github, or the other way around!

> > > Last but definitely not least: you can run automatic builds and
> > > tests whenever you push a commit.
> > > > And for user contributions, the pull requests from git could be synced
> > > > as new branches on the merc repo on bitbucket (if that's what Bram
> > > > chooses), in a way that is convenient enough for Bram to review and
> > > > decide to merge or not.
> > > +1
> > And this is what I mean when keeping both bitbucket and github in sync,
> > all the PRs from github can be fetched automagically on the bitbucket
> > repository, and integrated to the vim workflow.
> Does that also include the issue/bug tracker? Will that also be
> synchronized? Or do we have to disable the bug tracker in one location
> and send the people to the other?

That's what I tend to do when I got projects mirrored on several places.
But it's really a matter of what will be the most comfortable process
for committers, starting with Bram :-)

> > Of course, it's a very rough idea, but there's been a few people really
> > motivated to get vim's source on git/github, so you guys just do that?
> While I also think, that would be the best solution (does anybody has
> the skills to setup those 2 synchronized repositories?), it basically
> comes down to what makes Bram most comfortable and how he can work the
> best.

afaict, people in the mozilla team work exclusively on git, whereas the
main repository is mercurial. Though, they're 100% self-hosted. BTW, I
believe that the MoFo could provide infrastructure shelter to a project
such as Vim (even though I'm not part of it).

> All the rest is just icing on the cake that will make other interested
> people easier to get involved with, but that shouldn't be the main
> reason for switching.

indeed, and that's the whole point I'm trying to develop. Bram chooses,
and then we can "ice" around that to make it comfy for everybody.

HTH

--
Guyzmo

[h_east]

Hi Bram and List,

Any good :-)
Bram Please decide.
I continue to write a patch of Vim. Yeah!

Best regards,
Hirohito Higashi (a.k.a. h_east)

[Ben Fritz]

On Friday, March 13, 2015 at 2:57:04 AM UTC-5, Fredrik Gustafsson wrote:
> On Thu, Mar 12, 2015 at 02:38:23PM -0700, Ben Fritz wrote:
> > And, Mercurial is a tool that makes it very hard to shoot yourself in
> > the foot. Git makes it very easy to lose data permanently, even when
> > you're doing something like a *push* which should *never* lose data in
> > my opinion. Mercurial also is a lot easier to pick up with fewer
> > concepts that need understanding. So I think people who occasionally
> > need to dabble in Mercurial are probably better off than people who
> > occasionally need to dabble in git.
>
> I don't care about if vim uses mercurial or git, but please don't use
> FUD as an argument.
>
> It's _very hard_ to loose data with git, and you can't loose data with a
> push.
>
> What you probably mean is that a push -f would move your branch pointer,
> possible to a branch that does not contain all commits. Now this is
> stupid to do if it's a public branch, so hopefully this will be denied
> by the server (if the server is setup correctly).
>

Yes, that's mostly what I was referring to. While long-time git users may
find it obvious that push --force is a stupid thing to do, new git users
may not realize that. I sure would not have thought of that; I certainly
would never have thought that it could destroy commits on the public
repository.

As for the server disallowing it, consider when you are pushing to
something that might not even BE a server; perhaps it is a backup
repository, or some intermediate repository, or a repository you set up to
share your work with others, or perhaps your team just doesn't use GitHub.

I was reading an article (I can't find it now) where the author LIKES git,
and uses it more than other systems, but warned about destroying *other*
people's work by using push -f. I think these are valid things to worry
about with git; you need to LEARN to never use push -f. In Mercurial it is
very hard to remove commits by design. Git removes commits all by itself
in some situations, also by design.

I was missing a key concept, which Erik kindly provided me in his link:
git is designed to forget things that need forgetting. Mercurial is
designed to keep everything unless told to do otherwise. Coming from
Mercurial, git's behavior here seems dangerous. I'm sure that if I had
learned git first, I'd find Mercurial's behavior at least mildly annoying.

> Second, if a commit become unrefered by any branch or tag, it will be
> garbage collected, but first after 2 weeks.
>

Yes, this was another thing I was referring to. Coming from Mercurial,
that actually seems like a very big danger, because in Mercurial you can
have dangling heads all over the place and they will stay there forever
unless you intentionally delete them. I understand now that in Git,
unnamed branches are WEIRD things that rarely (if ever) get used.

I think calling this FUD is unfair; it's not FUD, it's a matter of
familiarity. If you're familiar with Git, sure, these things are
understood and probably don't ever happen. But if you only use git
occasionally, you don't know these things *can* bite you, so they probably
will sometime.

I'm not going to get into other things I like/don't like about the two
systems, because I don't want to get into a long discussion about it. I
know I'm not going to change anyone's mind who already prefers git over
Mercurial. And I now understand *why* git does these things, due to it
being designed for use on a huge, distributed project.

[Fredrik Gustafsson]

On Fri, Mar 13, 2015 at 07:43:57AM -0700, Ben Fritz wrote:
> As for the server disallowing it, consider when you are pushing to
> something that might not even BE a server; perhaps it is a backup
> repository, or some intermediate repository, or a repository you set up to
> share your work with others, or perhaps your team just doesn't use GitHub.

This has nothing to do with github. You can't push to a non-bare repo
and public bare repos you should always consider denying force-push
to.

I think you described the differences pretty well and objective(!).

Mercurial thinking that everything you ever tell it should be there
forever and git thinking that you should be able to prepare something
nice and change it until it's ready to be public, and then it should
never be changed. Two different views, and in my opinion it boils down
to that you should know your tools.

[Ben Fritz]

I read somewhat recently about Kiln, which gives one front-end that lets you use *either* Hg or git with:

http://blog.fogcreek.com/announcing-kiln-harmony-the-future-of-dvcs/

They seem to imply they may be flexible on the number of users for open-source projects (http://blog.fogcreek.com/share-your-code-with-the-world-introducing-kiln-public-repositories/) but standard pricing is 2 free users for both Kiln and their FogBugz issue tracker. Right now it's pretty much just Bram pushing code and Christian managing the bug tracker so even that might be sufficient, but obviously more supported uses is better.

How about it? Is Kiln an option in addition to GitHub/Bitbucket? Or maybe someone has seen something similar? Maybe we don't *need* to fight over Mercurial vs. Git :-)

[Павлов Николай Александрович]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On March 13, 2015 10:56:56 AM EAT, Fredrik Gustafsson <iv...@iveqy.com> wrote:
>On Thu, Mar 12, 2015 at 02:38:23PM -0700, Ben Fritz wrote:
>> And, Mercurial is a tool that makes it very hard to shoot yourself in
>> the foot. Git makes it very easy to lose data permanently, even when
>> you're doing something like a *push* which should *never* lose data
>in
>> my opinion. Mercurial also is a lot easier to pick up with fewer
>> concepts that need understanding. So I think people who occasionally
>> need to dabble in Mercurial are probably better off than people who
>> occasionally need to dabble in git.
>
>I don't care about if vim uses mercurial or git, but please don't use
>FUD as an argument.
>
>It's _very hard_ to loose data with git, and you can't loose data with
>a
>push.

... as long as you control the server.

>
>What you probably mean is that a push -f would move your branch
>pointer,
>possible to a branch that does not contain all commits. Now this is
>stupid to do if it's a public branch, so hopefully this will be denied
>by the server (if the server is setup correctly).

Github servers are not by default.

>
>Second, if a commit become unrefered by any branch or tag, it will be
>garbage collected, but first after 2 weeks.

Which is of no use if don't control the server and don't have the commits locally.

>
>Third, you have a list of all commits you've been on, so a it's not
>hard
>to look up the previous branch position.

Absolutely pointless. You can make unreachable those commits that *never* were in your repository locally.

Here is the story:

Background: most of the projects I develop on GH are developed in my fork and I run PRs to the upstream whether or not I have push access. Since I may develop more then one branch at once I aliased 'git p' to 'git push --all' (origin is my clone). This works well since nobody, but me pushes to my fork.

One project (VAM) was different: it was the first project on GH I actively participated and after gaining push access I stopped using my fork. Once I was developing my branch, rebased it on master and squashed some commits, then force-pushed. I guess you now understand the issue: of course I was using usual shortcut. And I forgot to pull prior to this. So I happened to force-push my branch *and* master, *and* I did not have commits locally that became now unreachable.

This story resolved by using commits from @MarcWeber local clone and I adjusted my development process to avoid this in the future. But there are two morals here:

1. When developing using git you need to be aware that you *can* destroy other people's work on remote repository and adjust your development process accordingly. (AFAIK GH allows you to deny non-ff pulls to certain branches. But this is not the default.)
2. You *can't* do this with mercurial.

Also note that remote history rewriting using mercurial changeset evolution looks more promising if you can tell the server that you need to pull removed changesets (they are *always* there, just not send by the server by default). Unfortunately, mercurial authors for some reason think changeset evolution replaces mq...

PS: Based on how many changes were made to git to the "core" concepts in past few years (== none AFAIR) I think that git architecture simply does not *allow* developers to do such changes like adding branches (git has bookmarks, mercurial also does, but they were *added* not too long ago) or changeset evolution, or phases.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI1BAEBCgAfBQJVAwKDGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRB2r/1b
STKPjvr7D/411ojY4KMVq7bsdb9D282Rdl4YYstG8O7bCUlSWPUzlc3DcBxnz9m0
FGuBVlaijb7LBS3/n3bMqCTz7+TliHlORharaPhprddpc9mTsZRlFf1ZoC+uwIiE
wVVS8acmNyCS7cKv5548KqT7sJ1nwxrbuPyRHter784ZAFXMtHV99RffQYeg6wMM
T8akkprA7V3hqNGyN75b8+9JICHWBjV1l1O6IQulIhYbqO/Rj4hfbO1SObPrhW66
PS4vm4+Ky2Fc4DgvEAWw4O1tsS0LdWkZoAxh2KVzU1/8AksMRrwjqmr9OAYnSSvy
DNZ4kMlcm+cWEtshiWtLKm9QRxbhng6/7tiKTY515Flwk4VwzMD0KvJ4G759Rcde
1m9sy0FOB4752gDOPMbIcT3zszrhKT9Dtec5Nk0I6VTHm6/EbsOnWrumnDuR0z+I
O4PZO9jz6XWAzKOg1Jgpp1H3KEUK8plMp2ujTLJIHvOihshH5x1MRSIzrrC01s+N
XZ5lTU0Mn+smk0G+MSJnMBkfLCvm+aMZEbjuGwxSxV8dYx/WK8RsDxjY7PFe7ydP
Eh0QLdUPa2OTcXKEkX6yF9pmD8NyEEV8MVQbXRgCvp8FKD7+W05BhLCzCBMspUws
x0uzqX11HsuRnI6MKSBEm1M+H4ltDLIkcoKAS5wSXK+PYJd0UsiOzA==
=UfGO
-----END PGP SIGNATURE-----

[Fredrik Gustafsson]

On Fri, Mar 13, 2015 at 06:30:12PM +0300, Павлов Николай Александрович wrote:
> Here is the story:

Unfortunately that's a possible story. There's many things wrong with
it. But yeah, it's a usecase that certainly can happen to a user not
familiar with git.

You can also argue that this is a feature that mercurial doesn't have,
what if your for example commit sensitive information?

> PS: Based on how many changes were made to git to the "core" concepts in past few years (== none AFAIR) I think that git architecture simply does not *allow* developers to do such changes like adding branches (git has bookmarks, mercurial also does, but they were *added* not too long ago) or changeset evolution, or phases.

This makes me a bit interested, could you elaborate on this (I've not
CC:ed the list since I believe it's off-topic).

Git has branches, what do you mean with adding branches?

What's a bookmark? I'm not familiar with git having them.

I'm not also familiar with changeset evolution nor phases. Those are not
git terms if I'm correct.

[Manuel Ortega]

There are a lot of people saying "Github is better than Bitbucket for reasons XYZ, therefore we should move to Github".

The problem is that moving to Github means Bram and the rest of us have to switch to git. The problem here is not git itself, but the switching. The path of minimum modification, and minimum risk of messing something up, is to just go to some host that supports mercurial.

The fact that someone has a Vim clone on GH already is irrelevant. Bram would still have to learn how to use git and make his rookie mistakes (which would affect all of us). Even if Bram makes no mistakes, the rest of us who barely know how to "git pull" would still have our workflows messed up, and have to make our own rookie mistakes.[1]

OTOH, all of us already know enough about Hg to get by, and the whole thing could be solved in five minutes by creating a BB (or wherever) account and then nobody has to change anything except the URL for the repo.

Inertia is, and in this case should be, very powerful; at any rate, it's powerful enough to not be overcome by the mere fact that we have to move hosts.

[1] Hg-git is too flaky to rely upon, and even when it does work, it more than doubles the size of a repo, and is really, really, really slow, and carries new dependencies (hg-git itself, dulwich) which break from time to time.

-Manny

[Martin Lundberg]

Honestly I don't see anyone successfully arguing that git or mercurial is better or worse, they are both great and you can do good and bad things in both of them. Discussing it much further will probably not be very effective.

Google themself write "To meet developers where they are, we ourselves migrated nearly a thousand of our own open source projects from Google Code to GitHub." in the post about google code closing down. http://google-opensource.blogspot.se/2015/03/farewell-to-google-code.html

To my understanding moving to BitBucket will probably be easier since they support mercurial which vim is already using so if what you want is an easy transition that should do it. However if what you want is more participation and better insight for developers no one can deny that GitHub is the better alternative.

[Mislav Marohnić]

Hi, GitHub employee here. I'm not here to talk anyone into using git over anything else, but to provide a bit of perspective as both long-time open source maintainer[1] and huge Vim fan[2].

On Friday, March 13, 2015 at 4:54:03 AM UTC-7, Bram Moolenaar wrote:
>
> Despite all the popularity of github, it doesn't seem to be able to do
> something as simple as sending a user a message. Do I need to fork a
> repostitory and send a pull request just to get someone's attention?

It's easy to get attention of any GitHub user by @-mentioning their name in any issue thread, pull request review conversation, commit message or commit comment.

I think a switch to a host such as GitHub or any alternative is a question of much more than just picking a version control systems. I agree with others on this thread that both git and hg are perfectly viable solutions, each in its own way. But project management and maintenance is much more than doing operations on the command-line.

My suggestion is that the decision about new project home for Vim should fall on Bram and few other people that are most heavily involved in maintaining the project (if there are any), based on which tool they want to look at day-to-day when they are triaging issues and reviewing code contributions & their CI status. In my experience, these are sometimes even more time-consuming tasks than actually writing the code. Therefore, feel and feature set of an online code collaboration tool is important regardless of the particular VCS that sits below it.

Our support staff spent weeks helping make the transition of the Go project to GitHub[3] flawless and with minimum disruption to their flow. If you do decide to move to GitHub, give us a heads-up and we can tweak our migration tools to your needs. Thanks!

[1]: https://github.com/mislav
[2]: http://mislav.uniqpath.com/2011/12/vim-revisited/
[3]: https://github.com/golang/go

[MURAOKA Taro]

I think it is problem that the name of "vim" is taken by someone
already on github.
https://github.com/vim

Could we request to concede that "vim" name
if we deside to move to github?

And we should ask bitbucket same thing.
https://bitbucket.org/vim

--
MURAOKA Taro <koron....@gmail.com>

[lilydjwg]

On Fri, Mar 13, 2015 at 07:43:57AM -0700, Ben Fritz wrote:

> [...]

>
> Yes, that's mostly what I was referring to. While long-time git users may
> find it obvious that push --force is a stupid thing to do, new git users
> may not realize that. I sure would not have thought of that; I certainly
> would never have thought that it could destroy commits on the public
> repository.

When I'm about to use an option called "--force", I will check the docs
to know exactly what will happen. If I don't understand that, I either
won't do it, or make a full backup before doing it.

I guess git push should better remove the short option "-f". Pacman has
removed that already :-)

PS: switching branches is slower for mercurial than git, at least with
CPython's source code.


--
Best regards,
lilydjwg

[Ernie Rael]

Git branches are more like, but not quite the same as, mercurial
bookmarks. (from what I've heard)

-ernie

[Lin Wang]

Saying that mercurial belongs to the past and is an older generation tool than git is rather ridiculous. Git is used more widely than mercurial, mainly due to Linux kernel and github. But from a technical perspective, mercurial is designed far more elegantly and much easier to use than git, without any compromise in functionality.

+1 for keeping vim on mercurial

On Fri, Mar 13, 2015 at 8:53 AM, Andre Sihera <andre....@hotmail.co.jp> wrote:

On 13/03/15 03:41, LCD 47 wrote:

On 12 March 2015, Taro MURAOKA<koron.kaoriya@gmail.com>  wrote:

>  It is not difficult to migrate/sync the repository from mercurial to git.
>  >  We (vim-jp) have been maintaining a mirror on github already.
>  >  https://github.com/vim-jp/vim

     Please, don't start this again.  Search the archives for the
previous Git vs. Mercurial pissing contests, and for why neither
actually matters.:)

     /lcd

Seriously, is using that kind of flippant and arrogant remark the best argument

you can come up with? Contempt for one of the many legions of dedicated foreign
volunteers who keep Vim maintained and encourage its use by their local communities
is not welcome.

***

You may not like the fact, but it is a fact: Mercurial was the system chosen by
a *previous* generation of Vim developers. While it has served the project well
in the past, such tools represent neither the present nor the *future* because
newer generations simply embrace what they know and what is relevant to their
time (like Mercurial was to the generation that chose it). Be it C# compared to
C, the MP3 instead of the CD (or vinyl record), whatever.

In order to attract new generations of developers, and the ideas and talent that
comes with them, we *must* move with the tools and times of those developers.
Otherwise Vim will die along with the dedicated team of people that currently
maintain it. More importantly, Vim won't expand in order to protect its own future.

If Mercurial can be used reliably and, in as much as is possible, transparently,
within local repositories while git is used as the server, that represents the
best solution does it not? Those who prefer Mercurial can continue to use it; new
developers who *only* know git will be attracted to us, and those in the middle
will now have a choice whether to migrate their Mercurial skills to git or not. A
win for most people don't you think?

Whether we like it or not, git is the present, and also the foreseeable future.
Change, as we all know, is hard enough to embrace at the best of times. So to not
grasp a "less painful" opportunity such as this to update our core infrastructure
and thus attract a new generation of developers and ideas I think would be the
equivalent of killing Vim's future before the fact.

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nikolay Pavlov]

2015-03-14 3:32 GMT+03:00 MURAOKA Taro <koron....@gmail.com>:
> I think it is problem that the name of "vim" is taken by someone
> already on github.
> https://github.com/vim
>
> Could we request to concede that "vim" name
> if we deside to move to github?

Github has a thing called “name squatting policy”
(https://help.github.com/articles/name-squatting-policy). According to
this policy you *can’t* make GitHub release *this* name for you and
you will have to talk with the user in question

>
> And we should ask bitbucket same thing.
> https://bitbucket.org/vim

, but *if* bitbucket had the same thing you probably could claim this
without talking to the user. Unfortunately this is not the case:
https://confluence.atlassian.com/pages/viewpage.action?pageId=317950343:
unlike github they are not going to check whether user has any
activity, including private activity.

I used to use GH Name Squatting Policy once to claim “powerline” user
name to create “powerline” organization, but situation was better
then: former powerline user had no visible public activity and GH team
verified it had no private activity either. Situation with GH/vim is
worse because account is active.

I would be happy to see Vim in https://bitbucket.org/vimcommunity
since it will put official status on vim-pi repositories. Doubt this
will actually happen though.

>
> 2015-03-14 8:38 GMT+09:00 Mislav Marohnić <mislav....@gmail.com>:
>> Hi, GitHub employee here. I'm not here to talk anyone into using git over anything else, but to provide a bit of perspective as both long-time open source maintainer[1] and huge Vim fan[2].
>>
>> On Friday, March 13, 2015 at 4:54:03 AM UTC-7, Bram Moolenaar wrote:
>>>
>>> Despite all the popularity of github, it doesn't seem to be able to do
>>> something as simple as sending a user a message. Do I need to fork a
>>> repostitory and send a pull request just to get someone's attention?
>>
>> It's easy to get attention of any GitHub user by @-mentioning their name in any issue thread, pull request review conversation, commit message or commit comment.
>>
>> I think a switch to a host such as GitHub or any alternative is a question of much more than just picking a version control systems. I agree with others on this thread that both git and hg are perfectly viable solutions, each in its own way. But project management and maintenance is much more than doing operations on the command-line.
>>
>> My suggestion is that the decision about new project home for Vim should fall on Bram and few other people that are most heavily involved in maintaining the project (if there are any), based on which tool they want to look at day-to-day when they are triaging issues and reviewing code contributions & their CI status. In my experience, these are sometimes even more time-consuming tasks than actually writing the code. Therefore, feel and feature set of an online code collaboration tool is important regardless of the particular VCS that sits below it.
>>
>> Our support staff spent weeks helping make the transition of the Go project to GitHub[3] flawless and with minimum disruption to their flow. If you do decide to move to GitHub, give us a heads-up and we can tweak our migration tools to your needs. Thanks!
>>
>> [1]: https://github.com/mislav
>> [2]: http://mislav.uniqpath.com/2011/12/vim-revisited/
>> [3]: https://github.com/golang/go
>
>
>
> --
> MURAOKA Taro <koron....@gmail.com>
>

> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.

[Nikolay Pavlov]

Knowing what --force does cannot protect yourself from being stupid:
check out my story few messages later. This was a bad mistake on my
side, but git allows such bad mistakes. Mercurial does not: the worst
thing you may do by pushing is creating a new head. If changeset
evolution is supported on the remote side (it is still experimental)
you could mark some changesets as obsolete on the remote, effectively
making them disappear in new pulls, but this problem is limited to
non-publishing repositories only. You also can’t mark changesets as
obsolete without actually having them in your local repository (from
where you can always restore them).

BTW, it appears that I either mistaken what mq was intended for or
they no longer consider changeset evolution *just* as mq replacement:
new documentation talks about what I thought changeset evolution
should be used for.

>
>
> --
> Best regards,
> lilydjwg

[Sergey Khorev]

> Bruno Sutic wrote:
>
> It's possible to use a local Mercurial repository with Github, right?
> So the instructions on how to get Vim would only need to change the URL.

Github unfortunately does not have support for Mercurial repos.
However, it is possible to use Mercurial locally and push to any git repo with a tool like this: https://github.com/schacon/hg-git

I would say hg-git is a bit dodgy for day to day use. I've used it to mirror a few Mercurial repos in github. Unfortunately it doesn't work 100% transparently and some stuff like tags appear as separate commits in git. Also I saw a few occurrences when hg-git refused to push changes properly so I had to fiddle with it.

[Ernie Rael]

On 3/14/2015 5:21 AM, Nikolay Pavlov wrote:
> ... BTW, it appears that I either mistaken what mq was intended for or

> they no longer consider changeset evolution *just* as mq replacement:
> new documentation talks about what I thought changeset evolution
> should be used for.

And mq is never going away. At some point it may be deprecated in favor
of changeset evolution, but it will always be there.

[Will Fiveash]

On Fri, Mar 13, 2015 at 10:08:09AM -0700, Manuel Ortega wrote:
> There are a lot of people saying "Github is better than Bitbucket for reasons XYZ, therefore we should move to Github".
>
> The problem is that moving to Github means Bram and the rest of us have to switch to git. The problem here is not git itself, but the switching. The path of minimum modification, and minimum risk of messing something up, is to just go to some host that supports mercurial.
>
> The fact that someone has a Vim clone on GH already is irrelevant. Bram would still have to learn how to use git and make his rookie mistakes (which would affect all of us). Even if Bram makes no mistakes, the rest of us who barely know how to "git pull" would still have our workflows messed up, and have to make our own rookie mistakes.[1]
>
> OTOH, all of us already know enough about Hg to get by, and the whole thing could be solved in five minutes by creating a BB (or wherever) account and then nobody has to change anything except the URL for the repo.

++. Seems to me that moving vim to another source repo host should be
done in phases. First, move the vim repo to a host that supports
Mercurial which limits the issues to those specific to the new host (say
Bitbucket). Then after things are stable and if it seems worth the
effort should vim be migrated to a different type of version control.

--
Will Fiveash
Oracle Solaris Software Engineer