Good morning git land!
This lovely dark 4am (see http://youtube.com/watch?v=yXi6hg90LUU) is
as good an occasion as any to offer to you the 5th issue 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 and git-fetch
git-svn
cvsps
git.git, mingw.git and 4msysgit.git closing ranks
Seems like this edition is mostly about transport... which is a good
sign. It means that the installer has no more issues and we can
concentrate on getting git on Windows to work.
git-gui and git-fetch
=====================
Some time ago, git-gui could call git-fetch to update the remotes, but
it popped up a new cmd window. This was ugly, and at some stage Shawn
Pearce, the maintainer of git-gui, changed some parts to avoid that.
Unfortunately, this broke fetching from within git-gui.
Warning: technical explanation ahead!
The problem is this: apparently there are two different kinds of
processes on Windows (actually three, but let's not make things
complicated, and for the same reason, let's not play the obvious pun
on Microsoft): graphical and console processes.
Whenever you start a console process from a graphical process, you
have to provide it with a console instance, which would be inherited
from the calling process if that were a console process, too. But in
our case, a graphical process calls a console process (this works),
which in turn calls another console process (this doesn't).
So the symptom is that git-fetch, called from git-gui, does not pop up
a cmd window, but ssh, which is called from git-fetch for ssh:// urls,
does.
I suspected a bug in Tcl/Tk, which might have been fixed in version
8.5b2, so I compiled it and tested it, but the behaviour is still the
same. At least we now have a script in our repository to conveniently
compile an...
