MSysGit:MSysGitHerald7

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated. Please visit git-scm.com/doc for up-to-date documentation.

Good morning git land!

This miserable, rainy Friday afternoon is as good an occasion as any to offer to you the 7th number 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:

• Updated previews of Git

• We managed to get git-svn to run!

• The branch "msys"

• Building rxvt from scratch

• Some activity in git-cheetah

Happy new year!

The "bi-week" grew into 5.5 weeks this time, but for two good reasons: Christmas and git-svn. The former does not need an explanation, the latter will be covered in this issue in depth.

Updated previews of Git

Since the last msysGit Herald, there have been three updates to the preview of the Git installer. Remember, msysGit is a two-fold project: it aims to provide a complete development environment on Windows to build Git (with a no-hassle installer), and it aims to provide an installer for Git itself.

The Git installer comes with pretty complete release notes (if you have not read them yet, you should do that sometime; they contain valuable information), and Sebastian Schuberth fixed some glitches with the uninstalling process.

As we realised that we install more than we support, a few programs have been removed from the Git installer, notably the p4, arch, cvs and svn importers/exporters. At the moment, there are no plans to support Python in the MSys environment, so I am doubtful about the first two, but the latter two will most likely be supported later this year (see also the next story).

Since our release meister, Steffen Prohaska, is really busy as a bee, the previews feature pretty current Git versions: the current installer includes 1.5.4-rc5.

While the updates for the Git installer are frequent, the updates to the msysGit installer (the development environment) are not: the recommended way is the netinstaller, which comes with a minimal set of programs needed to clone the repositories from repo.or.cz and git.kernel.org. Obviously, the netinstaller does not need frequent updates to stay current...

We managed to get git-svn to run!

Hooray! Thanks to the hard work of Simon Sasburg, Christian Stimming and Mike Pape, we have gotten git-svn to run on Windows. Well, "run" might not be the appropriate term, this being Windows, but at least it does what it is supposed to do, if only slowly...

Time for a little history.

Late in September, Simon Sasburg took upon the task to finally get perl compiling in msysGit, since we had a perl version that did not support dynamically loadable modules. For git-svn, however, we need subversion's perl bindings, and you can only build them as dynamically loadable modules.

In October, Simon got to build a new perl, and by November, things were fleshed out enough that the new perl could dynamically load modules.

All the while we were working on making the process of building perl as automated as possible. The goal was to have a branch in msysgit.git, which when checked out would provide all the MSys components needed to build perl, and a script which would download, configure, build and install perl.

Then for some time, almost nothing happened.

I upgraded the script to build perl 5.8.8, since subversion did not like the older version 5.6.1. There was some progress to the point that subversion built, but the perl modules would not. Or they would, but then perl just crashed after loading them.

Then all of a sudden Christian Stimming (of git-gui and gitk i18n fame) came along, and identified a lot of my mistakes, building working shared libraries. Mike Pape joined the fray, and together they hammered out the last missing pieces.

And now we have a working version of git-svn. And that long-standing issue 42 is closed. And nobody will ever suggest again to install MIME::Base64 to fix git-svn ;-)

The branch "msys"

While working on perl, and subversion's perl modules, it became apparent that we would need to separate those efforts from the main purpose of our project, compiling git. While git is a proper MinGW program (at least the parts compiled from C source), Perl can and must not be a MinGW program: it has to know about the MSys environment to pick up the root/home directory, the mount points, etc.

So we created a branch in msysgit.git, which was meant to compile MSys programs only. It provides the necessary MSys components and sets MSYSTEM=MSYS in /etc/profile to trigger the MSys environment instead of MinGW32. Our first target was perl, of course, but as we went, we accumulated a few more. It is to be expected that we will have to (re-)compile more MSys programs, and therefore we moved the branch "work/msysperl" to the full-status branch "msys".

Just a reminder: we decided for msysgit.git that branches in the work/* namespace are subject to rebasing (or deletion), branches in <name>/* should not be touched by anyone else but the owner, and top-level branches are never to be rebased, and additionally, they should be only updated with at least one Ack by another team member.

Conventions like this are necessary in a small project like msysgit.git, which cannot draw from a huge pool of enthusiastic coders like git.git. Instead, we have a small team, and everybody can push into the same public repository.

Building rxvt from scratch

Ah, my pet peeve. Rxvt would be so nice to have, instead of that console window Windows provides, which is not even resizable (makes you wonder which meaning of "console" the inventors meant).

Alas, now as we have an "msys" branch, it was easy enough to include a script to download, configure, build & install rxvt -- very much like the script we created for perl.

This should give a good starting point to work on rxvt's issues, and hopefully we will be able to let the user choose between two fully functional console windows, one for those who like to select rectangular portions of the text window, and one for those who like Rxvt.

One issue -- the one that prevents me from using rxvt in my msysGit work -- is that "git log" will spawn the pager, alright, but it does not stop after a screenfull of output. Instead, the complete history whizzes by.

The reason may be exactly the same that was described in the 6th Herald, in the story "Git Gui's fetch problems resolved".

The problem I am referring to is that on Windows, you have a distinction between console processes and GUI processes. Each console process interfaces with one console instance. If a GUI process spawns a console process, it seems that it gives that console process a certain console instance. But when that process spawns another console process, the console instance is not inherited, but a new one created instead.

So it may be a problem in the use of spawn() (or fork()) in rxvt, which does not attach stdin/stdout properly to the console instance of the parent process.

Some activity in git-cheetah

For a while, it seemed as git-cheetah -- a TortoiseCVS lookalike for git -- would stall, but out of nowhere appeared Kirill (I do not know his surname either) with a few patches to cheetah.

A big problem of git-cheetah was that the guy who started it (yours truly) had no idea about working with COM objects. And as soon as I learnt about COM, I started to hate it.

So my plan was to prove that you could wrap those ugly interfaces with a lean, elegant C interface and never look back at COM.

Almost the same happened for other aspects of providing a "shell extension" (as Microsoft calls the modules to enhance its Explorer.exe). For example, there is a function in each .dll that will be executed when the .dll is loaded into memory. Not only that: in our case, you need to put some code there, as certain module-specific values are not stored anywhere, but only passed to that function!

Needless to say that I was glad when other people arrived to my rescue. Brian Hetro took the ball for a while, Simon suggested a few things, and now it seems that Kirill will finally get it somewhere.

To make git-cheetah even more visible, it will soon become a submodule (that you do not need to check out, if you do not want to) of msysgit.git.