The 7th number of the msysGit Herald

The 7th number of the msysGit Herald

[Johannes Schindelin]

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. 

Re: The 7th number of the msysGit Herald

[Miles Bader]

Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
writes:
> 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

The arch importer (at least) is written in Perl, is it not?

-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish are
breaking up??!  Shit, white people oughtta understand, their job is to GIVE
people the blues, not to get them!    -- George Carlin

Re: The 7th number of the msysGit Herald

[Miles Bader]

Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org>
writes:
> 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

The arch importer (at least) is written in Perl, is it not?

-Miles

-- 
What the fuck do white people have to be blue about!?  Banana Republic ran
out of Khakis?  The Espresso Machine is jammed?  Hootie and The Blowfish are
breaking up??!  Shit, white people oughtta understand, their job is to GIVE
people the blues, not to get them!    -- George Carlin

Re: The 7th number of the msysGit Herald

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 766 bytes --]

On Fri, Feb 01, 2008 at 16:53:54 +0000, Johannes Schindelin wrote:
> [...]
> 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). 
> [...]

Well, the console is /somewhat/ resizable. Dynamically, you can change the
height, but not the width. Probably because windows don't have a SIGWINCH.

However, you /can/ select what size the console will start with -- in the
properties of the .lnk you run your program with. Ie. I normally run Cygwin
sessions at 160x60, which makes it somewhat usable (of course the rectangular
selection is still extremely braindead).

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]