Good morning git land!
This silent midnight is as good an occasion as any to offer to you the 6th edition of the msysGit Herald, the not-quite-biweekly news letter to keep you informed about msysGit, the effort to bring one of the most powerful Source Code Management systems to the poor souls stuck with Windows.
These are the covered topics:
- Git Gui's fetch problems resolved
- vim colours improved
- Getting more hits via git.or.cz than Google
- Update to 1.5.4-rc0
- New naming scheme: Git and msysGit
- We busted the quota of Google Code
- msysGit-netinstall: HTTP proxy and directories containing spaces
- Next things
So this not-quite bi-weekly newsletter took a little bit longer this time. But only for the better! Seems like the installer really stabilises, as I hoped, and we really concentrated on some serious git work.
Oh, and we got mentioned on kernel trap. For those who got the impression from there that Git on Windows is not quite there yet: not only is msysGit one of its own heaviest users, it is very much at the technical front of Git: we use submodules, and we promote Git Gui heavily. So there you have it: Git on Windows is already here.
Although we call it beta. Just to cover our buttocks.
Git Gui's fetch problems resolved
We updated git to a version where git-fetch is a builtin, in the hope that the issues with fetching were resolved (for those who do not follow the Herald: when fetching within Git Gui, a window would pop up with the remote refs, instead of redirecting this output to git-fetch).
Alas, it turns out that the implementation of spawnvpe() in Windows' runtime library leaves a lot to be desired. Amongst other issues, it does not automatically attach the child process to the same console as the parent window, which gave us some grief.
Hannes Sixt finally broke down and reimplemented spawnvpe() as it should have been (but was never fixed to).
Since then, it is running like a charm. The only issue left is when you access a remote host via ssh, and have to type in a password. We have do not intercept that yet. There is a relatively low-hanging fruit waiting for somebody to harvest it.
vim colours improved
We got a bug report that the colours in vim made a user blind ;-)
While investigating, we found out that not only did we have a useless /etc/vimrc (the correct location is /share/vim/vimrc), but the code to show nice colours for a dark background was already there, only at the wrong spot.
With that fixed, our user can recover, and open his eyes again to this lovely world we live in.
Getting more hits via git.or.cz than Google
Seems that the recent linking from the Git home page really changed things in the statistics! While Google's search referalls dominated the traffic sources earlier, 30% more users find our home page via git.or.cz than via Google now, which might also mean that they are referred to the Git home page first. ;-)
We also got some attention on November 19, when KernelTrap had a story on us.
Update to 1.5.4-rc0
Since the last Herald, Hannes was very busy sending patches to Junio Hamano, the maintainer of (non-MinGW) Git, in order to bring mingw.git closer to git.git. In the midst of all those wonderful efforts, a feature freeze was declared on git.git, to stabilise for 1.5.4. Such is life ;-)
Nevertheless, a few patches made it in, and Hannes made quite a few more cleanups, such as a rework of the environment variable handling (when you setenv() on Windows, references you got earlier via getenv() are now stale), or avoiding dup()s which confused Windows -- in the commit messages, this issue is known as the "dup dance".
At the same time, Steffen Prohaska worked on bringing 4msysgit.git closer to mingw.git ;-)
The fallout of these endeavours is that we are not only much closer to mingw.git, but we are in fact pretty close to the current prerelease of Git -- 1.5.4-rc0!
Together with the usability improvements in the installer, such as installing shortcuts for all users when installing as administrator, or the integration of the release notes into the installer, I am pretty happy with the state of the project.
New naming scheme: Git and msysGit
When taking the first steps of "Git on MSys", there was only one pretty large zip file, containing the development environment to compile git, along with a checkout of mingw.git.
Since then, we decided that we wanted installers. Three of them.
The final goal is a Git installer, meant for the end user.
To attract developers to that end, we also wanted to have two installers for the development environment: a small one, containing barely enough of Git and MSys to fetch and checkout the master branch of the development environment's repository, and the master branch of our fork of mingw.git (and recently, we got another submodule for the documentation). And a big installer, which does not clone anything, but is an all-in-one package of the development environment, not even setting up git remotes -- basically the big zip we had during the first day, turned into an installer.
As I am pretty bad with British slang names, I could not think of any really good names, and we ended up with "WinGit" (from "to wing it") for the Git installer, "GitMe" for the net installer of the development environment, and "msysGit" for the full installer.
That was confusing.
Steffen pointed out that we should thrive for the crown of Git on Windows, leaving cygwin's Git behind, and therefore our Git installer should really be called "Git".
Also, since the other two installers are in fact just two different ways to obtain the development environment, they should share the same name, "msysGit", with one being the net installer and the other the full installer.
So, these are the downloads we offer: Git, msysGit-netinstall and msysGit-fullinstall.
But maybe we decide to rename the latter two to Git-Dev-netinstall and Git-Dev-full some day... we'll see.
We busted the quota of Google Code
A mere 5 months after starting the project page http://msysgit.googlecode.com/ we reached the (default) quota of 100MB. We used up about 7-9 megabytes for each release of the Git installer, and the full msysGit installer weighs in with a 14 megabytes.
When Dmitry Kakurin suggested to get some project hosting, back in July, my first address was sourceforge. However, they dragged their feet (and our project was really moving along at a breathtaking pace, back then) so we ended up using Google Code's friendly hosting service instead.
Already it became quite clear that we'd eventually need more quota, but we were being told that we would get more when we needed it. That point was reached on Friday, 14th of December, when Steffen was unable to upload the current preview due to space constraints.
When I found the right spot to ask (in case you wonder, it was not the email address firstname.lastname@example.org, as suggested by the Google Code FAQ, but the Project Hosting discussion group at http://groups.google.com/group/google-code-hosting?lnk=gschg), things went smoothly and we now have a quota of 200MB. See you in 5 months, Google ;-)
msysGit-netinstall: HTTP proxy and directories containing spaces
A long standing bug in msysGit-netinstall (then known as GitMe) was fixed quite some time ago, but I never got around to wrap up new installers: If you installed msysGit into a directory containing spaces, it would not be able to finish the installation.
Another bug(let) was that we did not have any method to specify an HTTP proxy in the net installer.
This was the reason, probably, that the net installer was substantially less popular (2817 downloads) than the full installer (4306 downloads), despite the former being featured on the main page.
With both bugs fixed in both msysGit installers -- also updated to the same state as the Git installer -- we lay the old installers, GitMe-0.4.2 and msysGit-0.6, to rest. Requiescant in pace.
The commands git-svn and git-cvsimport had to take a backseat while more visible Git issues were being taken care of. But postponed is not abandoned, so they will both see some attention again soon.
My pet project, git-cheetah, should also get integrated as a submodule of msysgit.git. It is a lightweight Explorer extension a la TortoiseCVS, and given enough people working on it, it should be able to kick rear ends pretty quickly.
Rxvt. Ah, so long ago, I abandoned hope that this would be fixed eventually (for one, git-log is not able to spawn a pager, and thus the history just whizzes by). So we use cmd instead.
It is no secret that cmd (or the console window it opens) has pretty annoying restrictions (such as no proper multi-line selections, no real resizing support, and you have to use the mouse to scroll back). But with the work we did to recompile Perl for MSys, it should become easier to tackle Rxvt. Or maybe we'll just include Xming instead, a very small and lean rootless X11 server for MinGW.