{"thread":{"id":"9217","subject":"Windows support","startedAt":"2007-07-25T10:35:26Z","lastAt":"2007-08-02T10:45:50Z","messageCount":69,"participants":["Dmitry Kakurin","Johannes Schindelin","Steven Grimm","Nguyen Thai Ngoc Duy","Steffen Prohaska","Stephen Cuppett","Daniel Barkalow","Russ Dill","Linus Torvalds","Medve Emilian-EMMEDVE1","Wincent Colaiuta","Junio C Hamano","Shawn O. Pearce","Han-Wen Nienhuys","Henning Rogge","Noel Grandin","Julian Phillips","Andy Parkins","Robin Rosenberg","Marius Storm-Olsen","Johannes Sixt","Christian MICHON","David Kastrup","Jakub Narebski","Asger Ottar Alstrup"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48552","messageId":"a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com","threadId":"9217","inReplyTo":null,"subject":"Windows support","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-07-25T10:35:26Z","receivedAt":"2007-07-25T10:35:26Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"How serious are you guys about Windows support?\nI'm talking fully-functional port, not Cygwin.\nI did a lot of searching for a new SCM to switch to (from Perforce).\nAnd Git is my #1 choice. I love it's internals design and it's\nexpressive power. I've also tested git-p4 and it has worked like a\ncharm with my depot (with few tweaks that I may contribute later).\nBut I do all my work on Windows so I need Git-For-Windows-Done-Right :-).\nThe current mingw port is not there yet.\n\nTransition to the new SCM must happen now, so basically I have 2 choices:\n1. Survive for a few months with the current CygWin port of Git\nknowing that Windows support is coming\n2. Use another SCM (#2 is Mercurial, #3 is Monotone)\n\nI'd realy love to do #1, but I need to know how long do I have to wait.\n\n- Dmitry\n"},{"id":"48553","messageId":"Pine.LNX.4.64.0707251139580.14781@racer.site","threadId":"9217","inReplyTo":"a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-25T10:40:36Z","receivedAt":"2007-07-25T10:40:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Dmitry Kakurin wrote:\n\n> How serious are you guys about Windows support?\n\nOkay, let's talk business:\n\n> I'd realy love to do #1, but I need to know how long do I have to wait.\n\nPay me decently, and you will have to wait for a few weeks.\n\nCiao,\nDscho\n"},{"id":"48555","messageId":"46A73015.7020306@midwinter.com","threadId":"9217","inReplyTo":"a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com","subject":"Re: Windows support","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-07-25T11:12:21Z","receivedAt":"2007-07-25T11:12:21Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Dmitry Kakurin wrote:\n> How serious are you guys about Windows support?\n\nWell, it's really a matter of someone stepping up and doing the work. \nMuch (nearly all?) of the core git team never touches Windows, so they \nboth have no selfish motivation to get it working well and no way to \ntest their changes even if they decide to take it up for the greater good.\n\nAs has been pointed out, there are a lot of people coming to the list \nand asking for Windows support, but precious few actually contributing \nany code. If everyone who asked for Windows support had been willing to \nfix one Windows-related issue, git's Windows support would be stellar by \nnow. I'm as guilty as anyone of asking for stuff without doing it \nmyself, so I say this as an observation, not an accusation!\n\n> I'm talking fully-functional port, not Cygwin.\n\nThere is a port that uses MinGW instead of Cygwin, FYI. It is still \nperhaps not as native-Windows-like as one might prefer, but it should be \nless alien than Cygwin, anyway.\n\n-Steve\n"},{"id":"48556","messageId":"46A73071.3000101@midwinter.com","threadId":"9217","inReplyTo":"a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com","subject":"Re: Windows support","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-07-25T11:13:53Z","receivedAt":"2007-07-25T11:13:53Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Dmitry Kakurin wrote:\n> The current mingw port is not there yet.\n\nPfft, that'll teach me to reply after only skimming the original \nmessage. Oops. But the main part of my reply is still valid, I think.\n\n-Steve\n"},{"id":"48559","messageId":"fcaeb9bf0707250513v587d7a92lb688b52da3c28bb7@mail.gmail.com","threadId":"9217","inReplyTo":"a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-25T12:13:14Z","receivedAt":"2007-07-25T12:13:14Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/25/07, Dmitry Kakurin wrote:\n> How serious are you guys about Windows support?\n> I'm talking fully-functional port, not Cygwin.\n> I did a lot of searching for a new SCM to switch to (from Perforce).\n> And Git is my #1 choice. I love it's internals design and it's\n> expressive power. I've also tested git-p4 and it has worked like a\n> charm with my depot (with few tweaks that I may contribute later).\n> But I do all my work on Windows so I need Git-For-Windows-Done-Right :-).\n> The current mingw port is not there yet.\n\nWhat features is mingw port missing?\n\n> Transition to the new SCM must happen now, so basically I have 2 choices:\n> 1. Survive for a few months with the current CygWin port of Git\n> knowing that Windows support is coming\n\nFYI, I'm working on getting rid of msys requirement from mingw port. I\ncan't tell you how long it would take though. Could be one month or\ntwo.\n-- \nDuy\n"},{"id":"48560","messageId":"693D0FFF-B271-4781-BCE2-3BF00C8BF426@zib.de","threadId":"9217","inReplyTo":"a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com","subject":"Re: Windows support","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-25T12:30:02Z","receivedAt":"2007-07-25T12:30:02Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 25, 2007, at 12:35 PM, Dmitry Kakurin wrote:\n\n> How serious are you guys about Windows support?\n> I'm talking fully-functional port, not Cygwin.\n\nWhat's wrong with the Cygwin port?\n\nIs it just that windows developer hate cygwin because it's to\ncomplex to install or is there any severe limitation?\nfunctionality? stability? performance?\n\nI'm personally only working on Windows if force to, but people\nare asking me the same question that you have. Does git\nseriously and fully support Windows?\n\n\tSteffen\n"},{"id":"48565","messageId":"Pine.LNX.4.64.0707251510130.14781@racer.site","threadId":"9217","inReplyTo":"fcaeb9bf0707250513v587d7a92lb688b52da3c28bb7@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-25T14:10:34Z","receivedAt":"2007-07-25T14:10:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n\n> FYI, I'm working on getting rid of msys requirement from mingw port. I \n> can't tell you how long it would take though. Could be one month or two. \n\nIs there a repo out there?\n\nCiao,\nDscho\n"},{"id":"48566","messageId":"fcaeb9bf0707250715p7c183a81vc78f641eef493777@mail.gmail.com","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707251510130.14781@racer.site","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-25T14:15:03Z","receivedAt":"2007-07-25T14:15:03Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/25/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n>\n> > FYI, I'm working on getting rid of msys requirement from mingw port. I\n> > can't tell you how long it would take though. Could be one month or two.\n>\n> Is there a repo out there?\n\nhttp://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox\n\nThere are some patches on mob I have not merged to gitbox branch yet.\n\n-- \nDuy\n"},{"id":"48652","messageId":"46A76D83.6020005@peralex.com","threadId":"9217","inReplyTo":"693D0FFF-B271-4781-BCE2-3BF00C8BF426@zib.de","subject":"Re: Windows support","fromName":"Noel Grandin","fromEmail":"noel@peralex.com","sentAt":"2007-07-25T15:34:27Z","receivedAt":"2007-07-25T15:34:27Z","isPatch":false,"sender":{"key":"noel@peralex.com","avatar":null},"body":"\nCygwin tries to make Windows look like unix (from a command-line POV),\nso it very much runs against the grain of \"real\" windows programs.\n\nPlus, it's a pain to install and invoke,\nand doesn't deal nicely with real windows paths (it maps the windows\nfilesystem to a unix-y style single root path structure),\n\n\nSteffen Prohaska wrote:\n>\n> On Jul 25, 2007, at 12:35 PM, Dmitry Kakurin wrote:\n>\n>> How serious are you guys about Windows support?\n>> I'm talking fully-functional port, not Cygwin.\n>\n> What's wrong with the Cygwin port?\n>\n> Is it just that windows developer hate cygwin because it's to\n> complex to install or is there any severe limitation?\n> functionality? stability? performance?\n>\n> I'm personally only working on Windows if force to, but people\n> are asking me the same question that you have. Does git\n> seriously and fully support Windows?\n>\n> Steffen\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\n\nDisclaimer: http://www.peralex.com/disclaimer.html\n"},{"id":"48573","messageId":"316a20a40707250958w1fe9f6fdn41d75ca704aeb9cd@mail.gmail.com","threadId":"9217","inReplyTo":"693D0FFF-B271-4781-BCE2-3BF00C8BF426@zib.de","subject":"Re: Windows support","fromName":"Stephen Cuppett","fromEmail":"cuppett@gmail.com","sentAt":"2007-07-25T16:58:47Z","receivedAt":"2007-07-25T16:58:47Z","isPatch":false,"sender":{"key":"cuppett@gmail.com","avatar":null},"body":"On 7/25/07, Steffen Prohaska wrote:\n\n> Is it just that windows developer hate cygwin because it's to\n> complex to install or is there any severe limitation?\n> functionality? stability? performance?\n\nI actually have no problems with cygwin and find it works pretty well\nwith git repositories. Starting the xserver to run git-gui is pretty\nannoying though. Windows-based development teams are going to expect\neasy access to those kinds of tooling. Otherwise, the champion will\nbe pushing a type of workflow change that would hinder adoption anyway\nand leave a sour taste for a long time.\n\nIn addition, performance is atrocious. In my particular case I have\nan older P4 running F7 and a newer machine running Windows and cygwin.\n On a pserver based cvsimport of a large, enterprise project, Linux\nwas able to generate the full history in 4 hours, cygwin took 3 and a\nhalf days. When I sync up every now and then, typical times for\nwindows are 25 minutes and Linux is around 4. That should give you an\nidea of what kind of multiplier we are talking about.\n\nI don't know if the performance problems are cygwin or not. More\nknowledgeable people might be able to answer, it's just what I'm\nobserving right now. It could be more fundamental to the types of\naccess being performed en masse on inode-based versus NTFS systems.\n"},{"id":"48574","messageId":"Pine.LNX.4.64.0707251813070.14781@racer.site","threadId":"9217","inReplyTo":"fcaeb9bf0707250715p7c183a81vc78f641eef493777@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-25T17:13:15Z","receivedAt":"2007-07-25T17:13:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On 7/25/07, Johannes Schindelin wrote:\n> > Hi,\n> > \n> > On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n> > \n> > > FYI, I'm working on getting rid of msys requirement from mingw port. I\n> > > can't tell you how long it would take though. Could be one month or two.\n> > \n> > Is there a repo out there?\n> \n> http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox\n> \n> There are some patches on mob I have not merged to gitbox branch yet.\n\nThanks,\nDscho\n"},{"id":"48575","messageId":"Pine.LNX.4.64.0707251332100.29679@iabervon.org","threadId":"9217","inReplyTo":"a1bbc6950707250335m3d37d4farceffc50945e31f6c@mail.gmail.com","subject":"Re: Windows support","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-25T17:41:59Z","receivedAt":"2007-07-25T17:41:59Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 25 Jul 2007, Dmitry Kakurin wrote:\n\n> How serious are you guys about Windows support?\n> I'm talking fully-functional port, not Cygwin.\n> I did a lot of searching for a new SCM to switch to (from Perforce).\n> And Git is my #1 choice. I love it's internals design and it's\n> expressive power. I've also tested git-p4 and it has worked like a\n> charm with my depot (with few tweaks that I may contribute later).\n> But I do all my work on Windows so I need Git-For-Windows-Done-Right :-).\n> The current mingw port is not there yet.\n> \n> Transition to the new SCM must happen now, so basically I have 2 choices:\n> 1. Survive for a few months with the current CygWin port of Git\n> knowing that Windows support is coming\n> 2. Use another SCM (#2 is Mercurial, #3 is Monotone)\n> \n> I'd realy love to do #1, but I need to know how long do I have to wait.\n\nIf the issue is the shell scripts, replacing those with C code is coming \nalong nicely; there's a big section (fetch and everything it uses) which \nis ready to go after 1.5.3 comes out, and I believe a number of the other \ncore parts are being taken care of in the same sort of time frame by the \nGSoC people.\n\nI've also been working on reducing the fork/exec usage, if that's the \nissue, but I'm not sure how much of that is left to do or how long it will \ntake.\n\n(Personally, I don't touch windows at all, but I have been working on \nfixing things that seem to be problems for porting to windows, which may \nbe relevant)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"48576","messageId":"loom.20070725T195200-46@post.gmane.org","threadId":"9217","inReplyTo":"316a20a40707250958w1fe9f6fdn41d75ca704aeb9cd@mail.gmail.com","subject":"Re: Windows support","fromName":"Russ Dill","fromEmail":"russ.dill@gmail.com","sentAt":"2007-07-25T17:56:05Z","receivedAt":"2007-07-25T17:56:05Z","isPatch":false,"sender":{"key":"russ.dill@gmail.com","avatar":"https://gravatar.com/avatar/989b24f3fa63126a35d7c74069e2626e715a3b1a86616be9962f7ceae04ff9c5?d=mp&s=160"},"body":"Stephen Cuppett gmail.com> writes:\n\n> I actually have no problems with cygwin and find it works pretty well\n> with git repositories. Starting the xserver to run git-gui is pretty\n> annoying though. Windows-based development teams are going to expect\n> easy access to those kinds of tooling. Otherwise, the champion will\n> be pushing a type of workflow change that would hinder adoption anyway\n> and leave a sour taste for a long time.\n\nI have the version of git that came with cygwin, and I never have to run an X\nserver to run git-gui or gitk.\n\nPersonally, I can't imagine running git without cygwin. Course, I want my\ndesktop to feel as much like unix as possible. My experience with git under\ncygwin has been excellent. My only gripe has to do with CRLF. The repository has\neverything checked in with dos line endings, I'd like to check everything out\nwith unix line endings, and then check it back in with dos line endings. I hate\nseeing the ^M's everywhere.\n\n> In addition, performance is atrocious. In my particular case I have\n> an older P4 running F7 and a newer machine running Windows and cygwin.\n> On a pserver based cvsimport of a large, enterprise project, Linux\n> was able to generate the full history in 4 hours, cygwin took 3 and a\n> half days. When I sync up every now and then, typical times for\n> windows are 25 minutes and Linux is around 4. That should give you an\n> idea of what kind of multiplier we are talking about.\n\nGranted, the performance isn't equal to git running on a real unix, but compared\nto working with SVN under win32, I would say it performs quite well.\n"},{"id":"48577","messageId":"alpine.LFD.0.999.0707251131540.3607@woody.linux-foundation.org","threadId":"9217","inReplyTo":"316a20a40707250958w1fe9f6fdn41d75ca704aeb9cd@mail.gmail.com","subject":"Re: Windows support","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-25T18:43:23Z","receivedAt":"2007-07-25T18:43:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 Jul 2007, Stephen Cuppett wrote:\n> \n> I don't know if the performance problems are cygwin or not. More\n> knowledgeable people might be able to answer, it's just what I'm\n> observing right now. It could be more fundamental to the types of\n> access being performed en masse on inode-based versus NTFS systems.\n\nI think cygwin may add some overhead, but people should really realize \nthat Linux is quite often an order of magnitude faster (or more) than \nother systems on some very basic operations.\n\nThat's especially true for filesystem operations. We really are just that \ngood.\n\nReally simple things like stat/open/read/write/close are just damn fast on \nLinux. To the point where you really do notice it when you compare to \nother systems. If something takes hours on Linux, and it's very \nfilesystem-intensive, I'm not at all surprised that it might take days on \nWindows.\n\n(OS X is probably better than Windows when it comes to filesystem ops, but \ntheir memory management absolutely sucks, and I can pretty much guarantee \nthat their filesystem operation latency doesn't hold a candle to Linux, \nso while I'd expect git to perform \"pretty well\" on OS X, it's still \ngoing to be slower than on Linux)\n\nLinux really *can* be that much faster. You may not see it as much on some \nother loads, where most of the load is about normal user code, and system \ncall performance is likely to be just a small fraction, but for git, most \nof what it does is filesystem interactions (I used to think that SHA1's \nwould be noticeable - they're not, and while zlib overhead *can* be \nnoticeable, it usually isn't a big deal except for some very specific \ncases).\n\nBut I bet that git ends up being faster on Windows than many other SCM's \nare (on Windows). Going native will help, and avoiding things like shell \nscripting will help a *lot*, but it's still always going to be slower on \nWindows than it is on Linux. And that is not about anything else than the \nfact that Linux simply kicks *ss on filesystem ops.\n\nSo for doing things like big imports, you might well want to do them on \nLinux. But that doesn't mean that git will suck on Windows for normal \noperations.\n\n(It will just not be so *blazingly* fast, ie things like \"git status\" will \ngenerally not be instantaneous).\n\n\t\t\tLinus\n"},{"id":"48578","messageId":"598D5675D34BE349929AF5EDE9B03E27012EDD12@az33exm24.fsl.freescale.net","threadId":"9217","inReplyTo":"loom.20070725T195200-46@post.gmane.org","subject":"RE: Re: Windows support","fromName":"Medve Emilian-EMMEDVE1","fromEmail":"emilian.medve@freescale.com","sentAt":"2007-07-25T19:04:56Z","receivedAt":"2007-07-25T19:04:56Z","isPatch":false,"sender":{"key":"emilian.medve@freescale.com","avatar":null},"body":"Hi Russ,\n\n\nTry playing with the core.autocrlf config option.\n\n\nCheers,\nEmil.\n\n\nThis e-mail, and any associated attachments have been classified as:\n--------------------------------------------------------------------\n[x] Public\n[ ] Freescale Semiconductor Internal Use Only\n[ ] Freescale Semiconductor Confidential Proprietary\n\n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\nBehalf Of Russ Dill\nSent: Wednesday, July 25, 2007 12:56 PM\nTo: git@vger.kernel.org\nSubject: Re: Windows support\n\nStephen Cuppett gmail.com> writes:\n\n> I actually have no problems with cygwin and find it works pretty well\n> with git repositories. Starting the xserver to run git-gui is pretty\n> annoying though. Windows-based development teams are going to expect\n> easy access to those kinds of tooling. Otherwise, the champion will\n> be pushing a type of workflow change that would hinder adoption anyway\n> and leave a sour taste for a long time.\n\nI have the version of git that came with cygwin, and I never have to run\nan X\nserver to run git-gui or gitk.\n\nPersonally, I can't imagine running git without cygwin. Course, I want\nmy\ndesktop to feel as much like unix as possible. My experience with git\nunder\ncygwin has been excellent. My only gripe has to do with CRLF. The\nrepository has\neverything checked in with dos line endings, I'd like to check\neverything out\nwith unix line endings, and then check it back in with dos line endings.\nI hate\nseeing the ^M's everywhere.\n\n> In addition, performance is atrocious. In my particular case I have\n> an older P4 running F7 and a newer machine running Windows and cygwin.\n> On a pserver based cvsimport of a large, enterprise project, Linux\n> was able to generate the full history in 4 hours, cygwin took 3 and a\n> half days. When I sync up every now and then, typical times for\n> windows are 25 minutes and Linux is around 4. That should give you an\n> idea of what kind of multiplier we are talking about.\n\nGranted, the performance isn't equal to git running on a real unix, but\ncompared\nto working with SVN under win32, I would say it performs quite well.\n\n\n\n"},{"id":"48579","messageId":"loom.20070725T211142-163@post.gmane.org","threadId":"9217","inReplyTo":"598D5675D34BE349929AF5EDE9B03E27012EDD12@az33exm24.fsl.freescale.net","subject":"Re: Re: Windows support","fromName":"Russ Dill","fromEmail":"russ.dill@gmail.com","sentAt":"2007-07-25T19:13:17Z","receivedAt":"2007-07-25T19:13:17Z","isPatch":false,"sender":{"key":"russ.dill@gmail.com","avatar":"https://gravatar.com/avatar/989b24f3fa63126a35d7c74069e2626e715a3b1a86616be9962f7ceae04ff9c5?d=mp&s=160"},"body":"Medve Emilian-EMMEDVE1 freescale.com> writes:\n\n> \n> Hi Russ,\n> \n> Try playing with the core.autocrlf config option.\n> \n\nIt seems to do the exact opposite of what I would like. My repository is\nimported from SVN with git-svn and all the text files have dos line endings. I\nwould like to checkout with unix line endings, and checkin with dos line endings.\n"},{"id":"48604","messageId":"45446C9F-F33E-4D47-9484-E92D36BB803E@wincent.com","threadId":"9217","inReplyTo":"alpine.LFD.0.999.0707251131540.3607@woody.linux-foundation.org","subject":"Re: Windows support","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-07-25T22:52:26Z","receivedAt":"2007-07-25T22:52:26Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 25/7/2007, a las 20:43, Linus Torvalds escribió:\n\n> I think cygwin may add some overhead, but people should really realize\n> that Linux is quite often an order of magnitude faster (or more) than\n> other systems on some very basic operations.\n>\n> That's especially true for filesystem operations. We really are \n> just that\n> good.\n>\n> Really simple things like stat/open/read/write/close are just damn \n> fast on\n> Linux. To the point where you really do notice it when you compare to\n> other systems. If something takes hours on Linux, and it's very\n> filesystem-intensive, I'm not at all surprised that it might take \n> days on\n> Windows.\n>\n> (OS X is probably better than Windows when it comes to filesystem \n> ops, but\n> their memory management absolutely sucks, and I can pretty much \n> guarantee\n> that their filesystem operation latency doesn't hold a candle to \n> Linux,\n> so while I'd expect git to perform \"pretty well\" on OS X, it's still\n> going to be slower than on Linux)\n\nWould be very interesting to see some \"scientific\" benchmarks of Git \nperformance on the different platforms.\n\nAnyone got an Intel Mac with Windows and Linux installed on it as well?\n\nCheers,\nWincent\n"},{"id":"48619","messageId":"a1bbc6950707251926t11e1d0f7p8e8cd8c936f7ff72@mail.gmail.com","threadId":"9217","inReplyTo":"fcaeb9bf0707250513v587d7a92lb688b52da3c28bb7@mail.gmail.com","subject":"Re: Windows support","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-07-26T02:26:12Z","receivedAt":"2007-07-26T02:26:12Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> What features is mingw port missing?\nWell, 'git commit' from a regular cmd prompt does not work.\nIMHO, That's a pretty serious omission :-).\n"},{"id":"48621","messageId":"a1bbc6950707251956h3db847c9v8db438f4c665b2cf@mail.gmail.com","threadId":"9217","inReplyTo":"46A73015.7020306@midwinter.com","subject":"Re: Windows support","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-07-26T02:56:02Z","receivedAt":"2007-07-26T02:56:02Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 7/25/07, Steven Grimm wrote:\n> > How serious are you guys about Windows support?\n> Much (nearly all?) of the core git team never touches Windows, so they\n> both have no selfish motivation to get it working well and no way to\n> test their changes even if they decide to take it up for the greater good.\n\nThis actually answers my question (if it's true).\nIf core team is not interested in supporting Windows then I cannot\ntrust this system with my source code :-(.\n\nMy concerns are (mostly):\n* lack of (or insufficient) testing for Windows platform\n* possibly lower code quality of Windows port, since core devs don't\ntouch it and don't care\n* possible troubles with support if issues arise\n* Windows port could become abandoned if those few brave people, who\nwork on it right now will leave\n\nIn short, all kinds of issues associated with software not being a\nfirst class citizen :-).\n\n- Dmitry\n"},{"id":"48622","messageId":"7vps2fc196.fsf@assigned-by-dhcp.cox.net","threadId":"9217","inReplyTo":"a1bbc6950707251926t11e1d0f7p8e8cd8c936f7ff72@mail.gmail.com","subject":"Re: Windows support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-26T03:06:13Z","receivedAt":"2007-07-26T03:06:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Dmitry Kakurin\" writes:\n\n> On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n>> What features is mingw port missing?\n> Well, 'git commit' from a regular cmd prompt does not work.\n> IMHO, That's a pretty serious omission :-).\n\nI was under the impression that is only because you do not have\nMSYS installed. Doesn't Windows people have automated way to\npull and install other packages on the dependency?\n"},{"id":"48625","messageId":"20070726031546.GN32566@spearce.org","threadId":"9217","inReplyTo":"a1bbc6950707251956h3db847c9v8db438f4c665b2cf@mail.gmail.com","subject":"Re: Windows support","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-26T03:15:46Z","receivedAt":"2007-07-26T03:15:46Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Dmitry Kakurin wrote:\n> On 7/25/07, Steven Grimm wrote:\n> > > How serious are you guys about Windows support?\n> > Much (nearly all?) of the core git team never touches Windows, so they\n> > both have no selfish motivation to get it working well and no way to\n> > test their changes even if they decide to take it up for the greater good.\n> \n> This actually answers my question (if it's true).\n> If core team is not interested in supporting Windows then I cannot\n> trust this system with my source code :-(.\n\nIt more or less is. Those of us that are most active as Git\ndevelopers don't really use Windows as our core development platform.\nWell, that is not entirely true. Day-job forces Windows on me,\nbecause its the Most Secure Operating System Evar!. :-) I run Cygwin\nthere so I have a sane user interface, and build Git under Cygwin\nrather than MSYS because I just expect the UNIX-like environment\nthat Cygwin gives me.\n\nWhy Cygwin? Because I have to use Windows, but I'd rather use Linux.\nNo, Linux isn't permitted. And Solaris/x86 is only allowed on\n\"servers\". I have yet to find a way to classify my desktop as\na server. :-|\n\ngit-gui is fairly well supported under Cygwin, as I use it a lot\nin my day-job. As do a lot of my coworkers. Which actually gives\nme a pretty good testing ground; ~20 people all beating on git-gui\nall day long is a pretty sizable testing group. I actually wonder\nsome days if git-gui is better tested on Cygwin than it is on Linux.\n\nBut as has been stated on this thread, Cygwin isn't native Windows.\n \n> My concerns are (mostly):\n> * lack of (or insufficient) testing for Windows platform\n> * possibly lower code quality of Windows port, since core devs don't\n> touch it and don't care\n\nWe do care. Its just not our primary focus. Dscho, Junio, Daniel\nBarkalow, Johannes Sixt, myself, even Linus have all contributed\npatches to git that help make it run better on Windows, or make\nit easier to port there. But none of us are running out and\ndedicating our lives to making Git the best software to ever run\non that platform. There's other things more important to us.\n\n> * possible troubles with support if issues arise\n> * Windows port could become abandoned if those few brave people, who\n> work on it right now will leave\n\nThat's always a concern. Heck, day-job invested untold fortunes in\na product we purchased from a large commerical vendor. Runs only on\nWindows. Vendor just up and decided to no longer support the product\nanymore and has left us hanging out to dry. Did I mention that the\nproduct is also closed source and less stable than Git is on Windows?\n\nSo no matter what you use, if the developers leave, you are stuck.\nBut one thing I *really* love about Git is how simple the data\nstructures are and how easy it is to read the repository. Its under\n500 lines of C code to unpack a working directory. More if you\nwant something that's blazing fast and always reliable, but if you\njust want to get the data out its quite simple.\n\nIts also fully open source. GPL'd even. So there's never the\nissue that your vendor runs away and prevents you from taking on\ndevelopment yourself, or just fixing those minor issues that you\nreally need to have fixed.\n \n-- \nShawn.\n"},{"id":"48626","messageId":"20070726031838.GO32566@spearce.org","threadId":"9217","inReplyTo":"7vps2fc196.fsf@assigned-by-dhcp.cox.net","subject":"Re: Windows support","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-26T03:18:38Z","receivedAt":"2007-07-26T03:18:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Dmitry Kakurin\" writes:\n> \n> > On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> >> What features is mingw port missing?\n> > Well, 'git commit' from a regular cmd prompt does not work.\n> > IMHO, That's a pretty serious omission :-).\n> \n> I was under the impression that is only because you do not have\n> MSYS installed. Doesn't Windows people have automated way to\n> pull and install other packages on the dependency?\n\nPackage management? On Windows? Surely you aren't talking about\nthat silly \"Add/Remove Programs\" control panel that just destroys\nyour machine.\n\nI do know the best way to uninstall dependencies on Windows is to\nboot a live Linux CD and `mkfs /dev/hda1`. But as far as installing\nthings go you pray that your vendor has packaged everything you need\nin their shiny click-through installer thing, and if they haven't,\nyou cry wolf and switch to another vendor.\n\n-- \nShawn.\n"},{"id":"48628","messageId":"20070726033605.GP32566@spearce.org","threadId":"9217","inReplyTo":"316a20a40707250958w1fe9f6fdn41d75ca704aeb9cd@mail.gmail.com","subject":"Re: Windows support","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-26T03:36:05Z","receivedAt":"2007-07-26T03:36:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Stephen Cuppett wrote:\n> On 7/25/07, Steffen Prohaska wrote:\n> \n> >Is it just that windows developer hate cygwin because it's to\n> >complex to install or is there any severe limitation?\n> >functionality? stability? performance?\n> \n> I actually have no problems with cygwin and find it works pretty well\n> with git repositories. Starting the xserver to run git-gui is pretty\n> annoying though.\n\nI've never even tried to run it that way. I know the Cygwin packages\nhave two different Tcl/Tk binaries: one that is actually a hacked\nup native Tcl/Tk (which uses native Win32 graphics) and one that\nis a straightup recompile of the UNIX Tcl/Tk (which uses X11 only).\nI only have the native Win32 Tcl/Tk installed, and thus run native\ngraphics.\n\nAn advantage of the native Tcl/Tk is just that, its native.\nA downside is it is native. It doesn't use the Cygwin APIs for exec,\nit directly goes through CreateProcess(). It doesn't use the Cygwin\nAPIs for file IO, it goes directly through the native Win32 stuff.\nWhich means it sometimes has a difficult time with Cygwin paths.\nThere are a few places in git-gui where I run `cygpath -w` just to\nhandle this.\n\nI've also recently tested git-gui under the ActiveState Tcl\ndistribution. It ran, but for reasons unknown to me (I didn't\nresearch it yet) the .git/info/exclude rules didn't apply when\ngit-gui spawned a `git ls-files --others` helper process.\n\nI have considered doing a starkit of git-gui, msys based git\nexecutables/dlls, and the ActiveState Tcl engine. That should give\nusers a single git-gui.exe that they can just download and launch,\nno installation required. Haven't started it yet, partly because\nI haven't finished removing the need for shell scripts to support\ngit-gui. I'm almost there, especially with Daniel Barkalow's work\non a native C fetch.\n\n> Windows-based development teams are going to expect\n> easy access to those kinds of tooling. Otherwise, the champion will\n> be pushing a type of workflow change that would hinder adoption anyway\n> and leave a sour taste for a long time.\n\nI agree. They also want this thing called \"explorer integration\" or\nsomething like that. I've never had good luck with cra^H^H^Hpackages\nthat install themselves into the Windows explorer UI. I would\nprobably never develop such a thing myself.\n\n> I don't know if the performance problems are cygwin or not. More\n> knowledgeable people might be able to answer, it's just what I'm\n> observing right now. It could be more fundamental to the types of\n> access being performed en masse on inode-based versus NTFS systems.\n\nAs Linus described its NTFS/Windows that is horrid here, and not\nreally Cygwin. Linux is just fast. Almost all modern UNIXes are.\nAt least when compared to the Windows kernel running on a crappy\n4500 RPM IDE drive that is also hampered with a virus scanner that\nwants to scan 12 GiB of data every 30 minutes, even when the volume\nhas only 8 GiB of files on it. ;-)\n\nGit is fast. Its faster than SVN on the same hardware. Even under\nWindows. About the only thing that I think is \"slow\" is two areas:\n\n * status. Doing lstat() on 8,000+ files takes a little while.\n Hooking into the OS' native file monitoring facility and having\n that tell us which files are stat-dirty would reduce the need\n for these massive lstat() runs.\n\n * for-each-ref. Opening 400 ref files to read their current SHA-1\n values is not fast on Windows. More aggressively packing refs\n (at least on Windows) may actually be worthwhile. Another option\n might be to have the same process that is watching the OS' file\n monitoring interface cache the ref values, so we can get to them\n via say shared memory or a pipe instead of file IO.\n\nNeither feature is really necessary on a good UNIX however, as most\nkernel development teams have just made sure their system has good\nfile IO throughput. Oh, and they don't have to run virus scanners\nthat get higher IO priority than everything else.\n\n-- \nShawn.\n"},{"id":"48630","messageId":"Pine.LNX.4.64.0707260438210.14781@racer.site","threadId":"9217","inReplyTo":"a1bbc6950707251926t11e1d0f7p8e8cd8c936f7ff72@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T03:38:34Z","receivedAt":"2007-07-26T03:38:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Dmitry Kakurin wrote:\n\n> On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> > What features is mingw port missing?\n> Well, 'git commit' from a regular cmd prompt does not work.\n> IMHO, That's a pretty serious omission :-).\n\nNot true.\n\nCiao,\nDscho\n"},{"id":"48631","messageId":"a1bbc6950707252054p21c48458j5e285604ff8884a5@mail.gmail.com","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707260438210.14781@racer.site","subject":"Re: Windows support","fromName":"Dmitry Kakurin","fromEmail":"dmitry.kakurin@gmail.com","sentAt":"2007-07-26T03:54:12Z","receivedAt":"2007-07-26T03:54:12Z","isPatch":false,"sender":{"key":"dmitry.kakurin@gmail.com","avatar":null},"body":"On 7/25/07, Johannes Schindelin wrote:\n> > On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> > > What features is mingw port missing?\n> > Well, 'git commit' from a regular cmd prompt does not work.\n> > IMHO, That's a pretty serious omission :-).\n> Not true.\n\nWell, repro is very simple:\n* Follow instructions on Git Wiki and install Git from\nhttp://lilypond.org/git/binaries/mingw/\n* run git commit:\nE:\\Git\\usr\\bin>git commit\ngit: 'commit' is not a git-command\n\nI've tried on both Win XP and Vista machines.\n\n- Dmitry\n"},{"id":"48632","messageId":"20070726040003.GR32566@spearce.org","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707260438210.14781@racer.site","subject":"Re: Windows support","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-26T04:00:03Z","receivedAt":"2007-07-26T04:00:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 25 Jul 2007, Dmitry Kakurin wrote:\n> \n> > On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> > > What features is mingw port missing?\n> > Well, 'git commit' from a regular cmd prompt does not work.\n> > IMHO, That's a pretty serious omission :-).\n> \n> Not true.\n\nUse git-gui. ;-) It doesn't need a shell to make commits.\n\nIt currently uses the shell for fetch and for merge. I'm fixing\nmerge this week. I'm hoping Daniel's native C fetch will fix\nthe fetch.\n\n-- \nShawn.\n"},{"id":"48634","messageId":"7v6447bxc1.fsf@assigned-by-dhcp.cox.net","threadId":"9217","inReplyTo":"20070726031838.GO32566@spearce.org","subject":"Re: Windows support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-26T04:30:54Z","receivedAt":"2007-07-26T04:30:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> I do know the best way to uninstall dependencies on Windows is to\n> boot a live Linux CD and `mkfs /dev/hda1`. But as far as installing\n> things go you pray that your vendor has packaged everything you need\n> in their shiny click-through installer thing, and if they haven't,\n> you cry wolf and switch to another vendor.\n\nIf that is the case, \"Git for Windows\" probably should package\nMSYS as part of it, I would think, to match the expectation of\nthe users there. I know two Johannes'es and Han-Wen spent quite\na lot of effort on Windows port and packaging, but perhaps that\nlittle (well, I should not be judging if that is a little or\nhuge, as I do not do Windows) finishing touch would make Windows\nusers much happier?\n"},{"id":"48638","messageId":"46A82D14.6090404@midwinter.com","threadId":"9217","inReplyTo":"a1bbc6950707251956h3db847c9v8db438f4c665b2cf@mail.gmail.com","subject":"Re: Windows support","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-07-26T05:11:48Z","receivedAt":"2007-07-26T05:11:48Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Wrote this reply privately earlier; forwarding to the list at Dmitry's \nsuggestion (though it's rendered slightly less relevant by his \nclarifications)...\n\nDmitry Kakurin wrote:\n> This actually answers my question (if it's true).\n> If core team is not interested in supporting Windows then I cannot\n> trust this system with my source code :-(.\n> \n\nI certainly understand the conclusion, but I'm not sure I would share \nit. Unless you have reason to believe there's something in particular \nabout the Windows environment that would cause git to lose data in \ncircumstances where it wouldn't do so under UNIX-ish systems, it seems \nlike your data should be perfectly safe.\n\nIn the year-and-a-bit I've been lurking on the git mailing list and \nmaking occasional contributions to the code, git has never lost any data \nfor anyone to my knowledge. Its design is extremely paranoid in that \nregard, and the paranoia is not really anything platform-dependent. It's \nstuff like, never overwrite files in place (always write a new file \nthen, once it's written successfully, get rid of the old one if needed). \nOr, as importantly, keep SHA1 hashes of *everything* and double-check \nthem often. Those approaches are just as valid on Windows as on any \nother OS. The SHA1 hashes in particular are pretty unimpeachable, IMO; \nthe times people have thought their git repositories have gotten \ncorrupted, it has always turned out to be underlying filesystem or disk \ncorruption that git's SHA1 checking has caught.\n\nIf there are data loss bugs in git (and of course it's possible, even if \nnone have been reported to my knowledge) IMO they're vastly more likely \nto be generic than platform-specific.\n\nOne nice thing about git is you don't have to take its word for your \ndata integrity. You can, without a whole lot of effort, dump out every \nfile in the repository and verify that it is what git says it is.\n\nAnyway, I guess my feeling would be, if I were going to choose to not \nuse git on Windows it would be because of smoothness of the experience, \nlack of integration with Windows tools, difficult installation process, \nor stuff like that. Data integrity would not even cross my mind as a \ndownside of git.\n\n-Steve\n"},{"id":"48639","messageId":"Pine.LNX.4.64.0707260614500.14781@racer.site","threadId":"9217","inReplyTo":"7v6447bxc1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T05:28:35Z","receivedAt":"2007-07-26T05:28:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Junio C Hamano wrote:\n\n> If that is the case, \"Git for Windows\" probably should package MSYS as \n> part of it, I would think, to match the expectation of the users there. \n> I know two Johannes'es and Han-Wen spent quite a lot of effort on \n> Windows port and packaging, but perhaps that little (well, I should not \n> be judging if that is a little or huge, as I do not do Windows) \n> finishing touch would make Windows users much happier?\n\nWindows users are only happy when they can bug developers.\n\nSeriously again, the biggest problem with Han-Wen's installer was that it \ninsists on cross-compiling _all_ the packages. This makes it easy for \nHan-Wen to upgrade packages and compile the thing on Linux in one go. \nHowever, it never worked with bash, and I could not fix it: I can read \nPython, but not _that_ Python.\n\nSo my plan was to wrap everything needed from an existing MinGW/MSYS \ninstallation, with a minimal installer (NullSoft or whatever) to setup the \nexec dir, perl lib path etc...\n\nHowever, my time is scarce, and it does not exactly help that all I can \nexpect from those who should be thankful is even more complaining.\n\nI mean, I understand Linus' point. I don't even expect a Windows user to \ncompile C. It's long time since I was silly enough to believe that. But \njust wrapping it up in an installer, and a little testing, seems to be too \nmuch to ask. When I don't need the darned thing to begin with.\n\nCiao,\nDscho\n"},{"id":"48640","messageId":"Pine.LNX.4.64.0707260629260.14781@racer.site","threadId":"9217","inReplyTo":"20070726040003.GR32566@spearce.org","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T05:30:04Z","receivedAt":"2007-07-26T05:30:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 26 Jul 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > On Wed, 25 Jul 2007, Dmitry Kakurin wrote:\n> > \n> > > On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> > > > What features is mingw port missing?\n> > > Well, 'git commit' from a regular cmd prompt does not work.\n> > > IMHO, That's a pretty serious omission :-).\n> > \n> > Not true.\n> \n> Use git-gui. ;-) It doesn't need a shell to make commits.\n\nOf course. Ever since I saw git-gui, I was convinced that _this_ is the \ntool Windows users should use.\n\nCiao,\nDscho\n"},{"id":"48646","messageId":"46A8378A.6050201@xs4all.nl","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707260614500.14781@racer.site","subject":"Re: Windows support","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-07-26T05:56:26Z","receivedAt":"2007-07-26T05:56:26Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin wrote:\n>> If that is the case, \"Git for Windows\" probably should package MSYS as \n>> part of it, I would think, to match the expectation of the users there. \n>> I know two Johannes'es and Han-Wen spent quite a lot of effort on \n>> Windows port and packaging, but perhaps that little (well, I should not \n>> be judging if that is a little or huge, as I do not do Windows) \n>> finishing touch would make Windows users much happier?\n> \n> Windows users are only happy when they can bug developers.\n> \n> Seriously again, the biggest problem with Han-Wen's installer was that it \n> insists on cross-compiling _all_ the packages. This makes it easy for \n> Han-Wen to upgrade packages and compile the thing on Linux in one go. \n> However, it never worked with bash, and I could not fix it: I can read \n> Python, but not _that_ Python.\n> \n\nThe problem is not really the python. If you supply me with a shell\nscript that will x-compile bash, I'll hapily code the python spec. IMO\nthe real problem is that bash is a unix shell (tied to unix internals)\nand therefore, compiling it for something as horrid as windows is far\nfrom trivial.\n\nfwiw, I briefly tried compiling msys, but I couldn't even find its\nsources, so I quickly gave up.\n\nA second option is that someone supplies me with an unpacked, installed\ntree of msys' bash shell. I can easily package that up along with the\nrest of the installer, if it doesnt' require further trickery (setting\nregistry entries, etc.)\n"},{"id":"48647","messageId":"87eacd830707252308t32c98108w39b52cdb9c61cd1e@mail.gmail.com","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707260629260.14781@racer.site","subject":"Re: Windows support","fromName":"Henning Rogge","fromEmail":"hrogge@googlemail.com","sentAt":"2007-07-26T06:08:06Z","receivedAt":"2007-07-26T06:08:06Z","isPatch":false,"sender":{"key":"hrogge@googlemail.com","avatar":null},"body":"On 7/26/07, Johannes Schindelin wrote:\n> > Use git-gui. ;-) It doesn't need a shell to make commits.\n>\n> Of course. Ever since I saw git-gui, I was convinced that _this_ is the\n> tool Windows users should use.\nQGit might be a good alternative too, especially because QT4 is\navailable for Windows.\n\nHenning\n"},{"id":"48650","messageId":"08588116-8E66-4F40-BC77-E0B272BE7776@zib.de","threadId":"9217","inReplyTo":"20070726031546.GN32566@spearce.org","subject":"Re: Windows support","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-26T06:25:51Z","receivedAt":"2007-07-26T06:25:51Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 26, 2007, at 5:15 AM, Shawn O. Pearce wrote:\n\n> Why Cygwin? Because I have to use Windows, but I'd rather use Linux.\n> No, Linux isn't permitted. And Solaris/x86 is only allowed on\n> \"servers\". I have yet to find a way to classify my desktop as\n> a server. :-|\n>\n> git-gui is fairly well supported under Cygwin, as I use it a lot\n> in my day-job. As do a lot of my coworkers. Which actually gives\n> me a pretty good testing ground; ~20 people all beating on git-gui\n> all day long is a pretty sizable testing group. I actually wonder\n> some days if git-gui is better tested on Cygwin than it is on Linux.\n>\n> But as has been stated on this thread, Cygwin isn't native Windows.\n\nSo apparently you're working in a reasonably sized group of people all\ntesting git on cygwin. I'd be completely satisfied if git ran rock solid\non cygwin.\n\nI found the following list of warnings about cygwin in the wiki\nentry WindowsInstall [1]. Some points look quite scary to me.\n\nWhat is your real-world experience? Are the warning still valid?\nMust I really fear to break cygwin if I press Ctrl-C?\n\nDo I really need to reboot regularly? I don't think this is an\noption. Nowadays our Windows boxes run for months, too. I can't\nseriously tell people that they need to regularly reboot if they\nwant to use git.\n\nHere's the list, copied from http://git.or.cz/gitwiki/WindowsInstall\n\n * Use git on local NTFS disks -- Network drives disks don't \nsupport the filesystem semantics GIT needs; for interoperability \npurposes you can store bare repositories on FAT32 disks.\n * Be careful with the case in filenames. Similarly, avoid special \nchars in filenames.\n * Run git gc early and often. There are slowdowns with many \nunpacked objects. Be careful to not create very big packfiles (bigger \nthan 2 Gb).\n * Avoid using ActiveState Perl if possible. Ask in the \nMailingLists if you must.\n * Try to avoid interrupting (Ctrl-C) processes - it breaks cygwin.\n * Consider setting core.fileMode to false (git repo-config \ncore.fileMode false) if file modes are frequently the only \ndifferences detected by Git. Many Windows applications make the \nexecute bit be set in Cygwin when they save a file. Besides Cygwin \ndetects file mode by stupid combination of content analysis, file \nname extension and moon phase.\n * Insert \"set CYGWIN=tty binmode\" after the first line of C: \n\\cygwin\\cygwin.bat, so you can use Ctrl-z in cygwin's bash to suspend \na program.\n * Windows usually writes end-of-line as CRLF, while Unix/POSIX \nwrites LF. This can cause a variety of problems. There are current \nefforts to address this.\n * Setup binary mode for cygwin (there is an option in cygwin's \nsetup program), otherwise Cygwin mangles everything read and written \n(Git repos have binary files in control structures).\n * Avoid big repos.\n * Avoid big blobs (very big files. Basically anything larger than \n10Mb is too big).\n * Avoid big trees (directories with many files in them).\n * Avoid deep hierarchies.\n * Reboot regularly (memory fragmentation)\n * Defragment often (filesystems fragmentation)\n\n\tSteffen\n"},{"id":"48657","messageId":"Pine.LNX.4.64.0707260737170.14781@racer.site","threadId":"9217","inReplyTo":"46A8378A.6050201@xs4all.nl","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T06:40:08Z","receivedAt":"2007-07-26T06:40:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[Funny, you quoted me, but culled _me_ from the Cc: list]\n\nOn Wed, 25 Jul 2007, Han-Wen Nienhuys wrote:\n\n> Johannes Schindelin wrote:\n> >> If that is the case, \"Git for Windows\" probably should package MSYS as \n> >> part of it, I would think, to match the expectation of the users there. \n> >> I know two Johannes'es and Han-Wen spent quite a lot of effort on \n> >> Windows port and packaging, but perhaps that little (well, I should not \n> >> be judging if that is a little or huge, as I do not do Windows) \n> >> finishing touch would make Windows users much happier?\n> > \n> > Windows users are only happy when they can bug developers.\n> > \n> > Seriously again, the biggest problem with Han-Wen's installer was that it \n> > insists on cross-compiling _all_ the packages. This makes it easy for \n> > Han-Wen to upgrade packages and compile the thing on Linux in one go. \n> > However, it never worked with bash, and I could not fix it: I can read \n> > Python, but not _that_ Python.\n> > \n> \n> The problem is not really the python.\n\nFor me, it is. Probably you know by now that I am not really a fan of \nPython, mainly because people can write unelegant code which looks \nelegant.\n\n> If you supply me with a shell script that will x-compile bash, I'll \n> hapily code the python spec. IMO the real problem is that bash is a unix \n> shell (tied to unix internals) and therefore, compiling it for something \n> as horrid as windows is far from trivial.\n\nWill do.\n\nDid you succeed in adding perl? It is not that important, because I plan \nto make git-gui the main user interface with this installer. But Junio \nkeeps adding Perl scripts (ATM add -i and remote) that I have to convert \nlater...\n\nCiao,\nDscho\n"},{"id":"48658","messageId":"Pine.LNX.4.64.0707260745030.14781@racer.site","threadId":"9217","inReplyTo":"46A76D83.6020005@peralex.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T06:46:05Z","receivedAt":"2007-07-26T06:46:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 25 Jul 2007, Noel Grandin wrote:\n\n> Cygwin tries to make Windows look like unix (from a command-line POV),\n> so it very much runs against the grain of \"real\" windows programs.\n\nOkay, just because you insist, I will introduce a crash, so that it does \nnot look too much like Unix. Maybe I will do this as an alternate \nhang/crash.\n\nCiao,\nDscho\n"},{"id":"48659","messageId":"7v6447acf3.fsf@assigned-by-dhcp.cox.net","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707260745030.14781@racer.site","subject":"Re: Windows support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-26T06:48:00Z","receivedAt":"2007-07-26T06:48:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Wed, 25 Jul 2007, Noel Grandin wrote:\n>\n>> Cygwin tries to make Windows look like unix (from a command-line POV),\n>> so it very much runs against the grain of \"real\" windows programs.\n>\n> Okay, just because you insist, I will introduce a crash, so that it does \n> not look too much like Unix. Maybe I will do this as an alternate \n> hang/crash.\n\nYou forgot an obligatory smiley. That is not amusing.\n"},{"id":"48662","messageId":"20070726065332.GB18114@spearce.org","threadId":"9217","inReplyTo":"08588116-8E66-4F40-BC77-E0B272BE7776@zib.de","subject":"Re: Windows support","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-26T06:53:32Z","receivedAt":"2007-07-26T06:53:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Steffen Prohaska wrote:\n> On Jul 26, 2007, at 5:15 AM, Shawn O. Pearce wrote:\n> >git-gui is fairly well supported under Cygwin, as I use it a lot\n> >in my day-job. As do a lot of my coworkers. Which actually gives\n> >me a pretty good testing ground; ~20 people all beating on git-gui\n> >all day long is a pretty sizable testing group. I actually wonder\n> >some days if git-gui is better tested on Cygwin than it is on Linux.\n> \n> So apparently you're working in a reasonably sized group of people all\n> testing git on cygwin. I'd be completely satisfied if git ran rock solid\n> on cygwin.\n\nIt is just as rock solid as it is on Mac OS X (my real Git\ndevelopment system) and Solaris. If your Cygwin DLL does not\nsupport pread() you do need to compile with NO_PREAD=1, but that's\na minor issue. Personally I build Git on Cygwin with pread() and\nmmap() enabled and it runs fine. Of course we only use it on local\ndrives, and only on NTFS drives.\n\nAs has been stated already, Git's checksums work nicely to make\nsure data hasn't been corrupted. I've seen one user have trouble\nwith checksums failing in his repository. Usually he recopies it\nfrom another user and picks up where he left off. Twice I've seen\nhis packfile corrupted and Git caught the corruption. We seriously\nsuspect some bad blocks on his drive. But budget says we cannot\nreplace the disk for another 4 years.\n \n> I found the following list of warnings about cygwin in the wiki\n> entry WindowsInstall [1]. Some points look quite scary to me.\n> \n> What is your real-world experience? Are the warning still valid?\n> Must I really fear to break cygwin if I press Ctrl-C?\n\nIts not that Cygwin breaks. Its that sometimes pressing Ctrl-C\ndoesn't actually stop the process, e.g. the signal isn't sent or\njust gets ignored. So its annoying because you can't abort things\nas readily as you might on a good UNIX. Sometimes you get weird\nstack traces from a Git process when you Ctrl-C it. But I also see\nthis same garbage out of a native Windows JVM when I Ctrl-C it from\na Cygwin bash. Its just general Cygwin-ism or something.\n\nDespite those failures I've never seen that stack dump actually\ncorrupt Git data. Think about it. Git needs to be safe on any\nplatform, even if the running Git program terminates unexpectedly\nin the middle of an operation, such as because of an OOM from the\nkernel, or an angry admin `kill -9`ing it. So this little stack\nspew is just annoying more than anything.\n \n> Do I really need to reboot regularly? I don't think this is an\n> option. Nowadays our Windows boxes run for months, too. I can't\n> seriously tell people that they need to regularly reboot if they\n> want to use git.\n\nI *never* reboot my Windows system at day-job. Except when our\nlocal adminstration staff shoves some Microsoft uber-patch down\nonto our systems and that patch forces us to reboot the machine.\nSo I never reboot for Cygwin (or Git's) sake. Ever.\n\n> Here's the list, copied from http://git.or.cz/gitwiki/WindowsInstall\n> \n> * Use git on local NTFS disks -- Network drives disks don't \n> support the filesystem semantics GIT needs; for interoperability \n> purposes you can store bare repositories on FAT32 disks.\n\nStill true. Network drives have some issues as the SMB protocol\ndoesn't support everything nicely. NTFS locally is fine. FAT32 has\nissues with mmap() not being well supported. If you must use\nFAT32 compile Git with NO_MMAP. Which is the default on Cygwin,\nas a lot of people still use FAT32.\n\n> * Be careful with the case in filenames. Similarly, avoid special \n> chars in filenames.\n\nThis is true. Git doesn't like getting file names with case only\ndifferences on such a platform. E.g. just today I wanted to do\nthe following:\n\n git mv foo.c Foo.c\n\nbut had to instead do:\n\n git mv foo.c CRAP && git mv CRAP Foo.c\n\nbecause the former won't work on a filesystem that ignores case.\nI have the same problem on my Mac OS X HFS+ volume as it also\nignores case.\n\n> * Run git gc early and often. There are slowdowns with many \n> unpacked objects. Be careful to not create very big packfiles (bigger \n> than 2 Gb).\n\nBoth of these are still true. git-gui on Windows suggests a repack\nif you have ~256 loose objects, on UNIX platforms it suggest a repack\nat ~2048 loose objects. The problem is really just a performance\nissue, the more files we have to open to access data the slower\nthings go. The loose objects tend to be the really recent stuff\n(that's why they aren't packed yet) and the really recent stuff\ntends to be what is accessed most.\n\nOpening 200 files takes time on Windows. Its just a limitation\nof the OS apparently. And its a fundamental property of the Git\nobject store that we always write to loose objects first, as its\nfast and easy to make safe.\n\nAnother aside to this is `git grep --cached` or `git grep ... TREE`\nis *always* faster for me then grepping the working directory.\nThe first two will return nearly instantly (tiny lag) while the\nworking directory grep will take days. On Linux and Mac OS X the\nexact reverse is true, the working directory grep is usually faster\nif the disk cache is hot.\n\n> * Avoid using ActiveState Perl if possible. Ask in the \n> MailingLists if you must.\n\nYea, we've had some issues with that. This comes from one particular\nuser (Alex Riesen) who uses Cygwin but for strange reasons is\nnot allowed to use the Cygwin perl and instead must only use the\nActiveState Perl. We've had some issues in the past with our Perl\nscripts running on that perl port. Alex has fixed many of them,\nbut some may still be lurking.\n\n> * Try to avoid interrupting (Ctrl-C) processes - it breaks cygwin.\n\nAlready talked about above.\n\n> * Consider setting core.fileMode to false (git repo-config \n> core.fileMode false) if file modes are frequently the only \n> differences detected by Git. Many Windows applications make the \n> execute bit be set in Cygwin when they save a file. Besides Cygwin \n> detects file mode by stupid combination of content analysis, file \n> name extension and moon phase.\n\nWe currently default core.fileMode to false on Cygwin, for this\nvery reason. We used to not do that. We got smarter and realized\nthat although Cygwin itself (and all Cygwin tools) will properly\nhandle the executable bit on NTFS native Windows tools (e.g. Eclipse)\nwon't. Users use the native Windows tools, then blame Git. So we\ndisable it.\n\n> * Insert \"set CYGWIN=tty binmode\" after the first line of C: \n> \\cygwin\\cygwin.bat, so you can use Ctrl-z in cygwin's bash to suspend \n> a program.\n\nOooooh. I did not know this tip. I still just cuss at Cygwin\nanytime I want to suspend a job and cannot.\n\n> * Windows usually writes end-of-line as CRLF, while Unix/POSIX \n> writes LF. This can cause a variety of problems. There are current \n> efforts to address this.\n\nSee the crlf feature in gitattributes. You can now have Git create\nworking tree files in CRLF format, but check them into the object\ndatabase with only LF.\n\n> * Setup binary mode for cygwin (there is an option in cygwin's \n> setup program), otherwise Cygwin mangles everything read and written \n> (Git repos have binary files in control structures).\n\nI think binary mode is the default now on Cygwin. It used to not\nbe. Because of this problem.\n\n> * Avoid big repos.\n\nYea, sort of. I'm using about 180M (fully packed as best as I can\nmake Git do) and its fine. I don't know what a definition of \"big\"\nis.\n\n> * Avoid big blobs (very big files. Basically anything larger than \n> 10Mb is too big).\n\nThis I can't speak to. All of my blobs are source code, so they\nare small-ish.\n\n> * Avoid big trees (directories with many files in them).\n\nProbably true. Most of my trees are reasonably well distributed\n(they aren't that big). I think my largest is 900 files in the\nsame directory.\n\n> * Avoid deep hierarchies.\n\nI/use/java/programs/on/windows/and/much/of/my/source/is/in/that/format.\n:-) I don't really have issues with deep trees, and I have some\npretty darn deep source code trees.\n\n> * Reboot regularly (memory fragmentation)\n\nDon't see that.\n\n> * Defragment often (filesystems fragmentation)\n\nYes! Very much so. The packfiles are the first things to fragment,\nand what with all of the small files that Git creates, especially\nwith frequent branch switching, and then the small object files\nthat my build system creates, my drive is almost always completely\nfragmented.\n\nWhich reminds me, I need to defrag again...\n\n-- \nShawn.\n"},{"id":"48665","messageId":"f329bf540707260002p117937tc9bc70050ef87838@mail.gmail.com","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707260737170.14781@racer.site","subject":"Re: Windows support","fromName":"Han-Wen Nienhuys","fromEmail":"hanwenn@gmail.com","sentAt":"2007-07-26T07:02:01Z","receivedAt":"2007-07-26T07:02:01Z","isPatch":false,"sender":{"key":"hanwenn@gmail.com","avatar":"https://gravatar.com/avatar/058832acb8d613baeb6ce9d21b009d9772424a309b9a521330423daef909a27a?d=mp&s=160"},"body":"2007/7/25, Johannes Schindelin :\n> Hi,\n>\n> [Funny, you quoted me, but culled _me_ from the Cc: list]\n\nIt's because gmane does not do SMTP\n\n> > If you supply me with a shell script that will x-compile bash, I'll\n> > hapily code the python spec. IMO the real problem is that bash is a unix\n> > shell (tied to unix internals) and therefore, compiling it for something\n> > as horrid as windows is far from trivial.\n>\n> Will do.\n>\n> Did you succeed in adding perl?\n\nGod forbid no. Perl is enormous, and I shudder at the thought of\nmaking all those modules compile, or even worse, writing actual perl\ncode.\n\n> It is not that important, because I plan\n> to make git-gui the main user interface with this installer. But Junio\n> keeps adding Perl scripts (ATM add -i and remote) that I have to convert\n> later...\n\nI don't see what this is good for. I would suggest to making a clear\ndecision of what are recommended languages, and move everything else\nto contrib/ .. Currently, C and bash seem the most reasonable choice,\nbut you could decide for perl, but then the consequence should be that\nthe bash scripts are translated into perl. Having both bash and perl\nserves no purpose, and will lead to duplication of library code to\ninteract with the git binary.\n\n-- \nHan-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"48669","messageId":"20070726071316.GE18114@spearce.org","threadId":"9217","inReplyTo":"f329bf540707260002p117937tc9bc70050ef87838@mail.gmail.com","subject":"Re: Windows support","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-26T07:13:16Z","receivedAt":"2007-07-26T07:13:16Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Han-Wen Nienhuys wrote:\n> 2007/7/25, Johannes Schindelin :\n> >Did you succeed in adding perl?\n> \n> >It is not that important, because I plan\n> >to make git-gui the main user interface with this installer. But Junio\n> >keeps adding Perl scripts (ATM add -i and remote) that I have to convert\n> >later...\n> \n> I don't see what this is good for.\n\nWhat git-gui is good for? Its a GUI. For people who perfer to use\nmice and push buttons over keys and a command prompt. A large number\nof people in this world (many of them on Windows) like these things.\nMe, I'm more command line than I am GUI, yet I develop git-gui.\nSo I find myself using it a lot, just so I can eat my own dogfood.\n\nOr do you mean Dscho's other point about rewriting tools into C?\n\n> I would suggest to making a clear\n> decision of what are recommended languages, and move everything else\n> to contrib/ .. Currently, C and bash seem the most reasonable choice,\n> but you could decide for perl, but then the consequence should be that\n> the bash scripts are translated into perl. Having both bash and perl\n> serves no purpose, and will lead to duplication of library code to\n> interact with the git binary.\n\nSure, but there's some stuff that shell is good at, and other stuff\nthat Perl is good at. Forcing everything into one mold while we\nprototype new features is really limiting.\n\nBut both are slower on fork challenged systems than using native C.\nLook at git-fetch for example; my ~400+ branch repository is taking\nupwards of 5 minutes to run a no-argument, no-changes git-fetch in.\nAll sh and fork overhead.\n\n-- \nShawn.\n"},{"id":"48671","messageId":"f329bf540707260018u21ad8e16h75cc9c3351fe0fc2@mail.gmail.com","threadId":"9217","inReplyTo":"20070726071316.GE18114@spearce.org","subject":"Re: Windows support","fromName":"Han-Wen Nienhuys","fromEmail":"hanwenn@gmail.com","sentAt":"2007-07-26T07:18:45Z","receivedAt":"2007-07-26T07:18:45Z","isPatch":false,"sender":{"key":"hanwenn@gmail.com","avatar":"https://gravatar.com/avatar/058832acb8d613baeb6ce9d21b009d9772424a309b9a521330423daef909a27a?d=mp&s=160"},"body":"2007/7/26, Shawn O. Pearce :\n> Han-Wen Nienhuys wrote:\n> > 2007/7/25, Johannes Schindelin :\n> > >Did you succeed in adding perl?\n> >\n> > >It is not that important, because I plan\n> > >to make git-gui the main user interface with this installer. But Junio\n> > >keeps adding Perl scripts (ATM add -i and remote) that I have to convert\n> > >later...\n> >\n> > I don't see what this is good for.\n>\n> What git-gui is good for? Its a GUI. For people who perfer to use\n> mice and push buttons over keys and a command prompt. A large number\n> of people in this world (many of them on Windows) like these things.\n> Me, I'm more command line than I am GUI, yet I develop git-gui.\n> So I find myself using it a lot, just so I can eat my own dogfood.\n>\n> Or do you mean Dscho's other point about rewriting tools into C?\n\nThe last one. The windows installers actually includes a copy of\ntcl/tk so you can run gitk on windows. .\n\n> > I would suggest to making a clear\n> > decision of what are recommended languages, and move everything else\n> > to contrib/ .. Currently, C and bash seem the most reasonable choice,\n> > but you could decide for perl, but then the consequence should be that\n> > the bash scripts are translated into perl. Having both bash and perl\n> > serves no purpose, and will lead to duplication of library code to\n> > interact with the git binary.\n>\n> Sure, but there's some stuff that shell is good at, and other stuff\n> that Perl is good at. Forcing everything into one mold while we\n> prototype new features is really limiting.\n\nI'm not contradicting that, but merely suggesting that they go into\ncontrib/ and are not recommended as standard git commands, and don't\nneed to be packaged for windows.\n\n-- \nHan-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"48675","messageId":"Pine.LNX.4.64.0707260841490.27738@beast.quantumfyre.co.uk","threadId":"9217","inReplyTo":"20070726071316.GE18114@spearce.org","subject":"Re: Windows support","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-26T07:52:12Z","receivedAt":"2007-07-26T07:52:12Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Thu, 26 Jul 2007, Shawn O. Pearce wrote:\n\n> Han-Wen Nienhuys wrote:\n>> 2007/7/25, Johannes Schindelin :\n>>> Did you succeed in adding perl?\n>>\n>>> It is not that important, because I plan\n>>> to make git-gui the main user interface with this installer. But Junio\n>>> keeps adding Perl scripts (ATM add -i and remote) that I have to convert\n>>> later...\n>>\n>> I don't see what this is good for.\n>\n> What git-gui is good for? Its a GUI. For people who perfer to use\n> mice and push buttons over keys and a command prompt. A large number\n> of people in this world (many of them on Windows) like these things.\n> Me, I'm more command line than I am GUI, yet I develop git-gui.\n> So I find myself using it a lot, just so I can eat my own dogfood.\n>\n> Or do you mean Dscho's other point about rewriting tools into C?\n>\n>> I would suggest to making a clear\n>> decision of what are recommended languages, and move everything else\n>> to contrib/ .. Currently, C and bash seem the most reasonable choice,\n>> but you could decide for perl, but then the consequence should be that\n>> the bash scripts are translated into perl. Having both bash and perl\n>> serves no purpose, and will lead to duplication of library code to\n>> interact with the git binary.\n\nWell, that really doesn't make much sense from the Linux POV. Bash, perl \nand C are all well supported languages, each with its own set of \nstrengths. The tools that are being written are true parts of git - not \noptional contributed bolt-ons.\n\nAdmittedly it would probably increase the motivation to make everything \nbuilt in if only C programs were allowed outside of contrib - but git \nwould probably have not got where it is in that case.\n\n> Sure, but there's some stuff that shell is good at, and other stuff\n> that Perl is good at. Forcing everything into one mold while we\n> prototype new features is really limiting.\n>\n> But both are slower on fork challenged systems than using native C.\n> Look at git-fetch for example; my ~400+ branch repository is taking\n> upwards of 5 minutes to run a no-argument, no-changes git-fetch in.\n> All sh and fork overhead.\n\nI have a repo with ~9000 refs - it's what motivated me to start rewriting \nfetch in C ...\n\ntimes for fetch to decide there were no changes (on Linux, local XFS \ndisk):\n\npure-shell: ~45 mins\nshell + C (fetch--tool): ~30 secs\npure C: ~0.5 secs\n\n(the C version isn't the current version that Daniel has, but rather an \nolder incomplete version that I had got far enough to do that much - so \nit may actually be slightly slower now ...)\n\n-- \nJulian\n\n ---\nIf you want to travel around the world and be invited to speak at a lot of\ndifferent places, just write a Unix operating system.\n\n -- Linus Torvalds\n"},{"id":"48677","messageId":"200707260914.48042.andyparkins@gmail.com","threadId":"9217","inReplyTo":"87eacd830707252308t32c98108w39b52cdb9c61cd1e@mail.gmail.com","subject":"Re: Windows support","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-07-26T08:14:46Z","receivedAt":"2007-07-26T08:14:46Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 July 26, Henning Rogge wrote:\n\n> QGit might be a good alternative too, especially because QT4 is\n> available for Windows.\n\nI have a colleague using qgit4 on Windows with git on cygwin. Works very \nwell; and qgit being native rather than tcl/tk+cygwin makes it a lot faster.\n\nI've also seen him using gitweb for browsing around my repository.\n\nWe've never lost data, and have had significantly more success using git \nitself rather than git-cvsserver, which was a constant struggle.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"48682","messageId":"200707261111.54439.robin.rosenberg.lists@dewire.com","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707260614500.14781@racer.site","subject":"Re: Windows support","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-26T09:11:53Z","receivedAt":"2007-07-26T09:11:53Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdag 26 juli 2007 skrev Johannes Schindelin:\n> Hi,\n> \n> On Wed, 25 Jul 2007, Junio C Hamano wrote:\n> \n> > If that is the case, \"Git for Windows\" probably should package MSYS as \n> > part of it, I would think, to match the expectation of the users there. \n> > I know two Johannes'es and Han-Wen spent quite a lot of effort on \n> > Windows port and packaging, but perhaps that little (well, I should not \n> > be judging if that is a little or huge, as I do not do Windows) \n> > finishing touch would make Windows users much happier?\n> \n> Windows users are only happy when they can bug developers.\n> \n> Seriously again, the biggest problem with Han-Wen's installer was that it \n> insists on cross-compiling _all_ the packages. This makes it easy for \n> Han-Wen to upgrade packages and compile the thing on Linux in one go. \n> However, it never worked with bash, and I could not fix it: I can read \n> Python, but not _that_ Python.\n\nWill windows developers need to get Linux just in order to do a two line fix,\nor will the build process work on Windows too (provided the developer gets\na number of extra packages).\n\n-- robin\n"},{"id":"48685","messageId":"46A869A3.6050707@trolltech.com","threadId":"9217","inReplyTo":"alpine.LFD.0.999.0707251131540.3607@woody.linux-foundation.org","subject":"Re: Windows support","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-26T09:30:11Z","receivedAt":"2007-07-26T09:30:11Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Linus Torvalds said the following on 25.07.2007 20:43:\n> On Wed, 25 Jul 2007, Stephen Cuppett wrote:\n>> I don't know if the performance problems are cygwin or not. More\n>> knowledgeable people might be able to answer, it's just what I'm\n>> observing right now. It could be more fundamental to the types\n>> of access being performed en masse on inode-based versus NTFS\n>> systems.\n> \n> I think cygwin may add some overhead, but people should really\n> realize that Linux is quite often an order of magnitude faster (or\n> more) than other systems on some very basic operations.\n> \n(..snip..)\n> \n> (It will just not be so *blazingly* fast, ie things like \"git\n> status\" will generally not be instantaneous).\n\nLet me present some numbers:\nMy repository is ~680MB, and 19323 tracked files, in 2264 directories.\nWhen in a compiled state the total is 27540 files, in 4885 directories.\n\nWhen file system cache is warm, I get the following times:\n Native: dir /B /S 1.077s\n dir /S 1.707s (shows time, size/type)\n MSys: ls -f1AUR 34.608s\n find . -type f 6.718s\n git diff (empty diff) 1.18s\n git status 5.5s\nand when the system cach is cold:\n git status 54.55s\n\nMaybe you guys have other git commands which are also/more interesting\nto look at/benchmark?\n\nWindows people should also be aware that it's possible to tweak the\namount of memory which the OS uses for the file cache. On XP you can\nchange it _roughly_ in System Properties panel (Right-click on My\nComputer), then Advanced - Performance Settings - Advanced -\nMemory Usage:\nNormal setting is \"Programs\" for non-servers Windows systems, while\nyou can select \"System cache\" make the OS allocate more memory for\nthe system caches. I've tried both, and the setting doesn't really\naffect the file operations much when the cache is warm, but it\nprobably affects how long the cache stays warm.\n\nAlso note that you can use Sysinternal's CacheSet (free), to\nmanipulate the working-set parameters of the system file cache.\nYou'll find that here:\n http://www.microsoft.com/technet/sysinternals/FileAndDisk/CacheSet.mspx\n\n-- \n.marius\n\n"},{"id":"48686","messageId":"46A86C42.8070103@trolltech.com","threadId":"9217","inReplyTo":"20070726065332.GB18114@spearce.org","subject":"Re: Windows support","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-26T09:41:22Z","receivedAt":"2007-07-26T09:41:22Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":">> * Be careful with the case in filenames. Similarly, avoid\n>> special chars in filenames.\n> \n> This is true. Git doesn't like getting file names with case only \n> differences on such a platform. E.g. just today I wanted to do the\n> following:\n> \n> git mv foo.c Foo.c\n> \n> but had to instead do:\n> \n> git mv foo.c CRAP && git mv CRAP Foo.c\n> \n> because the former won't work on a filesystem that ignores case. I\n> have the same problem on my Mac OS X HFS+ volume as it also ignores\n> case.\n\nYou can turn off case-insensitivity in the Windows kernel, by\nusing RegEdit, and setting the following registry key to 0:\n\nHKLM\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\kernel\\obcaseinsensitive\n\nI haven't tried it, but it should help your case above. Just keep\nin mind that you can then check in files which your coworkers can't\ncheckout :-)\n\n-- \n.marius\n\n"},{"id":"48687","messageId":"46A86CF2.9080205@trolltech.com","threadId":"9217","inReplyTo":"46A86C42.8070103@trolltech.com","subject":"Re: Windows support","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-26T09:44:18Z","receivedAt":"2007-07-26T09:44:18Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"> You can turn off case-insensitivity in the Windows kernel, by using\n> RegEdit, and setting the following registry key to 0:\n> \n> HKLM\\SYSTEM\\CurrentControlSet\\Control\\Session\n> Manager\\kernel\\obcaseinsensitive\n> \n> I haven't tried it, but it should help your case above. Just keep \n> in mind that you can then check in files which your coworkers can't\n> checkout :-)\n\nPS: You'll have to reboot for it to take effect, and don't blame _me_ \nif it doesn't reboot successfully! ;-)\n\n-- \n.marius\n\n"},{"id":"48688","messageId":"46A878F5.AA590D20@eudaptics.com","threadId":"9217","inReplyTo":"200707261111.54439.robin.rosenberg.lists@dewire.com","subject":"Re: Windows support","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-07-26T10:35:33Z","receivedAt":"2007-07-26T10:35:33Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Robin Rosenberg wrote:\n> torsdag 26 juli 2007 skrev Johannes Schindelin:\n> > Seriously again, the biggest problem with Han-Wen's installer was that it\n> > insists on cross-compiling _all_ the packages. This makes it easy for\n> > Han-Wen to upgrade packages and compile the thing on Linux in one go.\n> > However, it never worked with bash, and I could not fix it: I can read\n> > Python, but not _that_ Python.\n> \n> Will windows developers need to get Linux just in order to do a two line fix,\n> or will the build process work on Windows too (provided the developer gets\n> a number of extra packages).\n\nThe build process works on Windows, too. That's how I do it.\nREADME.MinGW lists the packages that you need.\n\n-- Hannes\n"},{"id":"48691","messageId":"fcaeb9bf0707260429l327f446bq73a8a0a13cd77cf1@mail.gmail.com","threadId":"9217","inReplyTo":"f329bf540707260002p117937tc9bc70050ef87838@mail.gmail.com","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T11:29:06Z","receivedAt":"2007-07-26T11:29:06Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, Han-Wen Nienhuys wrote:\n> 2007/7/25, Johannes Schindelin :\n> > Hi,\n> >\n> > [Funny, you quoted me, but culled _me_ from the Cc: list]\n>\n> It's because gmane does not do SMTP\n>\n> > > If you supply me with a shell script that will x-compile bash, I'll\n> > > hapily code the python spec. IMO the real problem is that bash is a unix\n> > > shell (tied to unix internals) and therefore, compiling it for something\n> > > as horrid as windows is far from trivial.\n> >\n> > Will do.\n> >\n> > Did you succeed in adding perl?\n>\n> God forbid no. Perl is enormous, and I shudder at the thought of\n> making all those modules compile, or even worse, writing actual perl\n> code.\n\nmicroperl [1] maybe? I haven't tried it yet.\n\n[1] http://www.foo.be/docs/tpj/issues/vol5_3/tpj0503-0003.html\n-- \nDuy\n"},{"id":"48694","messageId":"46d6db660707260521u15c2bd85j806d48e0f51a3b9@mail.gmail.com","threadId":"9217","inReplyTo":"fcaeb9bf0707260429l327f446bq73a8a0a13cd77cf1@mail.gmail.com","subject":"Re: Windows support","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-07-26T12:21:56Z","receivedAt":"2007-07-26T12:21:56Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 7/26/07, Nguyen Thai Ngoc Duy wrote:\n> microperl [1] maybe? I haven't tried it yet.\n>\n\nit won't work. I tried that few months back.\n\nplus the fact you'll still need perl modules.\n\nI just had a look at your gitbox gitweb. Did you really manage\nto get busybox-1.6.1 to work with mingw ?\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu\n"},{"id":"48697","messageId":"fcaeb9bf0707260537y4233abaamadf4cb6190ea0eeb@mail.gmail.com","threadId":"9217","inReplyTo":"46d6db660707260521u15c2bd85j806d48e0f51a3b9@mail.gmail.com","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T12:37:19Z","receivedAt":"2007-07-26T12:37:19Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, Christian MICHON wrote:\n> On 7/26/07, Nguyen Thai Ngoc Duy wrote:\n> > microperl [1] maybe? I haven't tried it yet.\n> >\n>\n> it won't work. I tried that few months back.\n>\n> plus the fact you'll still need perl modules.\n>\n> I just had a look at your gitbox gitweb. Did you really manage\n> to get busybox-1.6.1 to work with mingw ?\n\nMost of tools (that are included) work fine. Ash almost works. It can\nrun git status, git commit, git clone.. and most of test cases. There\nare still some missing pieces and bugs to hunt down though.\n-- \nDuy\n"},{"id":"48699","messageId":"46d6db660707260600w6c3ca5d2ve6aaf06c7684789d@mail.gmail.com","threadId":"9217","inReplyTo":"fcaeb9bf0707250715p7c183a81vc78f641eef493777@mail.gmail.com","subject":"Re: Windows support","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-07-26T13:00:52Z","receivedAt":"2007-07-26T13:00:52Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> On 7/25/07, Johannes Schindelin wrote:\n> > Hi,\n> >\n> > On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n> >\n> > > FYI, I'm working on getting rid of msys requirement from mingw port. I\n> > > can't tell you how long it would take though. Could be one month or two.\n> >\n> > Is there a repo out there?\n>\n> http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox\n>\n> There are some patches on mob I have not merged to gitbox branch yet.\n>\n\nbeautiful piece of work, IMHO. I really like the fact you managed some\nbusybox applets to actually work without msys. Really cool idea!\n\nit seems you're not very far off. I believe you intend to replace in git-commit\n\"#!c:/msys/bin/sh\" with something like \"#!c:/gitbox/bin/gitbox ash\", right ?\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu\n"},{"id":"48700","messageId":"fcaeb9bf0707260620i2ec1ab36ka470758edfd570d2@mail.gmail.com","threadId":"9217","inReplyTo":"46d6db660707260600w6c3ca5d2ve6aaf06c7684789d@mail.gmail.com","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T13:20:27Z","receivedAt":"2007-07-26T13:20:27Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, Christian MICHON wrote:\n> On 7/25/07, Nguyen Thai Ngoc Duy wrote:\n> > On 7/25/07, Johannes Schindelin wrote:\n> > > Hi,\n> > >\n> > > On Wed, 25 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n> > >\n> > > > FYI, I'm working on getting rid of msys requirement from mingw port. I\n> > > > can't tell you how long it would take though. Could be one month or two.\n> > >\n> > > Is there a repo out there?\n> >\n> > http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox\n> >\n> > There are some patches on mob I have not merged to gitbox branch yet.\n> >\n>\n> beautiful piece of work, IMHO. I really like the fact you managed some\n> busybox applets to actually work without msys. Really cool idea!\n>\n> it seems you're not very far off. I believe you intend to replace in git-commit\n> \"#!c:/msys/bin/sh\" with something like \"#!c:/gitbox/bin/gitbox ash\", right ?\n\nNo. I tweaked try_shell_exec() to use gitbox shell if the interpreter is \"sh\".\n\n-- \nDuy\n"},{"id":"48701","messageId":"46d6db660707260632q16f927a2r64f6b4588dd3cb48@mail.gmail.com","threadId":"9217","inReplyTo":"fcaeb9bf0707260620i2ec1ab36ka470758edfd570d2@mail.gmail.com","subject":"Re: Windows support","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-07-26T13:32:47Z","receivedAt":"2007-07-26T13:32:47Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 7/26/07, Nguyen Thai Ngoc Duy wrote:\n> On 7/26/07, Christian MICHON wrote:\n> > it seems you're not very far off. I believe you intend to replace in git-commit\n> > \"#!c:/msys/bin/sh\" with something like \"#!c:/gitbox/bin/gitbox ash\", right ?\n>\n> No. I tweaked try_shell_exec() to use gitbox shell if the interpreter is \"sh\".\n>\n\ninteresting. have you tried inserting busybox vi inside git-box ?\n\nI can commit using \"git commit -a -m ok\", but then I get this kind of\nerror message (and ash dies, I go back to xp/cmd prompt)\n\nmv: cannot rename '.git/next-index4540': File exists\nC:/gitbox/bin/git-commit: exit: line 658: Illegal number: -1\n\nnice piece of work. it could really be tiny once fixed.\n\nI suggest to replace most git-* by git-box/ash shell wrappers,\ncalling the git.exe binary directly.\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu\n"},{"id":"48702","messageId":"fcaeb9bf0707260655v1dbbacfbta23e670713683963@mail.gmail.com","threadId":"9217","inReplyTo":"46d6db660707260632q16f927a2r64f6b4588dd3cb48@mail.gmail.com","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T13:55:11Z","receivedAt":"2007-07-26T13:55:11Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, Christian MICHON wrote:\n> On 7/26/07, Nguyen Thai Ngoc Duy wrote:\n> > On 7/26/07, Christian MICHON wrote:\n> > > it seems you're not very far off. I believe you intend to replace in git-commit\n> > > \"#!c:/msys/bin/sh\" with something like \"#!c:/gitbox/bin/gitbox ash\", right ?\n> >\n> > No. I tweaked try_shell_exec() to use gitbox shell if the interpreter is \"sh\".\n> >\n>\n> interesting. have you tried inserting busybox vi inside git-box ?\n\nNot yet. That would be fun but I rather focus on ash in the moment.\nYou could set EDITOR to notepad or something else.\n\n> I can commit using \"git commit -a -m ok\", but then I get this kind of\n> error message (and ash dies, I go back to xp/cmd prompt)\n>\n> mv: cannot rename '.git/next-index4540': File exists\n\nBaah.. something goes wrong again.\n\n> C:/gitbox/bin/git-commit: exit: line 658: Illegal number: -1\n>\n> nice piece of work. it could really be tiny once fixed.\n\nUm.. that \"Illegal number\" might be an ash bug. Intended to fix it but\nthen forgot :(\n\n>\n> I suggest to replace most git-* by git-box/ash shell wrappers,\n> calling the git.exe binary directly.\n\nCool. Will do.\n\n> --\n> Christian\n> --\n> http://detaolb.sourceforge.net/, a linux distribution for Qemu\n>\n\n\n-- \nDuy\n"},{"id":"48708","messageId":"Pine.LNX.4.64.0707261534550.14781@racer.site","threadId":"9217","inReplyTo":"fcaeb9bf0707260537y4233abaamadf4cb6190ea0eeb@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T14:37:21Z","receivedAt":"2007-07-26T14:37:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On 7/26/07, Christian MICHON wrote:\n> > On 7/26/07, Nguyen Thai Ngoc Duy wrote:\n> > > microperl [1] maybe? I haven't tried it yet.\n> > >\n> > \n> > it won't work. I tried that few months back.\n> > \n> > plus the fact you'll still need perl modules.\n> > \n> > I just had a look at your gitbox gitweb. Did you really manage\n> > to get busybox-1.6.1 to work with mingw ?\n> \n> Most of tools (that are included) work fine. Ash almost works. It can \n> run git status, git commit, git clone.. and most of test cases. There \n> are still some missing pieces and bugs to hunt down though.\n\nThank you for working on this!\n\nHowever, I am not completely convinced that having a builtin shell is all \nthat useful. I for one would like to have MinGW busybox _separate_ from \ngit...\n\nYes, you could not use the nice \"ln -s busybox ash\" idiom, since Windows \nlacks symlinks, but you could still say \"busybox ash\" with a relatively \nsmall, single executable.\n\nCiao,\nDscho\n"},{"id":"48710","messageId":"fcaeb9bf0707260807u476719e3rec2dcf5f780013c0@mail.gmail.com","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707261534550.14781@racer.site","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T15:07:22Z","receivedAt":"2007-07-26T15:07:22Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n>\n> > On 7/26/07, Christian MICHON wrote:\n> > > On 7/26/07, Nguyen Thai Ngoc Duy wrote:\n> > > > microperl [1] maybe? I haven't tried it yet.\n> > > >\n> > >\n> > > it won't work. I tried that few months back.\n> > >\n> > > plus the fact you'll still need perl modules.\n> > >\n> > > I just had a look at your gitbox gitweb. Did you really manage\n> > > to get busybox-1.6.1 to work with mingw ?\n> >\n> > Most of tools (that are included) work fine. Ash almost works. It can\n> > run git status, git commit, git clone.. and most of test cases. There\n> > are still some missing pieces and bugs to hunt down though.\n>\n> Thank you for working on this!\n>\n> However, I am not completely convinced that having a builtin shell is all\n> that useful. I for one would like to have MinGW busybox _separate_ from\n> git...\n\nI make MinGW busybox part of git for some reasons:\n\n - Making a full MinGW busybox would take lots of time. I don't need\nbusybox for Windows. What I need is a shell and enough POSIX utilities\nto run git shell scripts without any dependencies. Windows users\n(including myself when I have to use Windows) hate dependencies.\n - I don't want MinGW busybox to be used outside of git (if it is\ninstalled separated from git), there are cygwin and msys already. I\ndon't want to compete them. And I don't like conflicts (not sure\nthough) because you have multiple UNIX emulations on the same system.\n - Making ash part of git has an advantage that you could tune the\nshell to fit git. Earlier you had to replace find/sort with\n/usr/bin/find and /usr/bin/sort in git scripts to avoid Windows\nalternatives. I don't like that. If you have control over the shell,\nyou could make it ignore whatever program out there and use your own\nones. This one is not a strong point though.\n - MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c\nand other stuff like run-command.c... Making it separate (as source\ncode) duplicates code for nothing.\n - If you meant separating from git.exe binary, not from source code,\nthen it's ok.\n\n>\n> Yes, you could not use the nice \"ln -s busybox ash\" idiom, since Windows\n> lacks symlinks, but you could still say \"busybox ash\" with a relatively\n> small, single executable.\n>\n> Ciao,\n> Dscho\n>\n>\n\n\n-- \nDuy\n"},{"id":"48711","messageId":"46A8BCD8.B925922@eudaptics.com","threadId":"9217","inReplyTo":"fcaeb9bf0707260655v1dbbacfbta23e670713683963@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-07-26T15:25:12Z","receivedAt":"2007-07-26T15:25:12Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n> \n> On 7/26/07, Christian MICHON wrote:\n> > I can commit using \"git commit -a -m ok\", but then I get this kind of\n> > error message (and ash dies, I go back to xp/cmd prompt)\n> >\n> > mv: cannot rename '.git/next-index4540': File exists\n> \n> Baah.. something goes wrong again.\n\nThe problem is likely that rename() of MSCVRT.DLL is implemented in\nterms of MoveFile(), which can't move over an existing file. A wrapper\nis needed that uses MoveFileEx() instead.\n\nWe have the same problem also in git-apply: One of the tests fails for\nthis reason.\n\n-- Hannes\n"},{"id":"48712","messageId":"Pine.LNX.4.64.0707261638100.14781@racer.site","threadId":"9217","inReplyTo":"fcaeb9bf0707260807u476719e3rec2dcf5f780013c0@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T15:43:01Z","receivedAt":"2007-07-26T15:43:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n\n> I make MinGW busybox part of git for some reasons:\n> \n> - Making a full MinGW busybox would take lots of time. I don't need\n> busybox for Windows. What I need is a shell and enough POSIX utilities\n> to run git shell scripts without any dependencies. Windows users\n> (including myself when I have to use Windows) hate dependencies.\n\nI think that if you succeed to compile ash on MinGW, the rest is easy.\n\n> - I don't want MinGW busybox to be used outside of git (if it is\n> installed separated from git), there are cygwin and msys already. I\n> don't want to compete them. And I don't like conflicts (not sure\n> though) because you have multiple UNIX emulations on the same system.\n\nBut you'd be my hero.\n\nInstalling Cygwin is often overkill if all I need is just a tiny shell \nwith just enough POSIX tools to run my scripts.\n\nInstalling MinGW is painful. Not because of MinGW, but because there is \nno single installer for all I want. You need to install MinGW, MSYS, MSYS \nDTK, iconv, bash (because the default is to old), etc. etc.\n\nWith busybox it would be busybox.exe.\n\n> - Making ash part of git has an advantage that you could tune the\n> shell to fit git. Earlier you had to replace find/sort with\n> /usr/bin/find and /usr/bin/sort in git scripts to avoid Windows\n> alternatives. I don't like that. If you have control over the shell,\n> you could make it ignore whatever program out there and use your own\n> ones. This one is not a strong point though.\n\nI doubt that this is useful. We do want to support the other systems as \nwell, so we have to kinda stick with the available workarounds.\n\n> - MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c\n> and other stuff like run-command.c... Making it separate (as source\n> code) duplicates code for nothing.\n\nIt is not duplication. It is forking. Which is a good thing.\n\n> - If you meant separating from git.exe binary, not from source code,\n> then it's ok.\n\nYes. Although I see your point in making it a builtin \"git-ash\" that can \nbe called without an extra fork(), using beginthread instead.\n\nCiao,\nDscho\n"},{"id":"48713","messageId":"fcaeb9bf0707260911y4091b525kc6b89beb82ec7dc7@mail.gmail.com","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707261638100.14781@racer.site","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T16:11:20Z","receivedAt":"2007-07-26T16:11:20Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n>\n> > I make MinGW busybox part of git for some reasons:\n> >\n> > - Making a full MinGW busybox would take lots of time. I don't need\n> > busybox for Windows. What I need is a shell and enough POSIX utilities\n> > to run git shell scripts without any dependencies. Windows users\n> > (including myself when I have to use Windows) hate dependencies.\n>\n> I think that if you succeed to compile ash on MinGW, the rest is easy.\n\nNo it's not. With a couple of ifdefs you can compile it fine. Then\nthere goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...\nFortunately Git does not use lots of features. It only needs /dev/null\n(and /dev/zero for tests), SIGEXIT and no job usage.. That cuts down\nthe effort porting ash.\n\n> > - I don't want MinGW busybox to be used outside of git (if it is\n> > installed separated from git), there are cygwin and msys already. I\n> > don't want to compete them. And I don't like conflicts (not sure\n> > though) because you have multiple UNIX emulations on the same system.\n>\n> But you'd be my hero.\n\nCan't say I don't love to ;-) It's just that I don't have enough time.\nOnce project \"busybox for Windows\" is born, people may scream for\nfeatures. Even if they don't, there are still bunch of work because I\nhave only ported a small number of tools. With Git as its sole\ncustomer, I can beg Git contributors to limit POSIX tools that they\nuse.\n\nBut if someone steps up for the project, I'm all for it.\n\n> Installing Cygwin is often overkill if all I need is just a tiny shell\n> with just enough POSIX tools to run my scripts.\n\nI see your point. Although you can install git and have git-box to\nplay with (oh spread git! lolz) Just keep in mind you don't have all\nPOSIX tools.\n\n> > - MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c\n> > and other stuff like run-command.c... Making it separate (as source\n> > code) duplicates code for nothing.\n>\n> It is not duplication. It is forking. Which is a good thing.\n\nI still don't see why duplicating compat/*, git-compat-util.h,\nrun-command.[ch]... and keeping fixing bugs in two places is a good\nthing.\n-- \nDuy\n"},{"id":"48717","messageId":"46A8D2BE.7070309@trolltech.com","threadId":"9217","inReplyTo":"fcaeb9bf0707260807u476719e3rec2dcf5f780013c0@mail.gmail.com","subject":"Re: Windows support","fromName":"Marius Storm-Olsen","fromEmail":"marius@trolltech.com","sentAt":"2007-07-26T16:58:38Z","receivedAt":"2007-07-26T16:58:38Z","isPatch":false,"sender":{"key":"marius@trolltech.com","avatar":"https://gravatar.com/avatar/a40071d8f651862c6ab10bd7996f0ad84d94f06c0399de9e3fa4f06beb390a71?d=mp&s=160"},"body":"Nguyen Thai Ngoc Duy wrote:\n> On 7/26/07, Johannes Schindelin wrote:\n>> Thank you for working on this!\n>>\n>> However, I am not completely convinced that having a builtin shell is all\n>> that useful. I for one would like to have MinGW busybox _separate_ from\n>> git...\n> \n> I make MinGW busybox part of git for some reasons:\n> \n> - Making a full MinGW busybox would take lots of time. I don't need\n> busybox for Windows. What I need is a shell and enough POSIX utilities\n> to run git shell scripts without any dependencies. Windows users\n> (including myself when I have to use Windows) hate dependencies.\n> - I don't want MinGW busybox to be used outside of git (if it is\n> installed separated from git), there are cygwin and msys already. I\n> don't want to compete them. And I don't like conflicts (not sure\n> though) because you have multiple UNIX emulations on the same system.\n(..snip..)\n\nHi Duy,\n\n*drool*\nThis was an extremely good idea! Thank you so much for working on it!\nI'll be sure to play around with it, and see if there's any way I can\nhelp out. Guess I finally have to get that MinGW compile environment set\nup then :-)\n\nBtw, are you compiling with MinGW on Windows, or cross-compiling on Linux?\n\nNeat neat neat!\n\n--\n.marius\n\n"},{"id":"48723","messageId":"8564478243.fsf@lola.goethe.zz","threadId":"9217","inReplyTo":"fcaeb9bf0707260911y4091b525kc6b89beb82ec7dc7@mail.gmail.com","subject":"Re: Windows support","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-26T18:13:32Z","receivedAt":"2007-07-26T18:13:32Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n> On 7/26/07, Johannes Schindelin wrote:\n>> Hi,\n>>\n>> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n>>\n>> > I make MinGW busybox part of git for some reasons:\n>> >\n>> > - Making a full MinGW busybox would take lots of time. I don't need\n>> > busybox for Windows. What I need is a shell and enough POSIX utilities\n>> > to run git shell scripts without any dependencies. Windows users\n>> > (including myself when I have to use Windows) hate dependencies.\n>>\n>> I think that if you succeed to compile ash on MinGW, the rest is easy.\n>\n> No it's not. With a couple of ifdefs you can compile it fine. Then\n> there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...\n> Fortunately Git does not use lots of features. It only needs\n> /dev/null (and /dev/zero for tests), SIGEXIT and no job usage.. That\n> cuts down the effort porting ash.\n\nAnd here I was tempted to multithread builtin-update-index.c: it is\nactually quite natural to let one process scan directories\nnon-recursively, stat the files, sort them on a per-directory grain\nand feed a sorted pseudo-index into a pipeline (recursing to scanning\nwhenever hitting a directory), then let another process/thread do a\nmerge-pass of pseudo-index and real index, immediately writing the\noutput to a new index-to-be. When this is finished and another\nprocess invalidated the old index already, reuse the index-to-be as\npseudo-index and merge it with the new-index-which-got-in-ahead-of-me.\n\nWould be a fun exercise in particular when merely using\n(block-buffered!) pipes, and could presumably make a difference on\nmultiprocessor-capable machines.\n\nAnyway, just something that had been spinning in my head. The\n\"streaming merge\" idea has the advantage of keeping memory usage low\npretty much independently of project size: project memory is pretty\nmuch determined by the reader pass since it has to read in a complete\ndirectory level before it can sort it and output the next element, and\nit has to retain the not-yet-output elements of the ancestry.\n\nAnd it is nice to have some potential for parallel processing. But if\nit is a lethal stumbling block for Windows... It is conceivable to do\nthe same job instead of with pipes and files with buffers and just\nswitch manually between the directory scanning and merging phases.\nBut it would be less fun.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48724","messageId":"Pine.LNX.4.64.0707261917150.14781@racer.site","threadId":"9217","inReplyTo":"fcaeb9bf0707260911y4091b525kc6b89beb82ec7dc7@mail.gmail.com","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-26T18:18:48Z","receivedAt":"2007-07-26T18:18:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On 7/26/07, Johannes Schindelin wrote:\n> >\n> > Earlier, Nguyen Thai Ngoc Duy wrote:\n> \n> > > - MinGW busybox (or gitbox as I call it now) utilizes compat/mingw.c \n> > > and other stuff like run-command.c... Making it separate (as source \n> > > code) duplicates code for nothing.\n> > \n> > It is not duplication. It is forking. Which is a good thing.\n> \n> I still don't see why duplicating compat/*, git-compat-util.h,\n> run-command.[ch]... and keeping fixing bugs in two places is a good\n> thing.\n\nActually, it would pretty easy to set up a tracking script with Git, I \nguess. But I can look into that once you finished your gitbox. \nThanks for doing it BTW...\n\nCiao,\nDscho\n"},{"id":"48733","messageId":"fcaeb9bf0707261239t6479a4f4j6dedfbaef7206535@mail.gmail.com","threadId":"9217","inReplyTo":"8564478243.fsf@lola.goethe.zz","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T19:39:21Z","receivedAt":"2007-07-26T19:39:21Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, David Kastrup wrote:\n> \"Nguyen Thai Ngoc Duy\" writes:\n>\n> > On 7/26/07, Johannes Schindelin wrote:\n> >> Hi,\n> >>\n> >> On Thu, 26 Jul 2007, Nguyen Thai Ngoc Duy wrote:\n> >>\n> >> > I make MinGW busybox part of git for some reasons:\n> >> >\n> >> > - Making a full MinGW busybox would take lots of time. I don't need\n> >> > busybox for Windows. What I need is a shell and enough POSIX utilities\n> >> > to run git shell scripts without any dependencies. Windows users\n> >> > (including myself when I have to use Windows) hate dependencies.\n> >>\n> >> I think that if you succeed to compile ash on MinGW, the rest is easy.\n> >\n> > No it's not. With a couple of ifdefs you can compile it fine. Then\n> > there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...\n> > Fortunately Git does not use lots of features. It only needs\n> > /dev/null (and /dev/zero for tests), SIGEXIT and no job usage.. That\n> > cuts down the effort porting ash.\n>\n> And here I was tempted to multithread builtin-update-index.c: it is\n> actually quite natural to let one process scan directories\n> non-recursively, stat the files, sort them on a per-directory grain\n> and feed a sorted pseudo-index into a pipeline (recursing to scanning\n> whenever hitting a directory), then let another process/thread do a\n> merge-pass of pseudo-index and real index, immediately writing the\n> output to a new index-to-be. When this is finished and another\n> process invalidated the old index already, reuse the index-to-be as\n> pseudo-index and merge it with the new-index-which-got-in-ahead-of-me.\n>\n(snip)\n\nIf you are going to do it. I suggest to base on official mingw branch.\nI haven't looked at builtin-update-index.c (hey, I'm all doing sh\nscripts these days) so no comments here.\n\n-- \nDuy\n"},{"id":"48735","messageId":"fcaeb9bf0707261243v65f6e9deof8e266590e05d49f@mail.gmail.com","threadId":"9217","inReplyTo":"46A8D2BE.7070309@trolltech.com","subject":"Re: Windows support","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-07-26T19:43:15Z","receivedAt":"2007-07-26T19:43:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 7/26/07, Marius Storm-Olsen wrote:\n> Nguyen Thai Ngoc Duy wrote:\n> > On 7/26/07, Johannes Schindelin wrote:\n> >> Thank you for working on this!\n> >>\n> >> However, I am not completely convinced that having a builtin shell is all\n> >> that useful. I for one would like to have MinGW busybox _separate_ from\n> >> git...\n> >\n> > I make MinGW busybox part of git for some reasons:\n> >\n> > - Making a full MinGW busybox would take lots of time. I don't need\n> > busybox for Windows. What I need is a shell and enough POSIX utilities\n> > to run git shell scripts without any dependencies. Windows users\n> > (including myself when I have to use Windows) hate dependencies.\n> > - I don't want MinGW busybox to be used outside of git (if it is\n> > installed separated from git), there are cygwin and msys already. I\n> > don't want to compete them. And I don't like conflicts (not sure\n> > though) because you have multiple UNIX emulations on the same system.\n> (..snip..)\n>\n> Hi Duy,\n>\n> *drool*\n> This was an extremely good idea! Thank you so much for working on it!\n> I'll be sure to play around with it, and see if there's any way I can\n> help out. Guess I finally have to get that MinGW compile environment set\n> up then :-)\n>\n> Btw, are you compiling with MinGW on Windows, or cross-compiling on Linux?\n\nI cross-compile all the time (and test it on Windows when I have one,\non the buggy Wine when not). I'd absolutely appreciate bug reports\nregarding building it on Windows ;-)\n-- \nDuy\n"},{"id":"48736","messageId":"46d6db660707261302u26f5df3bwfdf6319b37087ce2@mail.gmail.com","threadId":"9217","inReplyTo":"fcaeb9bf0707261243v65f6e9deof8e266590e05d49f@mail.gmail.com","subject":"Re: Windows support","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-07-26T20:02:35Z","receivedAt":"2007-07-26T20:02:35Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 7/26/07, Nguyen Thai Ngoc Duy wrote:\n> I cross-compile all the time (and test it on Windows when I have one,\n> on the buggy Wine when not). I'd absolutely appreciate bug reports\n> regarding building it on Windows ;-)\n\nearlier on, when I reported a successful compilation and few problems\nwhile committing, it was on XP. I'll be offline for the next 2 weeks,\nbut I can dedicate some time to your porting.\n\nI second also what Dscho said. You'd be my hero too if porting\nbbox over XP. Imagine \"bbox + tcc + make + git\"...\n\n:)\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu\n"},{"id":"48737","messageId":"85sl7b6ie4.fsf@lola.goethe.zz","threadId":"9217","inReplyTo":"fcaeb9bf0707261239t6479a4f4j6dedfbaef7206535@mail.gmail.com","subject":"Re: Windows support","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-26T20:04:51Z","receivedAt":"2007-07-26T20:04:51Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n> On 7/26/07, David Kastrup wrote:\n>> \"Nguyen Thai Ngoc Duy\" writes:\n>\n>> > No it's not. With a couple of ifdefs you can compile it fine. Then\n>> > there goes fork(), fcntl(F_DUPFD), /dev/*, job/signal handling...\n>> > Fortunately Git does not use lots of features. It only needs\n>> > /dev/null (and /dev/zero for tests), SIGEXIT and no job usage.. That\n>> > cuts down the effort porting ash.\n>>\n>> And here I was tempted to multithread builtin-update-index.c: it is\n>> actually quite natural to let one process scan directories\n>> non-recursively, stat the files, sort them on a per-directory grain\n>> and feed a sorted pseudo-index into a pipeline (recursing to scanning\n>> whenever hitting a directory), then let another process/thread do a\n>> merge-pass of pseudo-index and real index, immediately writing the\n>> output to a new index-to-be. When this is finished and another\n>> process invalidated the old index already, reuse the index-to-be as\n>> pseudo-index and merge it with the new-index-which-got-in-ahead-of-me.\n>>\n> (snip)\n>\n> If you are going to do it. I suggest to base on official mingw\n> branch.\n\nWhy would I do that? I am not using Windows. Since Windows NT was\nflaunting threads big style years before Linux, I should not think\nthis implementation approach really to be a major porting hurdle, at\nleast if one indeed uses pipes for the IPC.\n\nIt should actually be doable with a clone system call or\npthread_create, whatever is easier to translate into Windows\nsemantics. The latter probably is more portable nowadays.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48741","messageId":"f8b4ak$8pe$1@sea.gmane.org","threadId":"9217","inReplyTo":"f329bf540707260018u21ad8e16h75cc9c3351fe0fc2@mail.gmail.com","subject":"Re: Windows support","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-26T21:39:35Z","receivedAt":"2007-07-26T21:39:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Han-Wen Nienhuys wrote:\n\n> 2007/7/26, Shawn O. Pearce :\n>> Han-Wen Nienhuys wrote:\n\n>>> I would suggest to making a clear\n>>> decision of what are recommended languages, and move everything else\n>>> to contrib/ .. Currently, C and bash seem the most reasonable choice,\n>>> but you could decide for perl, but then the consequence should be that\n>>> the bash scripts are translated into perl. Having both bash and perl\n>>> serves no purpose, and will lead to duplication of library code to\n>>> interact with the git binary.\n>>\n>> Sure, but there's some stuff that shell is good at, and other stuff\n>> that Perl is good at. Forcing everything into one mold while we\n>> prototype new features is really limiting.\n> \n> I'm not contradicting that, but merely suggesting that they go into\n> contrib/ and are not recommended as standard git commands, and don't\n> need to be packaged for windows.\n\nThey can be not packaged for windows, but for example git-send-email\n(which is written in Perl) is IMHO important enough to be in git proper\nand not delegated to contrib/; but it is packaged in separate RPM,\ngit-email. Same with git-svn package...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"49392","messageId":"f8rv65$1b3$1@sea.gmane.org","threadId":"9217","inReplyTo":"Pine.LNX.4.64.0707251139580.14781@racer.site","subject":"Re: Windows support","fromName":"Asger Ottar Alstrup","fromEmail":"asger@ottaralstrup.dk","sentAt":"2007-08-02T06:57:08Z","receivedAt":"2007-08-02T06:57:08Z","isPatch":false,"sender":{"key":"asger@ottaralstrup.dk","avatar":null},"body":"Johannes Schindelin wrote:\n> On Wed, 25 Jul 2007, Dmitry Kakurin wrote:\n> \n>> How serious are you guys about Windows support?\n> \n> Okay, let's talk business:\n> \n> Pay me decently, and you will have to wait for a few weeks.\n\nI propose that you set up a fundable:\n\nhttp://fundable.com/\n\nThis is a system where anyone can contribute money to the project, but \nnot have to pay unless the required amount of money has been contributed \nin total.\n\nFigure out your price, describe what you will deliver, and announce it.\n\nRegards,\nAsger Ottar Alstrup\n"},{"id":"49412","messageId":"Pine.LNX.4.64.0708021134070.14781@racer.site","threadId":"9217","inReplyTo":"f8rv65$1b3$1@sea.gmane.org","subject":"Re: Windows support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-02T10:45:50Z","receivedAt":"2007-08-02T10:45:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 2 Aug 2007, Asger Ottar Alstrup wrote:\n\n> Johannes Schindelin wrote:\n> > On Wed, 25 Jul 2007, Dmitry Kakurin wrote:\n> > \n> > > How serious are you guys about Windows support?\n> > \n> > Okay, let's talk business:\n> > \n> > Pay me decently, and you will have to wait for a few weeks.\n> \n> I propose that you set up a fundable:\n> \n> http://fundable.com/\n> \n> This is a system where anyone can contribute money to the project, but not\n> have to pay unless the required amount of money has been contributed in total.\n> \n> Figure out your price, describe what you will deliver, and announce it.\n\nI am not that much interested in money, really. But I do want to get \nsomething back in return for my efforts. And no, this does not include \nwhining and complaints.\n\nIt includes useful bug reports. It includes a willingness to keep working \nwith me until the bugs are fleshed out. It possibly includes making (and \nmaintaining!) an installer.\n\nAt the moment, I am happy to say that Git works for me. Even on Windows. \nI have no problems with the command line, and both Cygwin and MinGW Git do \ntheir job reliably and joyfully here.\n\nBut there might come a time when I get into a position much like Shawn, \nwhen I have to work with Aunt and Uncle Tillies, who are not as \nclueful and intelligent^W^W^Wused to the command line as I am.\n\nSo I want to exploit Open Source, meaning that I give _you_ something, and \n_you_ give me something back. And that might very well be just a \nsuggestion \"make the commit button stick out; I did not find it, since \nthere are so many buttons\". Or a nice comic \"how to use git\". Also a \nbeer is appreciated. Or whatever.\n\nMy complaint \"let's talk business\" was some (frustrated) way to get the \nattention of people who do _not_ give something back, and are astonished \nthat just complaining will not get them anywhere.\n\nFWIW I just applied for the project \"Git on MSys\" on SourceForge. Let's \nsee how this will work out.\n\nOh, and I will _not_ do such a thing as think about what you might want, \nand then proclaim what would be my price for it. You _know_ what you \nwant, so why don't you just tell me, as a detailed list?\n\nCiao,\nDscho\n"}]}