The current Git conversion has a lot of empty commits like
https://github.com/vim/vim/commit/e675d947a7ec993176262a888bfde5702427056d
Are they of any use to anyone? Can they be stripped away when doing the
final conversion ('git filter-branch --prune-empty' might be helpful
here)?
Marius
On Fri, Mar 27, 2015 at 04:42:31PM +1300, Jan Larres wrote:
James McCoy james...@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
On Thu, Mar 26, 2015 at 8:48 PM, Manuel Ortega mannyvim...@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
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
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).
Marius Gedminas wrote:
On Fri, Mar 27, 2015 at 04:42:31PM +1300, Jan Larres wrote:
James McCoy james...@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
On Fri, Mar 27, 2015 at 9:13 AM, Peter Aronoff telemac...@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,
On Mar 27, 2015, at 13:53, Francisco Lopes francisco.mailing.li...@oblita.com
wrote:
Em sexta-feira, 27 de março de 2015 01:51:05 UTC-3, Francisco Lopes escreveu:
Em sexta-feira, 27 de março de 2015 01:44:37 UTC-3, Francisco Lopes
escreveu:
Em quinta-feira, 26 de março de 2015 00:10:51
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
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
Manuel Ortega wrote:
I cloned the new testing repo from github.
When I do git log and scroll through the results, I find that multi-line
log messages that look fine in the hg repo are a bit mangled in the github
repo.
For example, a line starting with Problem: that has a description
Em sexta-feira, 27 de março de 2015 10:52:22 UTC-3, Kazunobu Kuriyama escreveu:
On Mar 27, 2015, at 13:53, Francisco Lopes
francisco.mailing.li...@oblita.com wrote:
Em sexta-feira, 27 de março de 2015 01:51:05 UTC-3, Francisco Lopes
escreveu:
Em sexta-feira, 27 de março de 2015
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
Hi zeug!
On Do, 26 Mär 2015, z...@tuxproject.de wrote:
Hmm, it should; still, as I only replaced one image file, I wonder
which one is responsible for the windowbar itself...?
Actually, I was wrong. This worked. It justed didn't look different
enough, that I didn't notice.
Best,
Christian
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
Christian Brabandt wrote:
Hi Ben!
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.
On Fri, Mar 27, 2015 at 12:18 PM, Bram Moolenaar b...@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
Have you contacted the javascript syntax maintainer?
Best,
Christian
--
Der einzige Unterschied zwischen dem Heiligen und dem Sünder ist, daß
jeder Heilige eine Vergangenheit und jeder Sünder eine Zukunft hat.
-- Oscar Wilde
I simply saw a problem and fixed it, it was
Hi José!
On Fr, 27 Mär 2015, José Monteiro wrote:
Have you contacted the javascript syntax maintainer?
I simply saw a problem and fixed it, it was also my first contribution
so I wasn't aware of the proper channels for this type of problem.
Sorry, if I sounded like scaring you away.
Christian Brabandt wrote:
Hi Charles!
On Fr, 27 Mär 2015, Charles Campbell wrote:
Bram Moolenaar wrote:
Charles Campbell wrote:
I tried a directory named josé and found that netrw wasn't handling it
well. One of the reasons is expand(%), which is used to get the full
path. However,
sexta-feira, 27 de Março de 2015 às 17:02:22 UTC, Christian Brabandt escreveu:
Hi José!
On Fr, 27 Mär 2015, José Monteiro wrote:
Have you contacted the javascript syntax maintainer?
I simply saw a problem and fixed it, it was also my first contribution
so I wasn't aware of the
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
Taro Muraoka wrote:
I suggest to give write access permission of vim organization to
some reliable users.
It is important to act for PR on github.
PR becomes a cause of flaming sometimes.
So we need to close, lock, or delete PR which have seed of troubles.
But this kind of operations
Hi Ben!
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
Hi José!
On Fr, 27 Mär 2015, José Monteiro wrote:
Hi,
I was coding in javascript and noticed that in the following example:
0 | var str = this is a \
1 | long string;
line 1 is highlighted as normal code, when in javascript the '\' allows the
interperter to ignore the end of line.
Hi,
I was coding in javascript and noticed that in the following example:
0 | var str = this is a \
1 | long string;
line 1 is highlighted as normal code, when in javascript the '\' allows the
interperter to ignore the end of line.
I then searched for a patch to this problem and found the
Bram Moolenaar wrote:
Charles Campbell wrote:
I tried a directory named josé and found that netrw wasn't handling it
well. One of the reasons is expand(%), which is used to get the full
path. However, when in that directory, expand(%) shows
/home/cec/joee9 instead of the desired
Hi Charles!
On Fr, 27 Mär 2015, Charles Campbell wrote:
Bram Moolenaar wrote:
Charles Campbell wrote:
I tried a directory named josé and found that netrw wasn't handling it
well. One of the reasons is expand(%), which is used to get the full
path. However, when in that directory,
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
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
On Mar 27, 2015 1:32 PM, Benjamin Fritz fritzophre...@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
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
On Fri, Mar 27, 2015 at 10:16 AM, Bram Moolenaar b...@moolenaar.net wrote:
Manuel Ortega wrote:
I cloned the new testing repo from github.
When I do git log and scroll through the results, I find that
multi-line
log messages that look fine in the hg repo are a bit mangled in the
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,
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
On Fri, Mar 27, 2015 at 10:16 AM, Bram Moolenaar b...@moolenaar.net wrote:
Manuel Ortega wrote:
I cloned the new testing repo from github.
When I do git log and scroll through the results, I find that
multi-line
log messages that look fine in the hg repo are a bit mangled in the
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
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
On Fri, Mar 27, 2015 at 5:06 PM, Bruno Sutic bruno.su...@gmail.com wrote:
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.
2015-03-28 2:18 GMT+09:00 Bram Moolenaar b...@moolenaar.net:
Yes, I hope several people can help out making Vim on Github work well.
With a bit of luck I only have to take care of patches and push to the
repository. Others can look into issues, pull requests, etc.
I have already added
40 matches
Mail list logo
