Remove empty Mercurial tag commits?
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 Gedminas
--
I code in vi because I don't want to learn another OS. :)
-- Robert Love
--
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
Re: Preparations for moving to github
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 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. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
Re: Preparations for moving to github
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 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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
Re: Preparations for moving to github
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). -- I wonder, do vegetarians eat fruit bats? /// Bram Moolenaar -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 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 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 -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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, 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Build Vim on Mac OS X with Privately Installed Python (src/configure.in)
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 UTC-3, Kazunobu Kuriyama
escreveu:
On Mar 26, 2015, at 1:36, Francisco Lopes
francisco.mailing.li...@oblita.com wrote:
Em segunda-feira, 23 de março de 2015 04:19:30 UTC-3, Kazunobu Kuriyama
escreveu:
Hi list,
The attached patch was written to address two issues on Vim build on Mac
OS X with privately installed Python.
(1) The current configure script uses the responses of the Python
executable AC_PATH_PROGS() finds. This doesn’t cause any problem when
you try to link Vim against the Python that came to your system together
with the OS. But when you installed another Python and try to link Vim
against it, you’ll find that the resulting Vim is always linked against
the Python framework of /usr/bin/python, not that of, e.g.,
/opt/local/bin/python, even if the configure script correctly detects
that the Python executable /opt/local/bin/python differs from the native
/usr/bin/python.
This issue is caused by forgetting to tell the linker to use an extra
linker search path which corresponds to the Python framework you want to
use.
The proposed patch addresses the issue by prepending an appropriate
linker search path if the Python executable in use doesn’t look like the
native one so that the linker will try to link vim against your favorite
Python first. The path is determined by examining the contents of
config/Makefile in the Python framework corresponding to the executable
in use.
(2) Another issue is closely related to the issue above and they surely
resemble one another. But the cause of it slightly differs from that
and thus should be handled as such.
The current configure script relies on the variables defined in Python
framework’s config/Makefile. LINKFORSHARED is one of such variables and
has a form of:
-u {symbol} {path}
When Vim is built on Mac OS X with —disable-darwin, the configure script
is to pass the value of LINKFORSHAED to the linker without referring to
a Python framework.
If {path} is relative, then it is almost certain that you’ll suffer from
a “No such file or directory” error from the linker behind the scenes.
Consequently, if LINKFORSHARED contains a relative path while the
privately installed Python is known usable, then the “sanity” test on
compile and linker flags is doomed to fail. In other words, the test
gives an unreliable result when {path} is relative.
This is what had happened to me with Python (2.7.9) that was privately
installed through MacPorts.
The proposed patch corrects the behavior of the configure script by
checking whether or not the given {path} makes sense for the linker,
and, if necessary, make and try other candidates so that the sanity test
will give a result more faithful to the state of the system.
The issue (1) may be related to Issue #315, but I don’t want to claim
that this patch solves #315, because the Mac system mentioned there
looks different from mine in subtle points. So I’m not sure if #315 is
solved with the patch.
Regards,
Kazunobu Kuriyama
Did you review information from issue 315:
https://code.google.com/p/vim/issues/detail?id=315.
I think it's quite important for solving OS X build problems, I use that
information for flipping a flag and vanish with the linker issues.
Hi,
If I understand correctly, you mean you fixed the linker issues using the
information that was given in the URL you mentioned, right?
If so, I’d be happy if you could help me understand what I’m probably
missing there.
In the URL in question:
Comment #1 says “It looks like the fix is not working anymore.”
Comment #2 saya “…(with the build patches I mention included).”
I’m no sure what “the fix” and “the build patches” are referred to,
because I can’t see any of them nor links on the same page. If you know
something about them, please let me know.
Or, more preferably, why don’t you share with the list the way you
actually used to fix the issues?
If I come to know something about them, there may be something I can do
for Issue 315.
Regards,
Kazunobu Kuriyama
The way I solve it when I have to build on OS X is just flip the test
from 2.3 to = 2.3.
It looks you are misunderstanding how shell’s IF statements work with exit
codes.
Let ${vi_cv_var_python_version} be 2.7. Since the inequality 2.7 2.3 is
false, the command line
/your/path/to/python -c “import sys; exit(${vi_cv_var_python_version} 2.3)”.
returns 0 as the exit code, which is to be evaluated *true* if it is used as
the condition of a IF statement. Yes, 0 means *true* there. They are not
typos.
So, the condition
Re: Preparations for moving to github
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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 -- 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: log messages slightly corrupted in new github repo
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 long enough to continue on to the next line has bad indentation on the second line. The commit messaget for atch 7.4.682 is a good example. I can't tell right now on my terminal, but I suspect github (or the google code exporter) is inserting a tab where there should only be spaces (or vice versa). I don't know whether anything can be done about that, but I thought I'd raise the issue here. It looks like the git log command itself is to blame. It inserts four spaces before every line, which means Tabs are misaligned. The 7.4.682 message looks OK on github, e.g. here: https://github.com/vim/vim/commit/6ac42ad71294c4ef6d74e99668e88911e76d818f Although in some other places the indent is removed completely. -- ARTHUR: What does it say? BROTHER MAYNARD: It reads ... Here may be found the last words of Joseph of Aramathea. He who is valorous and pure of heart may find the Holy Grail in the arrggghhh... ARTHUR: What? BROTHER MAYNARD: The Arrggghhh... Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Patch] Build Vim on Mac OS X with Privately Installed Python (src/configure.in)
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 01:44:37 UTC-3, Francisco Lopes
escreveu:
Em quinta-feira, 26 de março de 2015 00:10:51 UTC-3, Kazunobu Kuriyama
escreveu:
On Mar 26, 2015, at 1:36, Francisco Lopes
francisco.mailing.li...@oblita.com wrote:
Em segunda-feira, 23 de março de 2015 04:19:30 UTC-3, Kazunobu Kuriyama
escreveu:
Hi list,
The attached patch was written to address two issues on Vim build on
Mac OS X with privately installed Python.
(1) The current configure script uses the responses of the Python
executable AC_PATH_PROGS() finds. This doesn’t cause any problem when
you try to link Vim against the Python that came to your system
together with the OS. But when you installed another Python and try
to link Vim against it, you’ll find that the resulting Vim is always
linked against the Python framework of /usr/bin/python, not that of,
e.g., /opt/local/bin/python, even if the configure script correctly
detects that the Python executable /opt/local/bin/python differs from
the native /usr/bin/python.
This issue is caused by forgetting to tell the linker to use an extra
linker search path which corresponds to the Python framework you want
to use.
The proposed patch addresses the issue by prepending an appropriate
linker search path if the Python executable in use doesn’t look like
the native one so that the linker will try to link vim against your
favorite Python first. The path is determined by examining the
contents of config/Makefile in the Python framework corresponding to
the executable in use.
(2) Another issue is closely related to the issue above and they
surely resemble one another. But the cause of it slightly differs
from that and thus should be handled as such.
The current configure script relies on the variables defined in Python
framework’s config/Makefile. LINKFORSHARED is one of such variables
and has a form of:
-u {symbol} {path}
When Vim is built on Mac OS X with —disable-darwin, the configure
script is to pass the value of LINKFORSHAED to the linker without
referring to a Python framework.
If {path} is relative, then it is almost certain that you’ll suffer
from a “No such file or directory” error from the linker behind the
scenes. Consequently, if LINKFORSHARED contains a relative path while
the privately installed Python is known usable, then the “sanity” test
on compile and linker flags is doomed to fail. In other words, the
test gives an unreliable result when {path} is relative.
This is what had happened to me with Python (2.7.9) that was privately
installed through MacPorts.
The proposed patch corrects the behavior of the configure script by
checking whether or not the given {path} makes sense for the linker,
and, if necessary, make and try other candidates so that the sanity
test will give a result more faithful to the state of the system.
The issue (1) may be related to Issue #315, but I don’t want to claim
that this patch solves #315, because the Mac system mentioned there
looks different from mine in subtle points. So I’m not sure if #315 is
solved with the patch.
Regards,
Kazunobu Kuriyama
Did you review information from issue 315:
https://code.google.com/p/vim/issues/detail?id=315.
I think it's quite important for solving OS X build problems, I use
that information for flipping a flag and vanish with the linker issues.
Hi,
If I understand correctly, you mean you fixed the linker issues using
the information that was given in the URL you mentioned, right?
If so, I’d be happy if you could help me understand what I’m probably
missing there.
In the URL in question:
Comment #1 says “It looks like the fix is not working anymore.”
Comment #2 saya “…(with the build patches I mention included).”
I’m no sure what “the fix” and “the build patches” are referred to,
because I can’t see any of them nor links on the same page. If you know
something about them, please let me know.
Or, more preferably, why don’t you share with the list the way you
actually used to fix the issues?
If I come to know something about them, there may be something I can do
for Issue 315.
Regards,
Kazunobu Kuriyama
The way I solve it when I have to build on OS X is just flip the test
from 2.3 to = 2.3.
It looks you are misunderstanding how shell’s IF statements work with exit
codes.
Let ${vi_cv_var_python_version} be 2.7. Since the inequality 2.7 2.3 is
false, the command line
/your/path/to/python -c “import sys;
Re: Preparations for moving to github
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? -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Bug with renderoptions
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 -- F: Was ist weiß und stört beim Essen? A: Eine Lawine. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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. 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 :-). -- ARTHUR: But if he was dying, he wouldn't bother to carve Arrggghhh. 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 /// Bram Moolenaar -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 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. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Fix javascript syntax highlight
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 also my first contribution so I wasn't aware of the proper channels for this type of problem. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Fix javascript syntax highlight
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. Runtime usually have maintainers (I have CC'ed the javascript maintainer now) that take care of their files. If a problem occurs, it is usually best to contact them so they can acknowledge and fix the problem (and possibly also appreciate a patch) and then they send the complete file to Bram for distribution with Vim. That means Bram doesn't have to care for each and every single runtime file and makes it easier for him. Anyways, it is usually best to contact the maintainer and only if you don't hear back from them, write here. But we appreciate any contribution, thanks! @Claudio, could you please take a look at the problem and the proposed patch? Thanks! Best, Christian -- Hallo Kurvenblinker! -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: expand(%) and utf-8 characters in directory names
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, when in that directory, expand(%) shows /home/cec/joee9 instead of the desired /home/cec/josé . Do I need to program around this or is this problem a bug with expand()? I don't see this problem. What is 'encoding' set to? enc is utf-8. By bisection of my .vimrc, I find that the following is enough in a .vimrc to cause the e9 to appear instead of é set nocp filetype plugin on set enc=utf-8 In what filetype did you execute the expand() call? The filetype: netrw Try having a directory called josé with a file therein called one. vim -u (whatever you called the vimrc above) :echo expand(%:p) You'll see something like /home/cec/jose9/one With this, there's no filetype involved. Regards, Chip Campbell -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Fix javascript syntax highlight
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 proper channels for this type of problem. Sorry, if I sounded like scaring you away. Runtime usually have maintainers (I have CC'ed the javascript maintainer now) that take care of their files. If a problem occurs, it is usually best to contact them so they can acknowledge and fix the problem (and possibly also appreciate a patch) and then they send the complete file to Bram for distribution with Vim. That means Bram doesn't have to care for each and every single runtime file and makes it easier for him. Anyways, it is usually best to contact the maintainer and only if you don't hear back from them, write here. But we appreciate any contribution, thanks! @Claudio, could you please take a look at the problem and the proposed patch? Thanks! Best, Christian -- Hallo Kurvenblinker! Thanks for the information and for forwarding the problem to the proper place. Hope this will make it in a future patch. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: To keep good projects on github
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 require write access permission. So, currently only one Bram, you can do it. Yasuhiro Matsumoto (mattn) wrote replys for those PR, however it have limited effects. This kind of works are not worth for using Bram's time, I think. So, I suggest to mandate it with write permission. # of course, if we keep using github. ;) 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 Christian, we'll discuss who else. One thing I'm struggling with is granularity of permissions. Looks like when giving write access the user can write to everything. E.g., how do I add a user (or team) who can only change Issues? -- Veni, Vidi, VW -- I came, I saw, I drove around in a little car. /// Bram Moolenaar -- b...@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/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 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? Best, Christian -- -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] Fix javascript syntax highlight
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. I then searched for a patch to this problem and found the opposite. Back in 2012 there was one patch claming to do Multi-line string syntax highlighting for Vim when in fact it broke it. I reverted the change and it works. 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[PATCH] Fix javascript syntax highlight
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 opposite. Back in 2012 there was one patch claming to do Multi-line string syntax highlighting for Vim when in fact it broke it. I reverted the change and it works. diff -r 1f42458bf2e7 runtime/syntax/javascript.vim --- a/runtime/syntax/javascript.vimWed Mar 25 20:24:04 2015 +0100 +++ b/runtime/syntax/javascript.vimFri Mar 27 15:45:41 2015 + @@ -40,8 +40,8 @@ syn match javaScriptCommentSkip ^[ \t]*\*\($\|[ \t]\+\) syn region javaScriptComment start=/\* end=\*/ contains=@Spell,javaScriptCommentTodo syn match javaScriptSpecial \\\d\d\d\|\\. -syn region javaScriptStringD start=++ skip=+\|\\+ end=+\|$+contains=javaScriptSpecial,@htmlPreproc -syn region javaScriptStringS start=+'+ skip=+\|\\'+ end=+'\|$+contains=javaScriptSpecial,@htmlPreproc +syn region javaScriptStringD start=++ skip=+\|\\\|\\\n+ end=+\|$+contains=javaScriptSpecial,@htmlPreproc +syn region javaScriptStringS start=+'+ skip=+\|\\'\|\\\n+ end=+'\|$+contains=javaScriptSpecial,@htmlPreproc syn match javaScriptSpecialCharacter '\\.' syn match javaScriptNumber -\=\\d\+L\=\\|0[xX][0-9a-fA-F]\+\ -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: expand(%) and utf-8 characters in directory names
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 /home/cec/josé . Do I need to program around this or is this problem a bug with expand()? I don't see this problem. What is 'encoding' set to? enc is utf-8. By bisection of my .vimrc, I find that the following is enough in a .vimrc to cause the e9 to appear instead of é set nocp filetype plugin on set enc=utf-8 Regards, Chip -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: expand(%) and utf-8 characters in directory names
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, expand(%) shows /home/cec/joee9 instead of the desired /home/cec/josé . Do I need to program around this or is this problem a bug with expand()? I don't see this problem. What is 'encoding' set to? enc is utf-8. By bisection of my .vimrc, I find that the following is enough in a .vimrc to cause the e9 to appear instead of é set nocp filetype plugin on set enc=utf-8 In what filetype did you execute the expand() call? Best, Christian -- Ich brenne - sagte die Lampe. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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. On Friday, March 27, 2015 at 12:00:05 PM UTC-7, 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? 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. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 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. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 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. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: log messages slightly corrupted in new github repo
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 github repo. For example, a line starting with Problem: that has a description long enough to continue on to the next line has bad indentation on the second line. The commit messaget for atch 7.4.682 is a good example. I can't tell right now on my terminal, but I suspect github (or the google code exporter) is inserting a tab where there should only be spaces (or vice versa). I don't know whether anything can be done about that, but I thought I'd raise the issue here. It looks like the git log command itself is to blame. It inserts four spaces before every line, which means Tabs are misaligned. The 7.4.682 message looks OK on github, e.g. here: https://github.com/vim/vim/commit/6ac42ad71294c4ef6d74e99668e88911e76d818f Although in some other places the indent is removed completely. I'll look into whether there is a flag for `git log` that can control this. Yay, git :( -Manny -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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? -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: log messages slightly corrupted in new github repo
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 github repo. For example, a line starting with Problem: that has a description long enough to continue on to the next line has bad indentation on the second line. The commit messaget for atch 7.4.682 is a good example. I can't tell right now on my terminal, but I suspect github (or the google code exporter) is inserting a tab where there should only be spaces (or vice versa). I don't know whether anything can be done about that, but I thought I'd raise the issue here. It looks like the git log command itself is to blame. It inserts four spaces before every line, which means Tabs are misaligned. The 7.4.682 message looks OK on github, e.g. here: https://github.com/vim/vim/commit/6ac42ad71294c4ef6d74e99668e88911e76d818f Although in some other places the indent is removed completely. Bram, I think I have solved this. `git log` takes (of course) lots of optional flags to modify the output. If you append the following to the .git/config file, then just doing `git log` results in a log that corrects the indentation problem. [format] pretty = %C(yellow)commit %H%Creset%nAuthor: %an%nDate: %cd%n%n%B When I do this, it matches what `git log` would show by default except that it corrects the indentation problem by NOT inserting spaces, and making the commit message body flush left. This actually makes the output slightly closer to the `hg log` output. -Manny -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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%20mercurialcmpt=qtz= - Comparison of github vs bitbucket trends: http://www.google.com/trends/explore#q=github%2C%20bitbucketcmpt=qtz= - 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). -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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? -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Preparations for moving to github
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. 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%20mercurialcmpt=qtz= - Comparison of github vs bitbucket trends: http://www.google.com/trends/explore#q=github%2C%20bitbucketcmpt=qtz= - 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). 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: To keep good projects on github
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 Christian, we'll discuss who else. One thing I'm struggling with is granularity of permissions. Looks like when giving write access the user can write to everything. E.g., how do I add a user (or team) who can only change Issues? AFAIK github requires write access for this purpose. So I have wrote reliable users. It means highly reliable. However, github have audit page for organization. It is enough to monitor some bad actions, and then try to recover it. Best -- MURAOKA Taro koron.kaor...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
