{"thread":{"id":"11814","subject":"The 7th number of the msysGit Herald","startedAt":"2008-02-01T16:53:54Z","lastAt":"2008-02-08T20:44:24Z","messageCount":4,"participants":["Johannes Schindelin","Miles Bader","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"67036","messageId":"alpine.LSU.1.00.0802011653180.7372@racer.site","threadId":"11814","inReplyTo":null,"subject":"The 7th number of the msysGit Herald","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","sentAt":"2008-02-01T16:53:54Z","receivedAt":"2008-02-01T16:53:54Z","isPatch":false,"sender":{"key":"johannes.schindelin-mmb7mzphnfy@public.gmane.org","avatar":null},"body":"\nGood morning git land!\n\nThis miserable, rainy Friday afternoon is as good an occasion as any \nto offer to you the 7th number of the msysGit Herald, the \nnot-quite-biweekly news letter to keep you informed about msysGit, the \neffort to bring one of the most powerful Source Code Management \nsystems to the poor souls stuck with Windows. \n\nThese are the covered topics:\n\n\tUpdated previews of Git\n\n\tWe managed to get git-svn to run!\n\n\tThe branch \"msys\"\n\n\tBuilding rxvt from scratch\n\n\tSome activity in git-cheetah\n\n\n\nHappy new year! \n\nThe \"bi-week\" grew into 5.5 weeks this time, but for two good reasons: \nChristmas and git-svn. The former does not need an explanation, the \nlatter will be covered in this issue in depth. \n\n\nUpdated previews of Git\n=======================\n\nSince the last msysGit Herald, there have been three updates to the \npreview of the Git installer. Remember, msysGit is a two-fold project: \nit aims to provide a complete development environment on Windows to \nbuild Git (with a no-hassle installer), and it aims to provide an \ninstaller for Git itself. \n\nThe Git installer comes with pretty complete release notes (if you \nhave not read them yet, you should do that sometime; they contain \nvaluable information), and Sebastian Schuberth fixed some glitches \nwith the uninstalling process. \n\nAs we realised that we install more than we support, a few programs \nhave been removed from the Git installer, notably the p4, arch, cvs \nand svn importers/exporters. At the moment, there are no plans to \nsupport Python in the MSys environment, so I am doubtful about the \nfirst two, but the latter two will most likely be supported later this \nyear (see also the next story). \n\nSince our release meister, Steffen Prohaska, is really busy as a bee, \nthe previews feature pretty current Git versions: the current \ninstaller includes 1.5.4-rc5. \n\nWhile the updates for the Git installer are frequent, the updates to \nthe msysGit installer (the development environment) are not: the \nrecommended way is the netinstaller, which comes with a minimal set of \nprograms needed to clone the repositories from repo.or.cz and \ngit.kernel.org. Obviously, the netinstaller does not need frequent \nupdates to stay current... \n\n\nWe managed to get git-svn to run!\n=================================\n\nHooray! Thanks to the hard work of Simon Sasburg, Christian Stimming \nand Mike Pape, we have gotten git-svn to run on Windows. Well, \"run\" \nmight not be the appropriate term, this being Windows, but at least it \ndoes what it is supposed to do, if only slowly... \n\nTime for a little history. \n\nLate in September, Simon Sasburg took upon the task to finally get \nperl compiling in msysGit, since we had a perl version that did not \nsupport dynamically loadable modules. For git-svn, however, we need \nsubversion's perl bindings, and you can only build them as dynamically \nloadable modules. \n\nIn October, Simon got to build a new perl, and by November, things \nwere fleshed out enough that the new perl could dynamically load \nmodules. \n\nAll the while we were working on making the process of building perl \nas automated as possible. The goal was to have a branch in \nmsysgit.git, which when checked out would provide all the MSys \ncomponents needed to build perl, and a script which would download, \nconfigure, build and install perl. \n\nThen for some time, almost nothing happened. \n\nI upgraded the script to build perl 5.8.8, since subversion did not \nlike the older version 5.6.1. There was some progress to the point \nthat subversion built, but the perl modules would not. Or they would, \nbut then perl just crashed after loading them. \n\nThen all of a sudden Christian Stimming (of git-gui and gitk i18n \nfame) came along, and identified a lot of my mistakes, building \nworking shared libraries. Mike Pape joined the fray, and together they \nhammered out the last missing pieces. \n\nAnd now we have a working version of git-svn. And that long-standing \nissue 42 is closed. And nobody will ever suggest again to install \nMIME::Base64 to fix git-svn ;-) \n\n\nThe branch \"msys\"\n=================\n\nWhile working on perl, and subversion's perl modules, it became \napparent that we would need to separate those efforts from the main \npurpose of our project, compiling git. While git is a proper MinGW \nprogram (at least the parts compiled from C source), Perl can and must \nnot be a MinGW program: it has to know about the MSys environment to \npick up the root/home directory, the mount points, etc. \n\nSo we created a branch in msysgit.git, which was meant to compile MSys \nprograms only. It provides the necessary MSys components and sets \nMSYSTEM=MSYS in /etc/profile to trigger the MSys environment instead \nof MinGW32. Our first target was perl, of course, but as we went, we \naccumulated a few more. It is to be expected that we will have to \n(re-)compile more MSys programs, and therefore we moved the branch \n\"work/msysperl\" to the full-status branch \"msys\". \n\nJust a reminder: we decided for msysgit.git that branches in the \nwork/* namespace are subject to rebasing (or deletion), branches in \n/* should not be touched by anyone else but the owner, and \ntop-level branches are _never_ to be rebased, and additionally, they \nshould be only updated with at least one Ack by another team member. \n\nConventions like this are necessary in a small project like \nmsysgit.git, which cannot draw from a huge pool of enthusiastic coders \nlike git.git. Instead, we have a small team, and everybody can push \ninto the same public repository. \n\n\nBuilding rxvt from scratch\n==========================\n\nAh, my pet peeve. Rxvt would be so nice to have, instead of that \nconsole window Windows provides, which is not even resizable (makes \nyou wonder which meaning of \"console\" the inventors meant). \n\nAlas, now as we have an \"msys\" branch, it was easy enough to include a \nscript to download, configure, build & install rxvt -- very much like \nthe script we created for perl. \n\nThis should give a good starting point to work on rxvt's issues, and \nhopefully we will be able to let the user choose between two fully \nfunctional console windows, one for those who like to select \nrectangular portions of the text window, and one for those who like \nRxvt. \n\nOne issue -- the one that prevents me from using rxvt in my msysGit \nwork -- is that \"git log\" will spawn the pager, alright, but it does \nnot stop after a screenfull of output. Instead, the complete history \nwhizzes by. \n\nThe reason may be exactly the same that was described in the 6th \nHerald, in the story \"Git Gui's fetch problems resolved\". \n\nThe problem I am referring to is that on Windows, you have a \ndistinction between console processes and GUI processes. Each console \nprocess interfaces with one console instance. If a GUI process spawns \na console process, it seems that it gives that console process a \ncertain console instance. But when that process spawns another console \nprocess, the console instance is not inherited, but a new one created \ninstead. \n\nSo it may be a problem in the use of spawn() (or fork()) in rxvt, \nwhich does not attach stdin/stdout properly to the console instance of \nthe parent process. \n\n\nSome activity in git-cheetah\n============================\n\nFor a while, it seemed as git-cheetah -- a TortoiseCVS lookalike for \ngit -- would stall, but out of nowhere appeared Kirill (I do not know \nhis surname either) with a few patches to cheetah. \n\nA big problem of git-cheetah was that the guy who started it (yours \ntruly) had no idea about working with COM objects. And as soon as I \nlearnt about COM, I started to hate it. \n\nSo my plan was to prove that you could wrap those ugly interfaces with \na lean, elegant C interface and never look back at COM. \n\nAlmost the same happened for other aspects of providing a \"shell \nextension\" (as Microsoft calls the modules to enhance its \nExplorer.exe). For example, there is a function in each .dll that will \nbe executed when the .dll is loaded into memory. Not only that: in our \ncase, you need to put some code there, as certain module-specific \nvalues are not stored anywhere, but only passed to that function! \n\nNeedless to say that I was glad when other people arrived to my \nrescue. Brian Hetro took the ball for a while, Simon suggested a few \nthings, and now it seems that Kirill will finally get it somewhere. \n\nTo make git-cheetah even more visible, it will soon become a submodule \n(that you do not need to check out, if you do not want to) of \nmsysgit.git. \n"},{"id":"67330","messageId":"buo7ihl88eo.fsf__29070.5887171955$1202111706$gmane$org@dhapc248.dev.necel.com","threadId":"11814","inReplyTo":"alpine.LSU.1.00.0802011653180.7372@racer.site","subject":"Re: The 7th number of the msysGit Herald","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-02-04T07:53:19Z","receivedAt":"2008-02-04T07:53:19Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"\n\nJohannes Schindelin \nwrites:\n> As we realised that we install more than we support, a few programs \n> have been removed from the Git installer, notably the p4, arch, cvs \n> and svn importers/exporters. At the moment, there are no plans to \n> support Python in the MSys environment, so I am doubtful about the \n> first two, but the latter two will most likely be supported later this \n> year\n\nThe arch importer (at least) is written in Perl, is it not?\n\n-Miles\n\n-- \nWhat the fuck do white people have to be blue about!? Banana Republic ran\nout of Khakis? The Espresso Machine is jammed? Hootie and The Blowfish are\nbreaking up??! Shit, white people oughtta understand, their job is to GIVE\npeople the blues, not to get them! -- George Carlin\n"},{"id":"299223","messageId":"buo7ihl88eo.fsf@dhapc248.dev.necel.com","threadId":"11814","inReplyTo":"alpine.LSU.1.00.0802011653180.7372@racer.site","subject":"Re: The 7th number of the msysGit Herald","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-02-04T07:53:19Z","receivedAt":"2008-02-04T07:53:19Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"\n\nJohannes Schindelin \nwrites:\n> As we realised that we install more than we support, a few programs \n> have been removed from the Git installer, notably the p4, arch, cvs \n> and svn importers/exporters. At the moment, there are no plans to \n> support Python in the MSys environment, so I am doubtful about the \n> first two, but the latter two will most likely be supported later this \n> year\n\nThe arch importer (at least) is written in Perl, is it not?\n\n-Miles\n\n-- \nWhat the fuck do white people have to be blue about!? Banana Republic ran\nout of Khakis? The Espresso Machine is jammed? Hootie and The Blowfish are\nbreaking up??! Shit, white people oughtta understand, their job is to GIVE\npeople the blues, not to get them! -- George Carlin\n\n"},{"id":"67999","messageId":"20080208204424.GA17147@efreet.light.src","threadId":"11814","inReplyTo":"alpine.LSU.1.00.0802011653180.7372@racer.site","subject":"Re: The 7th number of the msysGit Herald","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-02-08T20:44:24Z","receivedAt":"2008-02-08T20:44:24Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Fri, Feb 01, 2008 at 16:53:54 +0000, Johannes Schindelin wrote:\n> [...]\n> Ah, my pet peeve. Rxvt would be so nice to have, instead of that \n> console window Windows provides, which is not even resizable (makes \n> you wonder which meaning of \"console\" the inventors meant). \n> [...]\n\nWell, the console is /somewhat/ resizable. Dynamically, you can change the\nheight, but not the width. Probably because windows don't have a SIGWINCH.\n\nHowever, you /can/ select what size the console will start with -- in the\nproperties of the .lnk you run your program with. Ie. I normally run Cygwin\nsessions at 160x60, which makes it somewhat usable (of course the rectangular\nselection is still extremely braindead).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"}]}