{"thread":{"id":"10283","subject":"Re: Switching from CVS to GIT","startedAt":"2007-10-14T17:10:05Z","lastAt":"2007-10-17T19:33:32Z","messageCount":120,"participants":["Benoit SIGOURE","Marco Costalba","Johannes Schindelin","Andreas Ericsson","Alex Riesen","Eli Zaretskii","Dave Korn","David Brown","Brian Dessent","Michael Gebetsroither","Martin Langhoff","Johannes Sixt","Steffen Prohaska","David Kastrup","Paul Smith","Linus Torvalds","Mark Watts","Shawn O. Pearce","Daniel Barkalow","Nguyen Thai Ngoc Duy","Peter Karlsson","Nicolas Pitre","Christopher Faylor","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55742","messageId":"1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr","threadId":"10283","inReplyTo":"1192381040.4908.57.camel@homebase.localnet","subject":"Re: Switching from CVS to GIT","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-10-14T17:10:05Z","receivedAt":"2007-10-14T17:10:05Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"Context: GNU make seems to be willing to switch from CVS to ... \nsomething else.\n\nOn Oct 14, 2007, at 6:57 PM, Paul Smith wrote:\n\n> [...] the big thing no one else seems to have addressed much in\n> other discussions I've seen is portability. It LOOKS like there are\n> native ports of GIT to MINGW, but I have no idea how complete and \n> usable\n> they are. If someone who has a Windows system could look into that it\n> would be a big help.\n\nI think the best thing to do is to ask directly on the Git ML.\n\nSomeone already pointed out that he'd like to use Git on Windows but \ndoesn't want to install either Cygwin or MSYS. Is this possible, or \nwill it be possible in the near future? Is it possible to use one of \nthe various GUIs (git-gui, gitk, qgit) on Windows without requiring a \nPOSIXish shell etc.?\n\nWhen will the librarification of Git be finished? (if Git is \navailable as a library, and if this library works on Windows, it will \ngreatly help truly native Windows ports).\n\nNot that I like Windows in any way, right, but it's legitimate for \npeople working on Windows ports of various software to be willing to \nhave a truly native port of Git for Windows.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n\n\n_______________________________________________\nMake-w32 mailing list\nMake-w32@gnu.org\nhttp://lists.gnu.org/mailman/listinfo/make-w32\n"},{"id":"55755","messageId":"e5bfff550710141106o5fd065c5yb8a3b627a06aab42@mail.gmail.com","threadId":"10283","inReplyTo":"1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr","subject":"Re: Switching from CVS to GIT","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2007-10-14T18:06:57Z","receivedAt":"2007-10-14T18:06:57Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 10/14/07, Benoit SIGOURE wrote:\n>\n> Is it possible to use one of\n> the various GUIs (git-gui, gitk, qgit) on Windows without requiring a\n> POSIXish shell etc.?\n>\n\nqgit-2.0 works natively under Windows\n\nhttp://sourceforge.net/project/showfiles.php?group_id=139897\n\nCheck the README for how to install.\n\n\nMarco\n"},{"id":"55758","messageId":"Pine.LNX.4.64.0710141916510.25221@racer.site","threadId":"10283","inReplyTo":"1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T18:20:37Z","receivedAt":"2007-10-14T18:20:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Benoit SIGOURE wrote:\n\n> Context: GNU make seems to be willing to switch from CVS to ... \n> something else.\n> \n> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:\n> \n> > [...] the big thing no one else seems to have addressed much in other \n> > discussions I've seen is portability. It LOOKS like there are native \n> > ports of GIT to MINGW, but I have no idea how complete and usable they \n> > are. If someone who has a Windows system could look into that it \n> > would be a big help.\n\nThere is msysGit. This project is nearing to its first beta, being \nself-hosted since mid-August IIRC.\n\nIt is a port of Git to MinGW, using parts of MSys as long as we have \ndependencies on bash and perl.\n\nI have no doubt that we'll manage to finish version 0.3 of the installer \nthis week, still not decided if it is still alpha or already beta.\n\nThere are some issues with using msysGit, none of them really serious, but \nyou better be ready to ask questions on this list or #git in case \nsomething crops up. msysGit is young.\n\nHaving said that, IMHO msysGit is already quite usable, and should be \npretty stable within a few weeks (if it is not already).\n\nCiao,\nDscho\n"},{"id":"55759","messageId":"47125F74.9050600@op5.se","threadId":"10283","inReplyTo":"1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr","subject":"Re: Switching from CVS to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-14T18:27:00Z","receivedAt":"2007-10-14T18:27:00Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Benoit SIGOURE wrote:\n> Context: GNU make seems to be willing to switch from CVS to ... \n> something else.\n> \n> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:\n> \n>> [...] the big thing no one else seems to have addressed much in\n>> other discussions I've seen is portability. It LOOKS like there are\n>> native ports of GIT to MINGW, but I have no idea how complete and usable\n>> they are. If someone who has a Windows system could look into that it\n>> would be a big help.\n> \n> I think the best thing to do is to ask directly on the Git ML.\n> \n> Someone already pointed out that he'd like to use Git on Windows but \n> doesn't want to install either Cygwin or MSYS. Is this possible, or \n> will it be possible in the near future?\n\nIt is sort of possible. Without cygwin he'll be in the black for the few\nfeatures that are still implemented as shell-scripts, but perhaps he/she\nwill then be inclined to help us migrate those scripts to C builtins.\n\n> Is it possible to use one of \n> the various GUIs (git-gui, gitk, qgit) on Windows without requiring a \n> POSIXish shell etc.?\n> \n\nqgit is possible to use natively, if one installs the qgit4 libraries for\nwindows, but it's more of a viewer than an action gui. git-gui and gitk\nare usable if you have the windows TCL port. I haven't tried it, but\nthere are installers available, so testing it out (with all dependencies)\nshouldn't take too long.\n\n> When will the librarification of Git be finished?\n\nWhen someone gets around to doing it ;-)\n\nFor a real answer, I'll have to defer to others. Everything works to my\nsatisfaction where I'm using it, so I'm not very inclined to fiddle with\nit and risk breaking things.\n\n> (if Git is available \n> as a library, and if this library works on Windows, it will greatly help \n> truly native Windows ports).\n> \n\nYup. I believe the primary reason for libification is to easier support\nboth porting and fully-fledged gui's.\n\n> Not that I like Windows in any way, right, but it's legitimate for \n> people working on Windows ports of various software to be willing to \n> have a truly native port of Git for Windows.\n> \n\nNaturally. Amazingly few of those stuck with windows have so far\nvolunteered for helping out though, and since many of us on this list\ndon't even have a windows system for testing, it's kinda slow going :-/\n\nI'd imagine getting in touch with Dscho to get a list of what's needed,\nor reading the biweekly msys.git herald on this list, is the best way\nof finding out the porting project's current priorities.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55760","messageId":"Pine.LNX.4.64.0710141934310.25221@racer.site","threadId":"10283","inReplyTo":"47125F74.9050600@op5.se","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T18:39:07Z","receivedAt":"2007-10-14T18:39:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Andreas Ericsson wrote:\n\n> Benoit SIGOURE wrote:\n> > Context: GNU make seems to be willing to switch from CVS to ... something\n> > else.\n> > \n> > On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:\n> > \n> > > [...] the big thing no one else seems to have addressed much in\n> > > other discussions I've seen is portability. It LOOKS like there are\n> > > native ports of GIT to MINGW, but I have no idea how complete and usable\n> > > they are. If someone who has a Windows system could look into that it\n> > > would be a big help.\n> > \n> > I think the best thing to do is to ask directly on the Git ML.\n> > \n> > Someone already pointed out that he'd like to use Git on Windows but \n> > doesn't want to install either Cygwin or MSYS. Is this possible, or \n> > will it be possible in the near future?\n> \n> It is sort of possible. Without cygwin he'll be in the black for the few \n> features that are still implemented as shell-scripts, but perhaps he/she \n> will then be inclined to help us migrate those scripts to C builtins.\n\nUmm. There are quite a few shell scripts still _necessary_ to run git: \ngit-commit, git-fetch and git-merge being the most prominent ones. The \nfirst two are in the process of being rewritten _right_ _now_, but no \nofficial git release has them yet.\n\nAnd I have to disagree strongly with the \"black\": In msysGit (which brings \nits own minimal version of MSys), it is very smooth.\n\n> > Is it possible to use one of the various GUIs (git-gui, gitk, qgit) \n> > on Windows without requiring a POSIXish shell etc.?\n> > \n> \n> qgit is possible to use natively, if one installs the qgit4 libraries \n> for windows, but it's more of a viewer than an action gui. git-gui and \n> gitk are usable if you have the windows TCL port. I haven't tried it, \n> but there are installers available, so testing it out (with all \n> dependencies) shouldn't take too long.\n\nFWIW msysGit comes with Tcl. You can run git gui and gitk without any \nhassles.\n\n> > When will the librarification of Git be finished?\n> \n> When someone gets around to doing it ;-)\n\nThere has been a GSoC project, and it has a nice small API which can be \ncalled from Python, for example.\n\nFunnily enough, the first user is qgit as far as I know, which is written \nin C++...\n\n> > (if Git is available as a library, and if this library works on \n> > Windows, it will greatly help truly native Windows ports).\n> \n> Yup. I believe the primary reason for libification is to easier support \n> both porting and fully-fledged gui's.\n\nWhy?\n\nI do not see any reason why libification helps the user experience on \nWindows.\n\nCiao,\nDscho\n"},{"id":"55762","messageId":"47126957.1020204@op5.se","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710141934310.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-14T19:09:11Z","receivedAt":"2007-10-14T19:09:11Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 14 Oct 2007, Andreas Ericsson wrote:\n> \n>> Benoit SIGOURE wrote:\n>>> Context: GNU make seems to be willing to switch from CVS to ... something\n>>> else.\n>>>\n>>> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:\n>>>\n>>>> [...] the big thing no one else seems to have addressed much in\n>>>> other discussions I've seen is portability. It LOOKS like there are\n>>>> native ports of GIT to MINGW, but I have no idea how complete and usable\n>>>> they are. If someone who has a Windows system could look into that it\n>>>> would be a big help.\n>>> I think the best thing to do is to ask directly on the Git ML.\n>>>\n>>> Someone already pointed out that he'd like to use Git on Windows but \n>>> doesn't want to install either Cygwin or MSYS. Is this possible, or \n>>> will it be possible in the near future?\n>> It is sort of possible. Without cygwin he'll be in the black for the few \n>> features that are still implemented as shell-scripts, but perhaps he/she \n>> will then be inclined to help us migrate those scripts to C builtins.\n> \n> Umm. There are quite a few shell scripts still _necessary_ to run git: \n> git-commit, git-fetch and git-merge being the most prominent ones. The \n> first two are in the process of being rewritten _right_ _now_, but no \n> official git release has them yet.\n> \n\nAh, right. I think of \"accepted into git.git\" as being released.\n\n> And I have to disagree strongly with the \"black\": In msysGit (which brings \n> its own minimal version of MSys), it is very smooth.\n> \n\nOh? I didn't know that. Windows and its unixifying toolboxes is unknown\nterritory to me, as I happily spend all my time on various unices.\n\n>>> Is it possible to use one of the various GUIs (git-gui, gitk, qgit) \n>>> on Windows without requiring a POSIXish shell etc.?\n>>>\n>> qgit is possible to use natively, if one installs the qgit4 libraries \n>> for windows, but it's more of a viewer than an action gui. git-gui and \n>> gitk are usable if you have the windows TCL port. I haven't tried it, \n>> but there are installers available, so testing it out (with all \n>> dependencies) shouldn't take too long.\n> \n> FWIW msysGit comes with Tcl. You can run git gui and gitk without any \n> hassles.\n> \n\nYes, my phrasing there was a bit obscure. I meant that all dependencies\nare installed by the installer package.\n\n>>> (if Git is available as a library, and if this library works on \n>>> Windows, it will greatly help truly native Windows ports).\n>> Yup. I believe the primary reason for libification is to easier support \n>> both porting and fully-fledged gui's.\n> \n> Why?\n> \n> I do not see any reason why libification helps the user experience on \n> Windows.\n> \n\nI was under the impression that the windows port suffers from Windows'\nlack of a proper fork() and friends and that a proper library would\nhelp solving those problems. Perhaps I was misinformed.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55767","messageId":"Pine.LNX.4.64.0710142112540.25221@racer.site","threadId":"10283","inReplyTo":"47126957.1020204@op5.se","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T20:14:25Z","receivedAt":"2007-10-14T20:14:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Andreas Ericsson wrote:\n\n> Johannes Schindelin wrote:\n>\n> > I do not see any reason why libification helps the user experience on \n> > Windows.\n> \n> I was under the impression that the windows port suffers from Windows' \n> lack of a proper fork() and friends and that a proper library would help \n> solving those problems. Perhaps I was misinformed.\n\nIt suffered. Until Hannes Sixt did a very fine job which cumulated in the \npatch series he posted yesterday. Of course, this work is the reason \nmsysGit is functional.\n\nCiao,\nDscho\n"},{"id":"55785","messageId":"20071014221446.GC2776@steel.home","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710142112540.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-14T22:14:46Z","receivedAt":"2007-10-14T22:14:46Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Sun, Oct 14, 2007 22:14:25 +0200:\n> On Sun, 14 Oct 2007, Andreas Ericsson wrote:\n> > Johannes Schindelin wrote:\n> >\n> > > I do not see any reason why libification helps the user experience on \n> > > Windows.\n> > \n> > I was under the impression that the windows port suffers from Windows' \n> > lack of a proper fork() and friends and that a proper library would help \n> > solving those problems. Perhaps I was misinformed.\n> \n> It suffered. Until Hannes Sixt did a very fine job which cumulated in the \n> patch series he posted yesterday. Of course, this work is the reason \n> msysGit is functional.\n> \n\nRe \"functional\". Have to remind something (besides the fork):\n\nFilesystem:\n\n- no proper VFS (can't do anything with files opened elsewhere, and we\n have not enough error handling and diagnostic output to detect the\n problems)\n\n- no proper filename semantics (case-insensitivity and stupid rules for\n allowed characters in filenames, like \":\" in filenames in\n cross-platform projects)\n\n- no acceptable level of performance in filesystem and VFS (readdir,\n stat, open and read/write are annoyingly slow)\n\n- it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n can be not the same, depending on what current \"drive\" is) and\n multi-cwd, which hasn't had formed itself into a problem yet, but\n surely will\n\n- no real \"mmap\" (which kills perfomance and complicates code)\n\nInterprocess communication:\n\n- no reliable text environment (I'm programming in the damn thing for\n 10 years and I still don't know how to pass an environment variable\n _for_sure_)\n\n- it has only one argument (limited in size) passed to started\n programs, which means that there is no possible way to safely pass\n file and text arguments on command line (more than one, that is)\n"},{"id":"55792","messageId":"u7ilpjp3x.fsf@gnu.org","threadId":"10283","inReplyTo":"20071014221446.GC2776@steel.home","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-14T22:41:38Z","receivedAt":"2007-10-14T22:41:38Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 00:14:46 +0200\n> From: Alex Riesen \n> Cc: Andreas Ericsson , Benoit SIGOURE ,\n> \tgit list , Eli Zaretskii ,\n> \tMake Windows \n> \n> Re \"functional\". Have to remind something (besides the fork):\n\nThat's a 20-20 hindsight: if you deliberately write a program to rely\nheavily on Posix-isms, don't be surprised when you discover that it\ncannot be easily ported to other platforms.\n\n> - no proper VFS\n\nI'm not sure what you are talking about. What VFS do you use on\nGNU/Linux that cannot work on Windows, and why do you use it?\n\n> - no proper filename semantics (case-insensitivity and stupid rules for\n> allowed characters in filenames, like \":\" in filenames in\n> cross-platform projects)\n\nThere's a flag on Windows to open files case-sensitively, if you need\nthat. In any case, I don't see how this can be of any real relevance\nto porting GIT. As for \":\" in file names, simply don't use it, like\nyou don't use white space or characters below 32 decimal: it's\ninconvenient, even if it's allowed.\n\n> - no acceptable level of performance in filesystem and VFS (readdir,\n> stat, open and read/write are annoyingly slow)\n\nWith what libraries? Native `stat' and `readdir' are quite fast.\nPerhaps you mean the ported glibc (libgw32c), where `readdir' is\nindeed painfully slow, but then you don't need to use it.\n\n> - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> can be not the same, depending on what current \"drive\" is)\n\nSo what? on Unix \"a/b/c\" can be not the same. Both cases are simply\nnot complete file names, that's all. No one said there must be a\nsingle root for all volumes, it's the Posix jingoism creeping in\nagain.\n\n> and multi-cwd\n\nNo longer a problem on Windows versions since 2000.\n\n> - no real \"mmap\" (which kills perfomance and complicates code)\n\nYou only need mmap because you are accustomed to use it on GNU/Linux.\n\n> Interprocess communication:\n> \n> - no reliable text environment (I'm programming in the damn thing for\n> 10 years and I still don't know how to pass an environment variable\n> _for_sure_)\n> \n> - it has only one argument (limited in size) passed to started\n> programs, which means that there is no possible way to safely pass\n> file and text arguments on command line (more than one, that is)\n\nNot enough context, so I cannot talk intelligently about this. Why do\nyou need interprocess communication in the first place? why not simply\ngive birth to a subsidiary process and pass it a command line (which\ncan be up to 32KB)?\n"},{"id":"55795","messageId":"023101c80eb5$e3b6b310$2e08a8c0@CAM.ARTIMI.COM","threadId":"10283","inReplyTo":"20071014221446.GC2776@steel.home","subject":"RE: Switching from CVS to GIT","fromName":"Dave Korn","fromEmail":"dave.korn@artimi.com","sentAt":"2007-10-14T22:59:35Z","receivedAt":"2007-10-14T22:59:35Z","isPatch":false,"sender":{"key":"dave.korn@artimi.com","avatar":null},"body":"On 14 October 2007 23:15, Alex Riesen wrote:\n\n> Interprocess communication:\n> \n> - no reliable text environment (I'm programming in the damn thing for\n> 10 years and I still don't know how to pass an environment variable\n> _for_sure_)\n> \n> - it has only one argument (limited in size) passed to started\n> programs, which means that there is no possible way to safely pass\n> file and text arguments on command line (more than one, that is)\n\n Whuh?\n\nhttp://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx\n\n\n cheers,\n DaveK\n-- \nCan't think of a witty .sigline today....\n"},{"id":"55797","messageId":"Pine.LNX.4.64.0710150039120.25221@racer.site","threadId":"10283","inReplyTo":"u7ilpjp3x.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-14T23:45:47Z","receivedAt":"2007-10-14T23:45:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Eli Zaretskii wrote:\n\n> Alex Riesen said:\n> \n> > - no proper VFS\n> \n> I'm not sure what you are talking about. What VFS do you use on \n> GNU/Linux that cannot work on Windows, and why do you use it?\n\nThe problem is that on Windows, you cannot keep a file open and delete it \nat the same time. This is an issue in Windows' equivalent of VFS.\n\nA neat trick to work with temporary files without permission issues is to \nopen the file and delete it right after that. This does not work on \nWindows.\n\n> > - no proper filename semantics (case-insensitivity and stupid rules for\n> > allowed characters in filenames, like \":\" in filenames in\n> > cross-platform projects)\n> \n> There's a flag on Windows to open files case-sensitively, if you need\n> that.\n\nThe problem is not so much opening, but determining if an existing file \nand a file in the index have the same name.\n\nFor example, \"README\" in the index, but \"readme\" in the working directory, \nwill be handled as \"deleted/untracked\" by the current machinery. IOW git \nwill not know that what it gets from readdir() as \"readme\" really is the \nsame file as \"README\" in the index.\n\n> > - no acceptable level of performance in filesystem and VFS (readdir,\n> > stat, open and read/write are annoyingly slow)\n> \n> With what libraries? Native `stat' and `readdir' are quite fast. \n> Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed \n> painfully slow, but then you don't need to use it.\n\nNo, native.\n\nOnce you experienced the performance of git on Linux, then rebooted into \nWindows on the same box, you will grow a beard while waiting for trivial \noperations.\n\nSure, git kicks ass on Windows, but only as compared to other programs _on \nWindows_.\n\n> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> > can be not the same, depending on what current \"drive\" is)\n> \n> So what? on Unix \"a/b/c\" can be not the same. Both cases are simply not \n> complete file names, that's all. No one said there must be a single \n> root for all volumes, it's the Posix jingoism creeping in again.\n\nI think Alex means this: you can have C:\\a\\b\\c and D:\\a\\b\\c. So depending \non which drive you are, you mean one or the other. Just comparing the \npaths is not enough.\n\n> > - no real \"mmap\" (which kills perfomance and complicates code)\n> \n> You only need mmap because you are accustomed to use it on GNU/Linux.\n\nYes. And we rely on the performance very much.\n\nHth,\nDscho\n"},{"id":"55798","messageId":"4712AC8C.9050006@op5.se","threadId":"10283","inReplyTo":"u7ilpjp3x.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-14T23:55:56Z","receivedAt":"2007-10-14T23:55:56Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Eli Zaretskii wrote:\n>> Date: Mon, 15 Oct 2007 00:14:46 +0200\n>> From: Alex Riesen \n>> Cc: Andreas Ericsson , Benoit SIGOURE ,\n>> \tgit list , Eli Zaretskii ,\n>> \tMake Windows \n>>\n>> Re \"functional\". Have to remind something (besides the fork):\n> \n> That's a 20-20 hindsight: if you deliberately write a program to rely\n> heavily on Posix-isms, don't be surprised when you discover that it\n> cannot be easily ported to other platforms.\n> \n\nTrue. It was originally developed because Linux kernel development came\nto a stand-still and needed an scm quickly. Since the original design\nworked out nicely, nobody bothered (then) about possible future porting\nissues. Windows is still a second class citizen, but that's true for\npretty much every unix-born application out there, so I'm not all that\nstressed out about it.\n\n> \n>> - no proper filename semantics (case-insensitivity and stupid rules for\n>> allowed characters in filenames, like \":\" in filenames in\n>> cross-platform projects)\n> \n> There's a flag on Windows to open files case-sensitively, if you need\n> that. In any case, I don't see how this can be of any real relevance\n> to porting GIT.\n\n\nBecause having\n\n\tPath/foo\n\tpath/Foo\n\tPATH\n\tpath/foo\n\nis possible in git's native playground, but not on windows, so it can\nquite seriously hamper cross-platform cooperation. When that happens,\nusers usually start blaming the tools in use. Browse the list archives\nfor HFS and you'll see what I mean, although come to think of it, the\nHFS problems might actually be worse, since HFS reports case-changes\nwhile not actually being case-sensitive.\n\n\n> As for \":\" in file names, simply don't use it, like\n> you don't use white space or characters below 32 decimal: it's\n> inconvenient, even if it's allowed.\n> \n\nIt's still a real problem because sooner or later someone will use that,\nand it needs to be handled with a bit more grace than just bombing out.\n\n> \n>> - no real \"mmap\" (which kills perfomance and complicates code)\n> \n> You only need mmap because you are accustomed to use it on GNU/Linux.\n> \n\nNot really. mmap() provides a real performance boost when reading large\nrepos, due to the sliding window code that handles pack-files. mmap\nwas invented for occasions like that, and was allowed to endure because\nit was a much better solution than simply read(fd, buf, st.st_size) and\nmoving pointers around.\n\n\n>> Interprocess communication:\n>>\n>> - no reliable text environment (I'm programming in the damn thing for\n>> 10 years and I still don't know how to pass an environment variable\n>> _for_sure_)\n>>\n>> - it has only one argument (limited in size) passed to started\n>> programs, which means that there is no possible way to safely pass\n>> file and text arguments on command line (more than one, that is)\n> \n> Not enough context, so I cannot talk intelligently about this. Why do\n> you need interprocess communication in the first place?\n\n\nBecause some of the commands operate on large data-sets that are best\npassed as a stream. It's ridiculously easy to set that up on unix, but\n(afaiu) quite troublesome under windows.\n\n\n> why not simply\n> give birth to a subsidiary process and pass it a command line (which\n> can be up to 32KB)?\n\nI believe work is in progress that will run things as threads rather\nthan using fork()+execve(). 32KiB of data is nowhere near enough to\nsustain many of the more data-hungry commands. Or rather, it won't be\nonce the repository has grown passed 50-odd revisions.\n\n\nAll that being said, welcome to the git mailing list. Hopefully you\ncan help iron out the wrinkles on windows. You seem to have a fairly\ngood grasp of what's available there, and I'm sure the msys team would\nbe pretty happy to get a few patches to speed them on their way.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55799","messageId":"Pine.LNX.4.64.0710150059460.25221@racer.site","threadId":"10283","inReplyTo":"023101c80eb5$e3b6b310$2e08a8c0@CAM.ARTIMI.COM","subject":"RE: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T00:01:00Z","receivedAt":"2007-10-15T00:01:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Dave Korn wrote:\n\n> On 14 October 2007 23:15, Alex Riesen wrote:\n> \n> > Interprocess communication:\n> > \n> > - no reliable text environment (I'm programming in the damn thing for\n> > 10 years and I still don't know how to pass an environment variable\n> > _for_sure_)\n> > \n> > - it has only one argument (limited in size) passed to started\n> > programs, which means that there is no possible way to safely pass\n> > file and text arguments on command line (more than one, that is)\n> \n> Whuh?\n> \n> http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx\n\nIt does have an exec() call, yes, since that is required by the C \nstandard. But internally, it converts that into one single command line.\n\nIn corner cases, you find problems with that.\n\nHth,\nDscho\n"},{"id":"55800","messageId":"20071015000347.GA13033@old.davidb.org","threadId":"10283","inReplyTo":"023101c80eb5$e3b6b310$2e08a8c0@CAM.ARTIMI.COM","subject":"Re: Switching from CVS to GIT","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-10-15T00:03:47Z","receivedAt":"2007-10-15T00:03:47Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Sun, Oct 14, 2007 at 11:59:35PM +0100, Dave Korn wrote:\n>On 14 October 2007 23:15, Alex Riesen wrote:\n>\n>> Interprocess communication:\n>> \n>> - it has only one argument (limited in size) passed to started\n>> programs, which means that there is no possible way to safely pass\n>> file and text arguments on command line (more than one, that is)\n>\n> Whuh?\n>\n>http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx\n\nThe MS exec* calls just concatenate all of the argv arguments, separating\nthem with a space into a single buffer.\n\nLook at the general _exec* page:\n\n http://msdn2.microsoft.com/en-us/library/431x4c1w(VS.80).aspx\n\nand read the first \"Note\" section.\n\nIf you know what the library on the other end is doing to re-parse the\narguments back into separate strings, it might be possible to quote things\nenough to handle names with spaces, but it is hard.\n\nDavid\n"},{"id":"55801","messageId":"4712B616.165BBF8D@dessent.net","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150039120.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Brian Dessent","fromEmail":"brian@dessent.net","sentAt":"2007-10-15T00:36:38Z","receivedAt":"2007-10-15T00:36:38Z","isPatch":false,"sender":{"key":"brian@dessent.net","avatar":null},"body":"Johannes Schindelin wrote:\n\n> The problem is that on Windows, you cannot keep a file open and delete it\n> at the same time. This is an issue in Windows' equivalent of VFS.\n> \n> A neat trick to work with temporary files without permission issues is to\n> open the file and delete it right after that. This does not work on\n> Windows.\n\nYou can achieve the same thing on Windows with CreateFile() by setting\nthe dwShareMode parameter to zero and setting the\nFILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This\nresults in a file that cannot be opened or read by any other process and\nthat will be automatically deleted when all open handles are closed.\n\n> I think Alex means this: you can have C:\\a\\b\\c and D:\\a\\b\\c. So depending\n> on which drive you are, you mean one or the other. Just comparing the\n> paths is not enough.\n\nThis just means that you have to consider the drive letter as part of\nthe filename.\n\n> > > - no real \"mmap\" (which kills perfomance and complicates code)\n> >\n> > You only need mmap because you are accustomed to use it on GNU/Linux.\n> \n> Yes. And we rely on the performance very much.\n\nWindows may not call it mmap() but it most certainly has memory-mapped\nfile IO:\n.\n\nBrian\n"},{"id":"55804","messageId":"feud8j$kdg$1@ger.gmane.org","threadId":"10283","inReplyTo":"20071014221446.GC2776@steel.home","subject":"Re: Switching from CVS to GIT","fromName":"Michael Gebetsroither","fromEmail":"gebi@sbox.tugraz.at","sentAt":"2007-10-15T00:46:11Z","receivedAt":"2007-10-15T00:46:11Z","isPatch":false,"sender":{"key":"gebi@sbox.tugraz.at","avatar":"https://gravatar.com/avatar/b3168bab3f94cb1f09343b408b618ff2982aea3c20789c387f6d5c9b3b73999b?d=mp&s=160"},"body":"[\"Followup-To:\" header set to gmane.comp.version-control.git.]\n\n> - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> can be not the same, depending on what current \"drive\" is) and\n> multi-cwd, which hasn't had formed itself into a problem yet, but\n> surely will\n\nThats true for linux too.\n/a/b/c and /a/b/c can be 2 totally different files depending on the vfs\nnamespace you are one.\n\ncu,\nmichael\n-- \nIt's already too late!\n"},{"id":"55802","messageId":"Pine.LNX.4.64.0710150217120.25221@racer.site","threadId":"10283","inReplyTo":"4712B616.165BBF8D@dessent.net","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T01:22:53Z","receivedAt":"2007-10-15T01:22:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Oct 2007, Brian Dessent wrote:\n\n> Johannes Schindelin wrote:\n> \n> > The problem is that on Windows, you cannot keep a file open and delete \n> > it at the same time. This is an issue in Windows' equivalent of VFS.\n> > \n> > A neat trick to work with temporary files without permission issues is \n> > to open the file and delete it right after that. This does not work \n> > on Windows.\n> \n> You can achieve the same thing on Windows with CreateFile() by setting \n> the dwShareMode parameter to zero and setting the \n> FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This \n> results in a file that cannot be opened or read by any other process and \n> that will be automatically deleted when all open handles are closed.\n\nAha. So to support Windows, we have to wrap all sites that use that \ntrick, and special case that #ifdef __MINGW32__. \n\n> > I think Alex means this: you can have C:\\a\\b\\c and D:\\a\\b\\c. So \n> > depending on which drive you are, you mean one or the other. Just \n> > comparing the paths is not enough.\n> \n> This just means that you have to consider the drive letter as part of \n> the filename.\n\nSo to support Windows, we have to special case having a \":\" as second \ncharacter in the filename.\n\n> > > > - no real \"mmap\" (which kills perfomance and complicates code)\n> > >\n> > > You only need mmap because you are accustomed to use it on GNU/Linux.\n> > \n> > Yes. And we rely on the performance very much.\n> \n> Windows may not call it mmap() but it most certainly has memory-mapped\n> file IO:\n> .\n\nYes, but there are still incompatibilities with POSIX. Again, when you \ndid not close the file, you cannot delete (or rename) it. So, to support \nWindows, ...\n\nAll this supporting Windows business is certainly possible, if tedious.\n\nCiao,\nDscho\n"},{"id":"55803","messageId":"Pine.LNX.4.64.0710150223230.25221@racer.site","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150217120.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T01:24:53Z","receivedAt":"2007-10-15T01:24:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Johannes Schindelin wrote:\n\n> All this supporting Windows business is certainly possible, if tedious.\n\nTo clarify: git works on Windows. Most of the time, that is. But all \nthose changes that were necessary to go there have not yet found their way \ninto the official git.git repository.\n\nCiao,\nDscho\n"},{"id":"55808","messageId":"u6419ja25.fsf@gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150039120.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T04:06:42Z","receivedAt":"2007-10-15T04:06:42Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Alex Riesen , ae@op5.se, tsuna@lrde.epita.fr, \n> git@vger.kernel.org, make-w32@gnu.org\n> \n> The problem is that on Windows, you cannot keep a file open and delete it \n> at the same time.\n\nThat is no longer true, for quite some time. NT4 and later versions\nsupport that almost exactly like Posix filesystems.\n\n> > > - no acceptable level of performance in filesystem and VFS (readdir,\n> > > stat, open and read/write are annoyingly slow)\n> > \n> > With what libraries? Native `stat' and `readdir' are quite fast. \n> > Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed \n> > painfully slow, but then you don't need to use it.\n> \n> No, native.\n> \n> Once you experienced the performance of git on Linux, then rebooted into \n> Windows on the same box, you will grow a beard while waiting for trivial \n> operations.\n\nMaybe GIT assumes too much about `readdir' and `stat', and should\nrefactor its code into better abstractions.\n\n> > > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> > > can be not the same, depending on what current \"drive\" is)\n> > \n> > So what? on Unix \"a/b/c\" can be not the same. Both cases are simply not \n> > complete file names, that's all. No one said there must be a single \n> > root for all volumes, it's the Posix jingoism creeping in again.\n> \n> I think Alex means this: you can have C:\\a\\b\\c and D:\\a\\b\\c. So depending \n> on which drive you are, you mean one or the other. Just comparing the \n> paths is not enough.\n\nWhat _I_ meant is that the C: part is part of the full file name,\nexactly like the leading / is on Unix.\n\n> > > - No real \"mmap\" (which kills perfomance and complicates code)\n> > \n> > You only need mmap because you are accustomed to use it on GNU/Linux.\n> \n> Yes. And we rely on the performance very much.\n\nThere's no need for mmap to get memory performance, except if sbrk and\nfriends are too slow.\n"},{"id":"55810","messageId":"u4pgtj9rs.fsf@gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150217120.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T04:12:55Z","receivedAt":"2007-10-15T04:12:55Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 02:22:53 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Eli Zaretskii , Alex Riesen , ae@op5.se, \n> tsuna@lrde.epita.fr, make-w32@gnu.org\n> \n> > You can achieve the same thing on Windows with CreateFile() by setting \n> > the dwShareMode parameter to zero and setting the \n> > FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This \n> > results in a file that cannot be opened or read by any other process and \n> > that will be automatically deleted when all open handles are closed.\n> \n> Aha. So to support Windows, we have to wrap all sites that use that \n> trick, and special case that #ifdef __MINGW32__. \n\nNo, you need to think in abstractions rather than POSIX-isms, and then\nlet each platform implement those abstractions as appropriate.\n\n> > > I think Alex means this: you can have C:\\a\\b\\c and D:\\a\\b\\c. So \n> > > depending on which drive you are, you mean one or the other. Just \n> > > comparing the paths is not enough.\n> > \n> > This just means that you have to consider the drive letter as part of \n> > the filename.\n> \n> So to support Windows, we have to special case having a \":\" as second \n> character in the filename.\n\nNo, you need to think abstractions like `absolute_file_name' and\n`dir_separator'.\n\n> > > > > - no real \"mmap\" (which kills perfomance and complicates code)\n> > > >\n> > > > You only need mmap because you are accustomed to use it on GNU/Linux.\n> > > \n> > > Yes. And we rely on the performance very much.\n> > \n> > Windows may not call it mmap() but it most certainly has memory-mapped\n> > file IO:\n> > .\n> \n> Yes, but there are still incompatibilities with POSIX.\n\nStop thinking POSIX. Think abstractions that are common to POSIX and\nnon-POSIX systems. If you think POSIX, don't be surprised that it\nwon't port.\n\n> Again, when you did not close the file, you cannot delete (or\n> rename) it.\n\nYes, you can, nowadays. But that doesn't mean it was TRT to use such\ndirty tricks to implement temporary files or security. One needs to\nthink in abstractions again, and leave the implementation to each\nplatform.\n\n> All this supporting Windows business is certainly possible, if tedious.\n\nOnly if the program was written with disregard to anything but POSIX.\n"},{"id":"55814","messageId":"46a038f90710142235i6d7e39c4qdb5d33941352e1aa@mail.gmail.com","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710141916510.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-10-15T05:35:22Z","receivedAt":"2007-10-15T05:35:22Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/15/07, Johannes Schindelin wrote:\n> There is msysGit. This project is nearing to its first beta, being\n> self-hosted since mid-August IIRC.\n\nI've been using it recently, I have to say it's pretty impressive -\nyou can use it from cmd.com or from a bash window (courtesy of the\nmsys environment included). The GUIs that ship with git are there\n(git-gui, gitk).\n\nI use gitk extensively, and it works *great*. My work-style is of a\nshell window for status/diff/commit actions and one or more gitk\nwindows for browsing of proj history. You can use git-gui for a visual\nstatus/git/commit workflow, or qgit. qgit is more integrated, and\nmight feel more \"at home\" for users that expect something more\nMDI-ish.\n\ncheers.\n\n\nmartin\n"},{"id":"55815","messageId":"46a038f90710142243s7d07d9f8td6c5c24383e135f3@mail.gmail.com","threadId":"10283","inReplyTo":"47126957.1020204@op5.se","subject":"Re: Switching from CVS to GIT","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-10-15T05:43:54Z","receivedAt":"2007-10-15T05:43:54Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/15/07, Andreas Ericsson wrote:\n> > And I have to disagree strongly with the \"black\": In msysGit (which brings\n> > its own minimal version of MSys), it is very smooth.\n> >\n>\n> Oh? I didn't know that. Windows and its unixifying toolboxes is unknown\n> territory to me, as I happily spend all my time on various unices.\n\nI'm a unix-head too. Last couple of weeks had to work on a windows\nserver, and installed msysGit. Very impressed - all the needed\ndependencies are there, from an end-user POV it \"just works\".\n\n> I was under the impression that the windows port suffers from Windows'\n> lack of a proper fork() and friends and that a proper library would\n> help solving those problems. Perhaps I was misinformed.\n\nI think msys' DLLs might be doing what cygwin does, an emulated fork.\n\nA quite surprising thing is that msysgit manages to be very fast. Not\nas fast as the same git, same hw running on a recent Linux, but pretty\nusable fast for a tree with a few thousand files. Earlier/other git\nports to win32 are pretty slow (still faster than svn and friends, but\nslooow).\n\ncheers,\n\n\nm\n"},{"id":"55816","messageId":"E1IhIwR-0006be-Ki@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150039120.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T05:56:39Z","receivedAt":"2007-10-15T05:56:39Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Alex Riesen , ae@op5.se, tsuna@lrde.epita.fr, \n> git@vger.kernel.org, make-w32@gnu.org\n> \n> The problem is not so much opening, but determining if an existing file \n> and a file in the index have the same name.\n> \n> For example, \"README\" in the index, but \"readme\" in the working directory, \n> will be handled as \"deleted/untracked\" by the current machinery. IOW git \n> will not know that what it gets from readdir() as \"readme\" really is the \n> same file as \"README\" in the index.\n\nThat's because you think file names are simple strings and can be\ncompared by simple string comparison. This naìve view is not true\neven on POSIX systems: \"foo/bar\" and \"/a/b/foo/bar\" can be the same\nfile, as well as \"/a/b/c/d\" and \"/x/y/z\", given the right symlinks.\nBut for some reason that eludes me, people who are accustomed to POSIX\nstop right there and in effect say \"file names are strings, if we only\nmake them absolute and resolve links\". Instead, recognize that file\nnames are not strings (although they inherit some of the strings'\ntraits), and think in terms of \"file-name comparison\" abstraction;\nthen everything will fall in place just fine.\n\n> > > - no acceptable level of performance in filesystem and VFS (readdir,\n> > > stat, open and read/write are annoyingly slow)\n> > \n> > With what libraries? Native `stat' and `readdir' are quite fast. \n> > Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed \n> > painfully slow, but then you don't need to use it.\n> \n> No, native.\n\nCan you show a test case where this penalty is clearly visible? I'm\ncurious to see the numbers. TIA\n"},{"id":"55818","messageId":"E1IhJ4K-00086x-5U@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150223230.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T06:04:48Z","receivedAt":"2007-10-15T06:04:48Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 02:24:53 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Eli Zaretskii , Alex Riesen , ae@op5.se, \n> tsuna@lrde.epita.fr, make-w32@gnu.org\n> \n> To clarify: git works on Windows. Most of the time, that is. But all \n> those changes that were necessary to go there have not yet found their way \n> into the official git.git repository.\n\nI, for one, appreciate all the hard work invested in that.\n\nWhile we are at that: can you (or someone else) point me to\ninstructions on how to build the MinGW port of GIT? I found a tarball\nof the MinGW-ported GIT (v1.5.3, I think), but what I don't seem to be\nable to find is some kind of HOWTO: what tools I need to have\ninstalled, how to configure them (if there are any special issues\nthere), what command(s) to type, etc. Is there anything like that out\nthere, or can someone post such instructions?\n\nTIA\n"},{"id":"55819","messageId":"E1IhJ7T-0008AC-8b@fencepost.gnu.org","threadId":"10283","inReplyTo":"20071015000347.GA13033@old.davidb.org","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T06:08:03Z","receivedAt":"2007-10-15T06:08:03Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Sun, 14 Oct 2007 17:03:47 -0700\n> From: David Brown \n> Cc: 'Andreas Ericsson' , 'Alex Riesen' ,\n> \t'git list' ,\n> \t'Johannes Schindelin' ,\n> \t'Make Windows' \n> \n> The MS exec* calls just concatenate all of the argv arguments, separating\n> them with a space into a single buffer.\n\nTrue.\n\n> If you know what the library on the other end is doing to re-parse the\n> arguments back into separate strings, it might be possible to quote things\n> enough to handle names with spaces, but it is hard.\n\nIt's not hard, it's just a bit of work. And it needs to be done\nexactly once.\n"},{"id":"55821","messageId":"47130B25.4010304@viscovery.net","threadId":"10283","inReplyTo":"1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-15T06:39:33Z","receivedAt":"2007-10-15T06:39:33Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Benoit SIGOURE schrieb:\n> Context: GNU make seems to be willing to switch from CVS to ... \n> something else.\n> \n> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:\n> \n>> [...] the big thing no one else seems to have addressed much in\n>> other discussions I've seen is portability. It LOOKS like there are\n>> native ports of GIT to MINGW, but I have no idea how complete and usable\n>> they are. If someone who has a Windows system could look into that it\n>> would be a big help.\n> \n> I think the best thing to do is to ask directly on the Git ML.\n> \n> Someone already pointed out that he'd like to use Git on Windows but \n> doesn't want to install either Cygwin or MSYS. Is this possible, or \n> will it be possible in the near future? Is it possible to use one of \n> the various GUIs (git-gui, gitk, qgit) on Windows without requiring a \n> POSIXish shell etc.?\n\nFWIW, I'm using the MinGW port from cmd.exe, i.e. not from a posix shell, on \na *production* repository. gitk and git-gui work. Not all operations that I \nregularly use are available[*] via the GUIs, like git-rebase or \nnon-fast-forwarding push, so the use of the command line is needed from time \nto time.\n\nUnfortunately, \"Fetch\" does not yet work[*] from within git-gui, so you have \nto fall back to git-fetch on the command line.\n\nOf course, the Posix toolset, including a shell, must still be installed \n(and in my setup they are in the PATH), but you don't have to use it.\n\n[*] Note the distinction between \"not available\" and \"does not work\".\n\n-- Hannes\n"},{"id":"55827","messageId":"AD60F584-7AAD-4083-9BA6-21F0D00D6D1D@zib.de","threadId":"10283","inReplyTo":"E1IhJ4K-00086x-5U@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-15T07:56:40Z","receivedAt":"2007-10-15T07:56:40Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 15, 2007, at 8:04 AM, Eli Zaretskii wrote:\n\n>> Date: Mon, 15 Oct 2007 02:24:53 +0100 (BST)\n>> From: Johannes Schindelin \n>> cc: Eli Zaretskii , Alex Riesen \n>> , ae@op5.se,\n>> tsuna@lrde.epita.fr, make-w32@gnu.org\n>>\n>> To clarify: git works on Windows. Most of the time, that is. But \n>> all\n>> those changes that were necessary to go there have not yet found \n>> their way\n>> into the official git.git repository.\n>\n> I, for one, appreciate all the hard work invested in that.\n>\n> While we are at that: can you (or someone else) point me to\n> instructions on how to build the MinGW port of GIT? I found a tarball\n> of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem to be\n> able to find is some kind of HOWTO: what tools I need to have\n> installed, how to configure them (if there are any special issues\n> there), what command(s) to type, etc. Is there anything like that out\n> there, or can someone post such instructions?\n\nIf you want to have a full working development environment, such that\nyou can start contributing to msysgit right away, and have no firewall\nissues, go to\n\n\thttp://code.google.com/p/msysgit/\n\nand install GitMe, currently\n\n\thttp://msysgit.googlecode.com/files/GitMe-0.4.2.exe\n\nIf you only care about an end-user setup, which contains only the git\nbinaries on your system, but no tools to compile them, stay tuned for\none or two days. We'll release an updated installer soon.\n\n\tSteffen\n"},{"id":"55829","messageId":"E1IhLBW-0006uw-19@fencepost.gnu.org","threadId":"10283","inReplyTo":"AD60F584-7AAD-4083-9BA6-21F0D00D6D1D@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T08:20:22Z","receivedAt":"2007-10-15T08:20:22Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Cc: Johannes Schindelin , git@vger.kernel.org,\n> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org\n> From: Steffen Prohaska \n> Date: Mon, 15 Oct 2007 09:56:40 +0200\n> \n> > While we are at that: can you (or someone else) point me to\n> > instructions on how to build the MinGW port of GIT? I found a tarball\n> > of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem to be\n> > able to find is some kind of HOWTO: what tools I need to have\n> > installed, how to configure them (if there are any special issues\n> > there), what command(s) to type, etc. Is there anything like that out\n> > there, or can someone post such instructions?\n> \n> If you want to have a full working development environment, such that\n> you can start contributing to msysgit right away, and have no firewall\n> issues, go to\n> \n> \thttp://code.google.com/p/msysgit/\n> \n> and install GitMe, currently\n> \n> \thttp://msysgit.googlecode.com/files/GitMe-0.4.2.exe\n> \n> If you only care about an end-user setup, which contains only the git\n> binaries on your system, but no tools to compile them, stay tuned for\n> one or two days. We'll release an updated installer soon.\n\nSorry I wasn't clear: I want neither. I don't think I will have\nenough free time to become an active contributor to GIT any time\nsoon. OTOH, since binaries are not available (and I'd prefer a\ntarball as opposed to an installer, to be more in control of what's\nbeing installed and where), I asked about the development tools\n(compiler and Binutils, obviously, but what else?) required to build\nthe source tarball with MinGW tools.\n\nDo I understand correctly that building GIT currently requires MSYS?\nThat'd be unfortunate, at least for me.\n\nAnyway, thanks for replying.\n"},{"id":"55830","messageId":"Pine.LNX.4.64.0710150932560.25221@racer.site","threadId":"10283","inReplyTo":"u4pgtj9rs.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T08:34:03Z","receivedAt":"2007-10-15T08:34:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Eli Zaretskii wrote:\n\n> No, you need to think in abstractions rather than POSIX-isms, and then \n> let each platform implement those abstractions as appropriate.\n\nLast time I checked, POSIX was already an abstraction, thankyouverymuch.\n\nAnyway, this discussion gets out of hand. The question was: does Git work \non Windows natively, and the answer as far as you are concerned is: yes.\n\nCiao,\nDscho\n"},{"id":"55832","messageId":"Pine.LNX.4.64.0710150936070.25221@racer.site","threadId":"10283","inReplyTo":"E1IhIwR-0006be-Ki@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T08:44:12Z","receivedAt":"2007-10-15T08:44:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)\n> > From: Johannes Schindelin \n> > cc: Alex Riesen , ae@op5.se, tsuna@lrde.epita.fr, \n> > git@vger.kernel.org, make-w32@gnu.org\n> > \n> > The problem is not so much opening, but determining if an existing file \n> > and a file in the index have the same name.\n> > \n> > For example, \"README\" in the index, but \"readme\" in the working directory, \n> > will be handled as \"deleted/untracked\" by the current machinery. IOW git \n> > will not know that what it gets from readdir() as \"readme\" really is the \n> > same file as \"README\" in the index.\n> \n> That's because you think file names are simple strings and can be\n> compared by simple string comparison.\n\nAlmost...\n\n> This na?ve view is not true even on POSIX systems: \"foo/bar\" and \n> \"/a/b/foo/bar\" can be the same file, as well as \"/a/b/c/d\" and \"/x/y/z\", \n> given the right symlinks.\n\n... not quite, ah ...\n\n> But for some reason that eludes me, people who are accustomed to POSIX\n> stop right there and in effect say \"file names are strings, if we only\n> make them absolute and resolve links\".\n\n... yes! There you have it. Absolute filenames, resolved by readlink() \nare assumed to be the unique (!) identifiers for the contents.\n\n_Note:_ absolute paths _without_ readlink() resolving are _still_ unique \nidentifiers; this time for files/symlinks.\n\nThings like this utter rubbish that two different file names (which are \nthe keys in the keystore that a filesystem really is) make Windows' \nfilesystem operations so slow.\n\nI wonder when Windows heads will realise that this \"convenience\" is just \nanother reason why Windows is easily outperformed by other OSes (yes, the \nlast one is a plural).\n\n> > > > - no acceptable level of performance in filesystem and VFS \n> > > > (readdir, stat, open and read/write are annoyingly slow)\n> > > \n> > > With what libraries? Native `stat' and `readdir' are quite fast. \n> > > Perhaps you mean the ported glibc (libgw32c), where `readdir' is \n> > > indeed painfully slow, but then you don't need to use it.\n> > \n> > No, native.\n> \n> Can you show a test case where this penalty is clearly visible? I'm \n> curious to see the numbers. TIA\n\nNo, I cannot. I will not go and buy a copy of Windows just to show you \nthe numbers.\n\nSince quite some time I only run Linux on my machine(s), and the reason \nwas a very unscientific experiment: I kept with the OS that did not freeze \nand let me do nothing for more than one second.\n\nNow, that is my _personal_ decision. If _you_ have no problem with \nWindows, just stick with it. (I always thought this goes without saying, \nbut Windows users tend to be very religious about this issue, thinking \njust because I hate Windows that I want to make them switch. Hahaha, no.)\n\nCiao,\nDscho\n"},{"id":"55833","messageId":"Pine.LNX.4.64.0710150946500.25221@racer.site","threadId":"10283","inReplyTo":"E1IhLBW-0006uw-19@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T08:47:25Z","receivedAt":"2007-10-15T08:47:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Eli Zaretskii wrote:\n\n> Do I understand correctly that building GIT currently requires MSYS? \n> That'd be unfortunate, at least for me.\n\nIf you could make Git compile with Visual C++, that would be fabulous.\n\nTIA,\nDscho\n"},{"id":"55851","messageId":"86k5popxhp.fsf@lola.quinscape.zz","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150936070.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-15T08:56:18Z","receivedAt":"2007-10-15T08:56:18Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n>\n>> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)\n>> > From: Johannes Schindelin \n>> > cc: Alex Riesen , ae@op5.se, tsuna@lrde.epita.fr, \n>> > git@vger.kernel.org, make-w32@gnu.org\n>> > \n>> > The problem is not so much opening, but determining if an existing file \n>> > and a file in the index have the same name.\n>> > \n>> > For example, \"README\" in the index, but \"readme\" in the working directory, \n>> > will be handled as \"deleted/untracked\" by the current machinery. IOW git \n>> > will not know that what it gets from readdir() as \"readme\" really is the \n>> > same file as \"README\" in the index.\n>> \n>> That's because you think file names are simple strings and can be\n>> compared by simple string comparison.\n>\n> Almost...\n>\n>> This na?ve view is not true even on POSIX systems: \"foo/bar\" and \n>> \"/a/b/foo/bar\" can be the same file, as well as \"/a/b/c/d\" and \"/x/y/z\", \n>> given the right symlinks.\n>\n> ... not quite, ah ...\n>\n>> But for some reason that eludes me, people who are accustomed to POSIX\n>> stop right there and in effect say \"file names are strings, if we only\n>> make them absolute and resolve links\".\n>\n> ... yes! There you have it. Absolute filenames, resolved by\n> readlink() are assumed to be the unique (!) identifiers for the\n> contents.\n\nThey aren't. One can mount the same file system several times in\ndifferent places. In Linux, one can even mount directories and files\nto several places at once. Most Unices also support some\ncase-insensitive file systems, and readlink does not canonicalize the\ncasing.\n\n> _Note:_ absolute paths _without_ readlink() resolving are _still_\n> unique identifiers; this time for files/symlinks.\n\nNot even that. A unique identifier for files would imply that\ntouching the file does not affect, say, the access times of files with\nother unique identifiers.\n\n-- \nDavid Kastrup\n"},{"id":"55834","messageId":"86d4vgpxew.fsf@lola.quinscape.zz","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150936070.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-15T08:57:59Z","receivedAt":"2007-10-15T08:57:59Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n>\n>> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)\n>> > From: Johannes Schindelin \n>> > cc: Alex Riesen , ae@op5.se, tsuna@lrde.epita.fr, \n>> > git@vger.kernel.org, make-w32@gnu.org\n>> > \n>> > The problem is not so much opening, but determining if an existing file \n>> > and a file in the index have the same name.\n>> > \n>> > For example, \"README\" in the index, but \"readme\" in the working directory, \n>> > will be handled as \"deleted/untracked\" by the current machinery. IOW git \n>> > will not know that what it gets from readdir() as \"readme\" really is the \n>> > same file as \"README\" in the index.\n>> \n>> That's because you think file names are simple strings and can be\n>> compared by simple string comparison.\n>\n> Almost...\n>\n>> This na?ve view is not true even on POSIX systems: \"foo/bar\" and \n>> \"/a/b/foo/bar\" can be the same file, as well as \"/a/b/c/d\" and \"/x/y/z\", \n>> given the right symlinks.\n>\n> ... not quite, ah ...\n>\n>> But for some reason that eludes me, people who are accustomed to POSIX\n>> stop right there and in effect say \"file names are strings, if we only\n>> make them absolute and resolve links\".\n>\n> ... yes! There you have it. Absolute filenames, resolved by\n> readlink() are assumed to be the unique (!) identifiers for the\n> contents.\n\nThey aren't. One can mount the same file system several times in\ndifferent places. In Linux, one can even mount directories and files\nto several places at once. Most Unices also support some\ncase-insensitive file systems, and readlink does not canonicalize the\ncasing.\n\n> _Note:_ absolute paths _without_ readlink() resolving are _still_\n> unique identifiers; this time for files/symlinks.\n\nNot even that. A unique identifier for files would imply that\ntouching the file does not affect, say, the access times of files with\nother unique identifiers.\n\n-- \nDavid Kastrup\n"},{"id":"55835","messageId":"DB8BA238-B1E3-48F2-AF90-A81BD0CD6A5F@lrde.epita.fr","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150932560.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Benoit SIGOURE","fromEmail":"tsuna@lrde.epita.fr","sentAt":"2007-10-15T09:02:54Z","receivedAt":"2007-10-15T09:02:54Z","isPatch":false,"sender":{"key":"tsunanet@gmail.com","avatar":"https://avatars.githubusercontent.com/u/128281?v=4"},"body":"On Oct 15, 2007, at 10:34 AM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n>\n>> No, you need to think in abstractions rather than POSIX-isms, and \n>> then\n>> let each platform implement those abstractions as appropriate.\n>\n> Last time I checked, POSIX was already an abstraction, \n> thankyouverymuch.\n\nBut as Eli pointed out, it's not universal, so you need higher \nabstractions on top of them.\n\n> Anyway, this discussion gets out of hand.\n\nNot at all, actually I think some interesting points were made, \nincluding on the technical side of the thing.\n\n-- \nBenoit Sigoure aka Tsuna\nEPITA Research and Development Laboratory\n\n\n"},{"id":"55837","messageId":"E45D25D3-F37A-49BE-8B83-B4567322D41D@zib.de","threadId":"10283","inReplyTo":"E1IhLBW-0006uw-19@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-15T09:23:37Z","receivedAt":"2007-10-15T09:23:37Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 15, 2007, at 10:20 AM, Eli Zaretskii wrote:\n\n>> Cc: Johannes Schindelin , \n>> git@vger.kernel.org,\n>> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make- \n>> w32@gnu.org\n>> From: Steffen Prohaska \n>> Date: Mon, 15 Oct 2007 09:56:40 +0200\n>>\n>>> While we are at that: can you (or someone else) point me to\n>>> instructions on how to build the MinGW port of GIT? I found a \n>>> tarball\n>>> of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem \n>>> to be\n>>> able to find is some kind of HOWTO: what tools I need to have\n>>> installed, how to configure them (if there are any special issues\n>>> there), what command(s) to type, etc. Is there anything like \n>>> that out\n>>> there, or can someone post such instructions?\n>>\n>> If you want to have a full working development environment, such that\n>> you can start contributing to msysgit right away, and have no \n>> firewall\n>> issues, go to\n>>\n>> \thttp://code.google.com/p/msysgit/\n>>\n>> and install GitMe, currently\n>>\n>> \thttp://msysgit.googlecode.com/files/GitMe-0.4.2.exe\n>>\n>> If you only care about an end-user setup, which contains only the git\n>> binaries on your system, but no tools to compile them, stay tuned for\n>> one or two days. We'll release an updated installer soon.\n>\n> Sorry I wasn't clear: I want neither. I don't think I will have\n> enough free time to become an active contributor to GIT any time\n> soon. OTOH, since binaries are not available (and I'd prefer a\n> tarball as opposed to an installer, to be more in control of what's\n> being installed and where),\n\nOk, so I uploaded the most recent preview of the installer to\n\nhttp://msysgit.googlecode.com/files/WinGit-1.5.3-preview20071010.exe\n\nNote, we're about to release an updated version soon. Personally,\nI don't plan to put work in providing tar balls. A working installer\nhas higher priority for me.\n\n\n> I asked about the development tools\n> (compiler and Binutils, obviously, but what else?) required to build\n> the source tarball with MinGW tools.\n>\n> Do I understand correctly that building GIT currently requires MSYS?\n> That'd be unfortunate, at least for me.\n\nmsysgit's GitMe contains all tools from MSYS required to build git.\nIt also clones the git source and compiles it. It doesn't install\nanything outside the folder that you chose upon installation.\n\nI strongly believe it is the easiest way to compile git from source.\n\n\tSteffen\n"},{"id":"55845","messageId":"47133DEC.6020600@op5.se","threadId":"10283","inReplyTo":"E1IhJ7T-0008AC-8b@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-15T10:16:12Z","receivedAt":"2007-10-15T10:16:12Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Eli Zaretskii wrote:\n> \n>> If you know what the library on the other end is doing to re-parse the\n>> arguments back into separate strings, it might be possible to quote things\n>> enough to handle names with spaces, but it is hard.\n> \n> It's not hard, it's just a bit of work. And it needs to be done\n> exactly once.\n\nBefore someone beats me to it: \"Patches welcome\" ;-)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55847","messageId":"4713431C.7030103@viscovery.net","threadId":"10283","inReplyTo":"47133DEC.6020600@op5.se","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-15T10:38:20Z","receivedAt":"2007-10-15T10:38:20Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Andreas Ericsson schrieb:\n> Eli Zaretskii wrote:\n>>\n>>> If you know what the library on the other end is doing to re-parse the\n>>> arguments back into separate strings, it might be possible to quote \n>>> things\n>>> enough to handle names with spaces, but it is hard.\n>>\n>> It's not hard, it's just a bit of work. And it needs to be done\n>> exactly once.\n> \n> Before someone beats me to it: \"Patches welcome\" ;-)\n\nLet others do the research for you, hm?\n\nhttp://repo.or.cz/w/git/mingw.git?a=blob;f=compat/mingw.c;h=2554f19765da5709b787e873da225c59f9d22bb7;hb=HEAD#l306\n\n-- Hannes\n"},{"id":"55849","messageId":"47134656.4070707@op5.se","threadId":"10283","inReplyTo":"4713431C.7030103@viscovery.net","subject":"Re: Switching from CVS to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-15T10:52:06Z","receivedAt":"2007-10-15T10:52:06Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Sixt wrote:\n> Andreas Ericsson schrieb:\n>> Eli Zaretskii wrote:\n>>>\n>>>> If you know what the library on the other end is doing to re-parse the\n>>>> arguments back into separate strings, it might be possible to quote \n>>>> things\n>>>> enough to handle names with spaces, but it is hard.\n>>>\n>>> It's not hard, it's just a bit of work. And it needs to be done\n>>> exactly once.\n>>\n>> Before someone beats me to it: \"Patches welcome\" ;-)\n> \n> Let others do the research for you, hm?\n> \n> http://repo.or.cz/w/git/mingw.git?a=blob;f=compat/mingw.c;h=2554f19765da5709b787e873da225c59f9d22bb7;hb=HEAD#l306 \n> \n\nYup. Although it was more in the nature of \"whoever wrote it surely knows\nhe/she did it and where to find the patch\", so I expect this wasn't much\nof a timesink for you. My apologies if I was incorrect.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55852","messageId":"E1IhNmZ-0002UD-3c@fencepost.gnu.org","threadId":"10283","inReplyTo":"E45D25D3-F37A-49BE-8B83-B4567322D41D@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T11:06:47Z","receivedAt":"2007-10-15T11:06:47Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Cc: Johannes.Schindelin@gmx.de, git@vger.kernel.org, raa.lkml@gmail.com,\n> ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org\n> From: Steffen Prohaska \n> Date: Mon, 15 Oct 2007 11:23:37 +0200\n> \n> Ok, so I uploaded the most recent preview of the installer to\n> \n> http://msysgit.googlecode.com/files/WinGit-1.5.3-preview20071010.exe\n\nThanks!\n\n> Note, we're about to release an updated version soon. Personally,\n> I don't plan to put work in providing tar balls. A working installer\n> has higher priority for me.\n\nFair enough.\n\n> msysgit's GitMe contains all tools from MSYS required to build git.\n> It also clones the git source and compiles it. It doesn't install\n> anything outside the folder that you chose upon installation.\n> \n> I strongly believe it is the easiest way to compile git from source.\n\nOkay, thanks a lot for the info.\n"},{"id":"55853","messageId":"E1IhNox-0004n2-N5@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150946500.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T11:09:15Z","receivedAt":"2007-10-15T11:09:15Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 09:47:25 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Steffen Prohaska , git@vger.kernel.org, \n> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org\n> \n> If you could make Git compile with Visual C++, that would be fabulous.\n\nI prefer GCC (the MinGW port), but without the MSYS ports of\nadditional tools. I use the GnuWin32 ports augmented by some of my\nown (where GnuWin32 ports are buggy or terribly slow).\n"},{"id":"55854","messageId":"029801c80f1c$cb065570$2e08a8c0@CAM.ARTIMI.COM","threadId":"10283","inReplyTo":"4713431C.7030103@viscovery.net","subject":"RE: Switching from CVS to GIT","fromName":"Dave Korn","fromEmail":"dave.korn@artimi.com","sentAt":"2007-10-15T11:16:11Z","receivedAt":"2007-10-15T11:16:11Z","isPatch":false,"sender":{"key":"dave.korn@artimi.com","avatar":null},"body":"On 15 October 2007 11:38, Johannes Sixt wrote:\n\n> http://repo.or.cz/w/git/mingw.git?a=blob;f=compat/mingw.c;h=2554f19765da5709b787e873da225c59f9d22bb7;hb=HEAD#l306\n> \n> -- Hannes\n\n\n 291 /* Thanks, Bill. You'll burn in hell for that. */\n\n\n ;-)\n\n\n cheers,\n DaveK\n-- \nCan't think of a witty .sigline today....\n"},{"id":"55857","messageId":"47135D85.50701@viscovery.net","threadId":"10283","inReplyTo":"E1IhNox-0004n2-N5@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-15T12:31:01Z","receivedAt":"2007-10-15T12:31:01Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Eli Zaretskii schrieb:\n>> Date: Mon, 15 Oct 2007 09:47:25 +0100 (BST)\n>> From: Johannes Schindelin \n>> cc: Steffen Prohaska , git@vger.kernel.org, \n>> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org\n>>\n>> If you could make Git compile with Visual C++, that would be fabulous.\n> \n> I prefer GCC (the MinGW port), but without the MSYS ports of\n> additional tools. I use the GnuWin32 ports augmented by some of my\n> own (where GnuWin32 ports are buggy or terribly slow).\n\nThey should work, too. If a tool is missing, ought to notice it soon enough.\n\nThese are important to note, though:\n\n- The tools must not do their own LF->CRLF conversion when they are used in \na pipeline, \"just because they know it better\".\n\n- GNU tar is needed (in the cpio emulator).\n\n- ln must be able to create hard links on NTFS or do the equivalent of\ncp -p\n\n- GNU cp -al will be needed and should create hard links on NTFS. (I plan to \nuse it for local clones in place of cpio -pl.)\n\nAny feedback on how git works for you with these tools is appreciated.\n\n-- Hannes\n"},{"id":"55858","messageId":"E1IhPCo-0004ZO-N9@fencepost.gnu.org","threadId":"10283","inReplyTo":"47135D85.50701@viscovery.net","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T12:37:58Z","receivedAt":"2007-10-15T12:37:58Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 14:31:01 +0200\n> From: Johannes Sixt \n> Cc: Johannes Schindelin ,\n> \tprohaska@zib.de, make-w32@gnu.org, raa.lkml@gmail.com, ae@op5.se,\n> \tgit@vger.kernel.org\n> \n> > I prefer GCC (the MinGW port), but without the MSYS ports of\n> > additional tools. I use the GnuWin32 ports augmented by some of my\n> > own (where GnuWin32 ports are buggy or terribly slow).\n> \n> They should work, too. If a tool is missing, ought to notice it soon enough.\n> \n> These are important to note, though:\n> \n> - The tools must not do their own LF->CRLF conversion when they are used in \n> a pipeline, \"just because they know it better\".\n> \n> - GNU tar is needed (in the cpio emulator).\n> \n> - ln must be able to create hard links on NTFS or do the equivalent of\n> cp -p\n> \n> - GNU cp -al will be needed and should create hard links on NTFS. (I plan to \n> use it for local clones in place of cpio -pl.)\n> \n> Any feedback on how git works for you with these tools is appreciated.\n\nThanks, I will try.\n"},{"id":"55886","messageId":"20071015173609.GA2966@steel.home","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150059460.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T17:36:09Z","receivedAt":"2007-10-15T17:36:09Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Mon, Oct 15, 2007 02:01:00 +0200:\n> On Sun, 14 Oct 2007, Dave Korn wrote:\n> > On 14 October 2007 23:15, Alex Riesen wrote:\n> > > - it has only one argument (limited in size) passed to started\n> > > programs, which means that there is no possible way to safely pass\n> > > file and text arguments on command line (more than one, that is)\n> > \n> > Whuh?\n> > \n> > http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx\n> \n> It does have an exec() call, yes, since that is required by the C \n> standard. But internally, it converts that into one single command line.\n> \n> In corner cases, you find problems with that.\n> \n\nLike: \"damn, it is just IMPOSSIBLE to implement without them corner\ncases.\"\n"},{"id":"55884","messageId":"20071015173832.GB2966@steel.home","threadId":"10283","inReplyTo":"feud8j$kdg$1@ger.gmane.org","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T17:38:32Z","receivedAt":"2007-10-15T17:38:32Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:\n> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> > can be not the same, depending on what current \"drive\" is) and\n> > multi-cwd, which hasn't had formed itself into a problem yet, but\n> > surely will\n> \n> Thats true for linux too.\n> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs\n> namespace you are one.\n\nNo it is not. A process will always see the same filesystem object\nunder the same path at the any given time (IOW, you can't have many\nnamespaces active at the same time).\n"},{"id":"55890","messageId":"20071015174922.GC2966@steel.home","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150936070.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T17:49:22Z","receivedAt":"2007-10-15T17:49:22Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:\n> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n> > Can you show a test case where this penalty is clearly visible? I'm \n> > curious to see the numbers. TIA\n...\n> Now, that is my _personal_ decision. If _you_ have no problem with \n> Windows, just stick with it. (I always thought this goes without saying, \n> but Windows users tend to be very religious about this issue, thinking \n> just because I hate Windows that I want to make them switch. Hahaha, no.)\n\nThey tend to be so exactly because they know how pathetic they are.\nThey just want to have something where they don't suck and do\neverything to find it. And fail. Then they resort to graphics and\nuser-friendly interface.\n"},{"id":"55891","messageId":"20071015175354.GD2966@steel.home","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150039120.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T17:53:54Z","receivedAt":"2007-10-15T17:53:54Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Mon, Oct 15, 2007 01:45:47 +0200:\n> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n> > Alex Riesen said:\n> > > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> > > can be not the same, depending on what current \"drive\" is)\n> > \n> > So what? on Unix \"a/b/c\" can be not the same. Both cases are simply not \n> > complete file names, that's all. No one said there must be a single \n> > root for all volumes, it's the Posix jingoism creeping in again.\n> \n> I think Alex means this: you can have C:\\a\\b\\c and D:\\a\\b\\c. So depending \n> on which drive you are, you mean one or the other. Just comparing the \n> paths is not enough.\n\nNot really. I meant that \"/a/b/c\" and \"/a/b/c\". Note the leading\nslash. On windoze it is _NOT_ absolute path. It is relative to the\nroot of the current drive.\n"},{"id":"55892","messageId":"20071015175606.GE2966@steel.home","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710150217120.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T17:56:06Z","receivedAt":"2007-10-15T17:56:06Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Mon, Oct 15, 2007 03:22:53 +0200:\n> On Sun, 14 Oct 2007, Brian Dessent wrote:\n> > Johannes Schindelin wrote:\n> > > The problem is that on Windows, you cannot keep a file open and delete \n> > > it at the same time. This is an issue in Windows' equivalent of VFS.\n> > > \n> > > A neat trick to work with temporary files without permission issues is \n> > > to open the file and delete it right after that. This does not work \n> > > on Windows.\n> > \n> > You can achieve the same thing on Windows with CreateFile() by setting \n> > the dwShareMode parameter to zero and setting the \n> > FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This \n> > results in a file that cannot be opened or read by any other process and \n> > that will be automatically deleted when all open handles are closed.\n> \n> Aha. So to support Windows, we have to wrap all sites that use that \n> trick, and special case that #ifdef __MINGW32__. \n\nHe misunderstood. It is not what you meant. You cannot remove the open\nfile. What he talks about is removing the file after it is _closed_.\nJunk.\n"},{"id":"55894","messageId":"030301c80f58$d37b9710$2e08a8c0@CAM.ARTIMI.COM","threadId":"10283","inReplyTo":"20071015174922.GC2966@steel.home","subject":"RE: Switching from CVS to GIT","fromName":"Dave Korn","fromEmail":"dave.korn@artimi.com","sentAt":"2007-10-15T18:25:55Z","receivedAt":"2007-10-15T18:25:55Z","isPatch":false,"sender":{"key":"dave.korn@artimi.com","avatar":null},"body":"On 15 October 2007 18:49, Alex Riesen wrote:\n\n> Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:\n>> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n>>> Can you show a test case where this penalty is clearly visible? I'm\n>>> curious to see the numbers. TIA\n> ...\n>> Now, that is my _personal_ decision. If _you_ have no problem with\n>> Windows, just stick with it. (I always thought this goes without saying,\n>> but Windows users tend to be very religious about this issue, thinking\n>> just because I hate Windows that I want to make them switch. Hahaha, no.)\n> \n> They tend to be so exactly because they know how pathetic they are.\n> They just want to have something where they don't suck and do\n> everything to find it. And fail. Then they resort to graphics and\n> user-friendly interface.\n\n Translation: \"I feel that I am superior to other people. This post has no\ncontent apart from me shooting my mouth off in an attempt to prove how much\ncleverer I am than anyone else. However apart from my self-love I have no\ncontribution to make to the discussion.\"\n\n This isn't slashdot. A computer is just a tool, and it's really *you* who\nare being pathetic, because you confuse a choice of mass-manufactured consumer\nproduct with a statement about personal identity. Loyalty to your favourite\nbrand is a game of one-upmanship suitable only for kids. You need to grow up.\n\n cheers,\n DaveK\n-- \nCan't think of a witty .sigline today....\n"},{"id":"55895","messageId":"1192472978.8299.155.camel@homebase.localnet","threadId":"10283","inReplyTo":"E1IhPCo-0004ZO-N9@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Paul Smith","fromEmail":"psmith@gnu.org","sentAt":"2007-10-15T18:29:38Z","receivedAt":"2007-10-15T18:29:38Z","isPatch":false,"sender":{"key":"psmith@gnu.org","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"OK, enough. I am extremely grateful for the porting and maintenance\nefforts of the GNU make porting team (since I have no Windows--or Amiga,\nor OS/2, or OpenVMS--systems to maintain these ports myself) and I'm not\ngoing to choose a tool unless it supports their environment and helps\nthem to work more efficiently (or at least no less efficiently). I'm\nnot interested in getting into a pissing match over which operating\nsystem is better or worse, and I'm certainly not interested in unfounded\ninferences as to the character and quality of my porting team based on\nthe operating system they are using.\n\nFor those who have provided details and pointers regarding the state of\nGIT on Windows, thank you very much for your help: it's been very useful\nand Eli and others sound like they have enough information to be getting\non with for now. If you'd like to discuss some Windows porting issues\nfurther there are a number of extremely knowledgeable Windows / FLOSS\nprogrammers on the make-w32@gnu.org list--although they are generally\nvery busy.\n\nIf what you're interested in is self-congratulatory back-slapping over\nthe superiority of Linux/POSIX, please keep that on the GIT mailing\nlist, or else an advocacy forum somewhere.\n\n\nI'm setting followups to the GIT list.\n\nCheers all!\n\n-- \n-------------------------------------------------------------------------------\n Paul D. Smith Find some GNU make tips at:\n http://www.gnu.org http://make.mad-scientist.us\n \"Please remain calm...I may be mad, but I am a professional.\" --Mad Scientist\n"},{"id":"55889","messageId":"Pine.LNX.4.64.0710151934380.25221@racer.site","threadId":"10283","inReplyTo":"030301c80f58$d37b9710$2e08a8c0@CAM.ARTIMI.COM","subject":"RE: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T18:34:59Z","receivedAt":"2007-10-15T18:34:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Dave Korn wrote:\n\n> On 15 October 2007 18:49, Alex Riesen wrote:\n> \n> > Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:\n> >> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n> >>> Can you show a test case where this penalty is clearly visible? I'm\n> >>> curious to see the numbers. TIA\n> > ...\n> >> Now, that is my _personal_ decision. If _you_ have no problem with\n> >> Windows, just stick with it. (I always thought this goes without saying,\n> >> but Windows users tend to be very religious about this issue, thinking\n> >> just because I hate Windows that I want to make them switch. Hahaha, no.)\n> > \n> > They tend to be so exactly because they know how pathetic they are. \n> > They just want to have something where they don't suck and do \n> > everything to find it. And fail. Then they resort to graphics and \n> > user-friendly interface.\n> \n> Translation: \"I feel that I am superior to other people. This post \n> has no content apart from me shooting my mouth off in an attempt to \n> prove how much cleverer I am than anyone else. However apart from my \n> self-love I have no contribution to make to the discussion.\"\n> \n> This isn't slashdot. A computer is just a tool, and it's really *you* \n> who are being pathetic, because you confuse a choice of \n> mass-manufactured consumer product with a statement about personal \n> identity. Loyalty to your favourite brand is a game of one-upmanship \n> suitable only for kids. You need to grow up.\n\nI sense a classical Stockholm Syndrome here ;-)\n\nCiao,\nDscho\n"},{"id":"55888","messageId":"4713B367.52CEC7E2@dessent.net","threadId":"10283","inReplyTo":"20071015175606.GE2966@steel.home","subject":"Re: Switching from CVS to GIT","fromName":"Brian Dessent","fromEmail":"brian@dessent.net","sentAt":"2007-10-15T18:37:27Z","receivedAt":"2007-10-15T18:37:27Z","isPatch":false,"sender":{"key":"brian@dessent.net","avatar":null},"body":"Alex Riesen wrote:\n\n> He misunderstood. It is not what you meant. You cannot remove the open\n> file. What he talks about is removing the file after it is _closed_.\n> Junk.\n\nI did not misunderstand. The semantics are equivalent to the POSIX\ncase: you end up with a handle to an open file that is exclusive to that\nprocess (it cannot be opened by any other process, even root) and that\nis automatically reclaimed by the filesystem when all open handles are\nclosed, without any explicit action by the user. It's not \"unlinking an\nopen file\", no, but it's the same result.\n\nBrian\n"},{"id":"55896","messageId":"Pine.LNX.4.64.0710151938300.25221@racer.site","threadId":"10283","inReplyTo":"4713B367.52CEC7E2@dessent.net","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T18:44:08Z","receivedAt":"2007-10-15T18:44:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[excluding make-w32 list as per explicit request]\n\nOn Mon, 15 Oct 2007, Brian Dessent wrote:\n\n> Alex Riesen wrote:\n> \n> > He misunderstood. It is not what you meant. You cannot remove the open\n> > file. What he talks about is removing the file after it is _closed_.\n> > Junk.\n> \n> I did not misunderstand. The semantics are equivalent to the POSIX \n> case: you end up with a handle to an open file that is exclusive to that \n> process (it cannot be opened by any other process, even root) and that \n> is automatically reclaimed by the filesystem when all open handles are \n> closed, without any explicit action by the user. It's not \"unlinking an \n> open file\", no, but it's the same result.\n\nNo, it is not equivalent. For example, you can still see the file. For \nexample, you cannot reuse the filename for another file. And -- the \nkiller -- you cannot remove the directory which contains the file.\n\nBut really, we have workarounds in place to make this a non-issue.\n\nMy bigger concerns are the performance and stability. For example, I had \na very annoying problem on one of the machines I am testing msysGit on. \nThe problem was _only_ fixable by deactivating component of Logitech's \nWebCam driver! Now, if a user-installable 3rd party program can make my \nregular git crash, I am scared what more it can do.\n\nCiao,\nDscho\n"},{"id":"55898","messageId":"4713BA89.633B86F2@dessent.net","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710151938300.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Brian Dessent","fromEmail":"brian@dessent.net","sentAt":"2007-10-15T19:07:53Z","receivedAt":"2007-10-15T19:07:53Z","isPatch":false,"sender":{"key":"brian@dessent.net","avatar":null},"body":"Johannes Schindelin wrote:\n\n> No, it is not equivalent. For example, you can still see the file. For\n> example, you cannot reuse the filename for another file. And -- the\n> killer -- you cannot remove the directory which contains the file.\n\nFair enough. You can move it to another directory in order to delete\nthe containing directory -- this is what Cygwin does to placate posix\napps that expect this to work.\n\n> But really, we have workarounds in place to make this a non-issue.\n\nOk.\n\n> My bigger concerns are the performance and stability. For example, I had\n> a very annoying problem on one of the machines I am testing msysGit on.\n> The problem was _only_ fixable by deactivating component of Logitech's\n> WebCam driver! Now, if a user-installable 3rd party program can make my\n> regular git crash, I am scared what more it can do.\n\nThat is because the MSYS runtime is based on an old version of Cygwin,\nand it uses the same dirty tricks to emulate fork. These tricks rely on\nhaving a repeatably consistent memory layout for a process each time it\nis started, and when third party tools add hooks that affect the load\norder or otherwise screw with the layout, the fork emulation fails. \nThis is also why it is sometimes necessary to assign unique base\naddresses to all libraries (rebaseall) in order to get fork emulation\nworking again.\n\nSo yes, it is unfortunate that some system tools can drastically affect\nthe ability of Cygwin and MSYS to function, but it's what we live with\nto have fork/exec emulation. I see that there is work afoot to abstract\nprocess creation so that hopefully this won't be as much a concern in\nthe near future.\n\nBrian\n"},{"id":"55899","messageId":"85ejfwi3gr.fsf@lola.goethe.zz","threadId":"10283","inReplyTo":"20071015173832.GB2966@steel.home","subject":"Re: Switching from CVS to GIT","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-15T19:26:44Z","receivedAt":"2007-10-15T19:26:44Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Alex Riesen writes:\n\n> Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:\n>> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n>> > can be not the same, depending on what current \"drive\" is) and\n>> > multi-cwd, which hasn't had formed itself into a problem yet, but\n>> > surely will\n>> \n>> Thats true for linux too.\n>> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs\n>> namespace you are one.\n>\n> No it is not. A process will always see the same filesystem object\n> under the same path at the any given time (IOW, you can't have many\n> namespaces active at the same time).\n\ndak@lola:/home/tmp/emacs$ mkdir -p /tmp/a/b\ndak@lola:/home/tmp/emacs$ cd /tmp/a/b\ndak@lola:/tmp/a/b$ sudo mount --bind /usr /tmp/a\nPassword:\ndak@lola:/tmp/a/b$ command pwd\n/tmp/a/b\ndak@lola:/tmp/a/b$ ls -l\ntotal 0\ndak@lola:/tmp/a/b$ ls -l /tmp/a/b\nls: /tmp/a/b: No such file or directory\ndak@lola:/tmp/a/b$ \n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55900","messageId":"Pine.LNX.4.64.0710152026260.25221@racer.site","threadId":"10283","inReplyTo":"4713BA89.633B86F2@dessent.net","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T19:27:38Z","receivedAt":"2007-10-15T19:27:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Brian Dessent wrote:\n\n> Johannes Schindelin wrote:\n> \n> > My bigger concerns are the performance and stability. For example, I \n> > had a very annoying problem on one of the machines I am testing \n> > msysGit on. The problem was _only_ fixable by deactivating component \n> > of Logitech's WebCam driver! Now, if a user-installable 3rd party \n> > program can make my regular git crash, I am scared what more it can \n> > do.\n> \n> That is because the MSYS runtime is based on an old version of Cygwin, \n> and it uses the same dirty tricks to emulate fork. These tricks rely on \n> having a repeatably consistent memory layout for a process each time it \n> is started, and when third party tools add hooks that affect the load \n> order or otherwise screw with the layout, the fork emulation fails. This \n> is also why it is sometimes necessary to assign unique base addresses to \n> all libraries (rebaseall) in order to get fork emulation working again.\n\nAh, thanks for the explanation! (I knew that this thread still had \nsomething useful in it ;-)\n\n> So yes, it is unfortunate that some system tools can drastically affect \n> the ability of Cygwin and MSYS to function, but it's what we live with \n> to have fork/exec emulation. I see that there is work afoot to abstract \n> process creation so that hopefully this won't be as much a concern in \n> the near future.\n\nWe never had the problem in git itself, since we never used fork() on \nWindows. The problem lies in our usage of bash and perl.\n\nBash we can fix in the long run (this goes under the keyword \n\"builtinification\" on the git list), but I do not see our reliance on Perl \ngoing away, not for git {send-email,cvsimport,cvsexportcommit,svn}. \nThese are not too common operations, so common users will be able to do \nwithout them.\n\nHowever, if you rely on the CVS/SVN connectors, or send-email, and in any \ncase in the short run, you better run Git on Windows only when that funny \nLogitech driver is disabled ;-)\n\nCiao,\nDscho\n"},{"id":"55901","messageId":"20071015193053.GA15541@steel.home","threadId":"10283","inReplyTo":"85ejfwi3gr.fsf@lola.goethe.zz","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T19:30:53Z","receivedAt":"2007-10-15T19:30:53Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"David Kastrup, Mon, Oct 15, 2007 21:26:44 +0200:\n> Alex Riesen writes:\n> \n> > Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:\n> >> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> >> > can be not the same, depending on what current \"drive\" is) and\n> >> > multi-cwd, which hasn't had formed itself into a problem yet, but\n> >> > surely will\n> >> \n> >> Thats true for linux too.\n> >> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs\n> >> namespace you are one.\n> >\n> > No it is not. A process will always see the same filesystem object\n> > under the same path at the any given time (IOW, you can't have many\n> > namespaces active at the same time).\n> \n> dak@lola:/home/tmp/emacs$ mkdir -p /tmp/a/b\n> dak@lola:/home/tmp/emacs$ cd /tmp/a/b\n> dak@lola:/tmp/a/b$ sudo mount --bind /usr /tmp/a\n\nWell don't do that in your repos (unless need that for something).\n\nIt is not like someone creates a distribution which does it\nautomagically all the time and you're forced to use that distribution.\n"},{"id":"55902","messageId":"20071015193424.GB15541@steel.home","threadId":"10283","inReplyTo":"030301c80f58$d37b9710$2e08a8c0@CAM.ARTIMI.COM","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T19:34:24Z","receivedAt":"2007-10-15T19:34:24Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Dave Korn, Mon, Oct 15, 2007 20:25:55 +0200:\n> On 15 October 2007 18:49, Alex Riesen wrote:\n> \n> > Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:\n> >> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n> >>> Can you show a test case where this penalty is clearly visible? I'm\n> >>> curious to see the numbers. TIA\n> > ...\n> >> Now, that is my _personal_ decision. If _you_ have no problem with\n> >> Windows, just stick with it. (I always thought this goes without saying,\n> >> but Windows users tend to be very religious about this issue, thinking\n> >> just because I hate Windows that I want to make them switch. Hahaha, no.)\n> > \n> > They tend to be so exactly because they know how pathetic they are.\n> > They just want to have something where they don't suck and do\n> > everything to find it. And fail. Then they resort to graphics and\n> > user-friendly interface.\n> \n> Translation: \"I feel that I am superior to other people. This post has no\n> content apart from me shooting my mouth off in an attempt to prove how much\n> cleverer I am than anyone else. However apart from my self-love I have no\n> contribution to make to the discussion.\"\n\nIt is interpretation, not translation. Wrong, too.\n\n> This isn't slashdot. A computer is just a tool, and it's really *you* who\n> are being pathetic, because you confuse a choice of mass-manufactured consumer\n\nit is not a \"choice\". It is an accident. Like in \"caused by careless driving\".\n\n> product with a statement about personal identity. Loyalty to your favourite\n> brand is a game of one-upmanship suitable only for kids. You need to grow up.\n\nYep. Will do.\n"},{"id":"55903","messageId":"20071015194214.GC15541@steel.home","threadId":"10283","inReplyTo":"4713BA89.633B86F2@dessent.net","subject":"Re: Switching from CVS to GIT","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-10-15T19:42:14Z","receivedAt":"2007-10-15T19:42:14Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Brian Dessent, Mon, Oct 15, 2007 21:07:53 +0200:\n> Johannes Schindelin wrote:\n> > My bigger concerns are the performance and stability. For example, I had\n> > a very annoying problem on one of the machines I am testing msysGit on.\n> > The problem was _only_ fixable by deactivating component of Logitech's\n> > WebCam driver! Now, if a user-installable 3rd party program can make my\n> > regular git crash, I am scared what more it can do.\n> \n> That is because the MSYS runtime is based on an old version of Cygwin,\n> and it uses the same dirty tricks to emulate fork. These tricks rely on\n> having a repeatably consistent memory layout for a process each time it\n> is started, and when third party tools add hooks that affect the load\n> order or otherwise screw with the layout, the fork emulation fails. \n> This is also why it is sometimes necessary to assign unique base\n> addresses to all libraries (rebaseall) in order to get fork emulation\n> working again.\n\nHmm... Could the allocation of large contiguous blocks also lock the\nsystem hard? For instance, I avoid starting the test suite on my XP\nworkstation at work: it locks up hard every time. W2k works.\nThe system has nothing unusual in it. Well, it has an antivirus\nprogram (which hopefully stopped working after a series of crashes,\nwhich is just as well), an NVidia card with native driver (which is\nbroken in its own usual ways). Maybe that's enough\n"},{"id":"55904","messageId":"u1wbwjh10.fsf@gnu.org","threadId":"10283","inReplyTo":"20071015194214.GC15541@steel.home","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T19:48:27Z","receivedAt":"2007-10-15T19:48:27Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 21:42:14 +0200\n> From: Alex Riesen \n> Cc: Johannes Schindelin , git@vger.kernel.org,\n> \tEli Zaretskii , ae@op5.se, tsuna@lrde.epita.fr\n> \n> Hmm... Could the allocation of large contiguous blocks also lock the\n> system hard?\n\nNo, not on XP.\n\n> For instance, I avoid starting the test suite on my XP\n> workstation at work: it locks up hard every time.\n\nSounds like a bug to me.\n"},{"id":"55905","messageId":"Pine.LNX.4.64.0710152057580.25221@racer.site","threadId":"10283","inReplyTo":"u1wbwjh10.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T19:58:26Z","receivedAt":"2007-10-15T19:58:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Eli Zaretskii wrote:\n\n> > From: Alex Riesen \n> \n> > For instance, I avoid starting the test suite on my XP workstation at \n> > work: it locks up hard every time.\n> \n> Sounds like a bug to me.\n\nTo me, too. Alas, it works on W2k, so where is the bug?\n\nCiao,\nDscho\n"},{"id":"55917","messageId":"44f2ad561ade78c9dd5c4607b8ca@news.gmane.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710151938300.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Mark Watts","fromEmail":"mwatts42@gmail.com","sentAt":"2007-10-15T20:05:00Z","receivedAt":"2007-10-15T20:05:00Z","isPatch":false,"sender":{"key":"mwatts42@gmail.com","avatar":null},"body":"Hello Johannes,\n\n> My bigger concerns are the performance and stability. For example, I\n> had a very annoying problem on one of the machines I am testing\n> msysGit on. The problem was _only_ fixable by deactivating component\n> of Logitech's WebCam driver! Now, if a user-installable 3rd party\n> program can make my regular git crash, I am scared what more it can\n> do.\n\nNot just git. This driver has known issues with a number of pieces of software. \n The company I work with uses Delphi quite a bit and they also have Logitech \nWebCams for the devs and for some reason this driver makes debugging impossible \nwith Delphi. I have personally experienced this. I have also heard of this \nLogitech software having problems with other software too. I have not however \ntracked down exactly WHY this piece of software causes so much grief, only \nthat it does.\n\n-mark\n"},{"id":"55906","messageId":"4713C81F.A75FEFC2@dessent.net","threadId":"10283","inReplyTo":"20071015194214.GC15541@steel.home","subject":"Re: Switching from CVS to GIT","fromName":"Brian Dessent","fromEmail":"brian@dessent.net","sentAt":"2007-10-15T20:05:51Z","receivedAt":"2007-10-15T20:05:51Z","isPatch":false,"sender":{"key":"brian@dessent.net","avatar":null},"body":"Alex Riesen wrote:\n\n> Hmm... Could the allocation of large contiguous blocks also lock the\n> system hard? For instance, I avoid starting the test suite on my XP\n> workstation at work: it locks up hard every time. W2k works.\n> The system has nothing unusual in it. Well, it has an antivirus\n> program (which hopefully stopped working after a series of crashes,\n> which is just as well), an NVidia card with native driver (which is\n> broken in its own usual ways). Maybe that's enough\n\nIn terms of the MSYS/Cygwin style of fork emulation, large memory\nallocations shouldn't pose any real problem, but they will be slow as\nthe fork emulation has to manually replicate the state of the parent in\nthe child and this means copying memory extents. (Yes, horribly ugly,\nno doubt about it, but it allows for porting.)\n\nThis emulation code is sensitive enough that the Cygwin list has begun\nto maintain a list of software whose hooks/interference can cause Cygwin\napps to fail: . \nSince MSYS is derived from the same code I see no reason why the list\nwouldn't also implicate potential problems with binaries linked to the\nMSYS runtime.\n\nJohannes Schindelin wrote:\n\n> We never had the problem in git itself, since we never used fork() on\n> Windows. The problem lies in our usage of bash and perl.\n> \n> Bash we can fix in the long run (this goes under the keyword\n> \"builtinification\" on the git list), but I do not see our reliance on Perl\n> going away, not for git {send-email,cvsimport,cvsexportcommit,svn}.\n> These are not too common operations, so common users will be able to do\n> without them.\n> \n> However, if you rely on the CVS/SVN connectors, or send-email, and in any\n> case in the short run, you better run Git on Windows only when that funny\n> Logitech driver is disabled ;-)\n\nWell, instead of using an MSYS build of Perl there's always ActiveState\nPerl. I think you may be stuck on the shell though -- I don't know of\nany ports of bash that aren't MSYS or Cygwin based. However I do think\nthere's a native port of zsh out there by the GnuWin32 project, which\nwhen renamed as just \"/bin/sh\" might be suitable, but only if these\nscripts don't use bash-isms. I have not tried this zsh myself and\nspeed/compatibility wise I'm not sure it's up to snuff.\n\nBrian\n"},{"id":"55907","messageId":"Pine.LNX.4.64.0710152117290.25221@racer.site","threadId":"10283","inReplyTo":"4713C81F.A75FEFC2@dessent.net","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T20:19:51Z","receivedAt":"2007-10-15T20:19:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Brian Dessent wrote:\n\n> Well, instead of using an MSYS build of Perl there's always ActiveState \n> Perl.\n\nNo, but thanks no. You haven't been around long enough on this list to \ncount the issues, but it is known that ActiveState Perl is close to \nMalbolge.\n\n> I think you may be stuck on the shell though -- I don't know of any \n> ports of bash that aren't MSYS or Cygwin based. However I do think \n> there's a native port of zsh out there by the GnuWin32 project, which \n> when renamed as just \"/bin/sh\" might be suitable, but only if these \n> scripts don't use bash-isms. I have not tried this zsh myself and \n> speed/compatibility wise I'm not sure it's up to snuff.\n\nThere is a port of BusyBox' dash, which is nearing completion. Once \nNguyen says it is ready enough, we will try to integrate it into msysGit.\n\nCiao,\nDscho\n"},{"id":"55908","messageId":"alpine.LFD.0.999.0710151321560.6887@woody.linux-foundation.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710152026260.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-15T20:24:17Z","receivedAt":"2007-10-15T20:24:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 15 Oct 2007, Johannes Schindelin wrote:\n> \n> Bash we can fix in the long run (this goes under the keyword \n> \"builtinification\" on the git list)\n\nI thought busybox was being used for the core commands? Is ash not \ncomplete/usable enough (with all the fixes git has had for broken shells) \nto be used? \n\nI do agree that perl looks unavoidable, but I thought the windows port \nalready avoided at least bash. Not true?\n\n(or is it just that even with ash, you end up hitting all the same issues \nwith cygwin/msys?)\n\n\t\tLinus\n"},{"id":"55910","messageId":"Pine.LNX.4.64.0710152136130.25221@racer.site","threadId":"10283","inReplyTo":"alpine.LFD.0.999.0710151321560.6887@woody.linux-foundation.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T20:36:54Z","receivedAt":"2007-10-15T20:36:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Linus Torvalds wrote:\n\n> On Mon, 15 Oct 2007, Johannes Schindelin wrote:\n> > \n> > Bash we can fix in the long run (this goes under the keyword \n> > \"builtinification\" on the git list)\n> \n> I thought busybox was being used for the core commands? Is ash not \n> complete/usable enough (with all the fixes git has had for broken \n> shells) to be used?\n\nNo, not yet. The problem is not so much ash, as Nguyen, who said that \ngitbox is not there yet.\n\nCiao,\nDscho\n"},{"id":"55912","messageId":"7287AD62-3274-4B20-881C-D02E08C4B2EF@zib.de","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710152117290.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-15T20:43:06Z","receivedAt":"2007-10-15T20:43:06Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:\n\n>> I think you may be stuck on the shell though -- I don't know of any\n>> ports of bash that aren't MSYS or Cygwin based. However I do think\n>> there's a native port of zsh out there by the GnuWin32 project, which\n>> when renamed as just \"/bin/sh\" might be suitable, but only if these\n>> scripts don't use bash-isms. I have not tried this zsh myself and\n>> speed/compatibility wise I'm not sure it's up to snuff.\n\nI can't find zsh on the GnuWin32 project page.\n\n\n> There is a port of BusyBox' dash, which is nearing completion. Once\n> Nguyen says it is ready enough, we will try to integrate it into \n> msysGit.\n\nGnuarch [1] recommends zsh from the unxutils project [2].\n\n\tSteffen\n\n[1] http://www.gnuarch.org/gnuarchwiki/Native_WIN32_Support\n[2] http://unxutils.sourceforge.net/\n"},{"id":"55913","messageId":"Pine.LNX.4.64.0710152144480.25221@racer.site","threadId":"10283","inReplyTo":"7287AD62-3274-4B20-881C-D02E08C4B2EF@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-15T20:46:50Z","receivedAt":"2007-10-15T20:46:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 15 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:\n> \n> > There is a port of BusyBox' dash, which is nearing completion. Once \n> > Nguyen says it is ready enough, we will try to integrate it into \n> > msysGit.\n> \n> Gnuarch [1] recommends zsh from the unxutils project [2].\n\nI have the slight suspicion that we will somehow have problems with \n/etc/gitconfig, /share/git-gui/ and friends, should we try to use zsh. At \nleast with gitbox, we can hack a \"/\" translation for scripts.\n\nCiao,\nDscho\n"},{"id":"55914","messageId":"uy7e4hyv0.fsf@gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710152057580.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T21:06:11Z","receivedAt":"2007-10-15T21:06:11Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 20:58:26 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Alex Riesen , brian@dessent.net, git@vger.kernel.org, \n> ae@op5.se, tsuna@lrde.epita.fr\n> \n> On Mon, 15 Oct 2007, Eli Zaretskii wrote:\n> \n> > > From: Alex Riesen \n> > \n> > > For instance, I avoid starting the test suite on my XP workstation at \n> > > work: it locks up hard every time.\n> > \n> > Sounds like a bug to me.\n> \n> To me, too. Alas, it works on W2k, so where is the bug?\n\nI'm not smart enough to know without debugging it. W2K and WXP have\ndifferent system libraries and somewhat different memory layouts. A\nbug can get away on one, but not on the other.\n"},{"id":"55915","messageId":"uwstohyqf.fsf@gnu.org","threadId":"10283","inReplyTo":"4713C81F.A75FEFC2@dessent.net","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-15T21:08:56Z","receivedAt":"2007-10-15T21:08:56Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 13:05:51 -0700\n> From: Brian Dessent \n> CC: Johannes Schindelin ,\n> \tgit@vger.kernel.org, Eli Zaretskii , ae@op5.se,\n> \ttsuna@lrde.epita.fr\n> \n> I don't know of\n> any ports of bash that aren't MSYS or Cygwin based. However I do think\n> there's a native port of zsh out there by the GnuWin32 project, which\n> when renamed as just \"/bin/sh\" might be suitable, but only if these\n> scripts don't use bash-isms. I have not tried this zsh myself and\n> speed/compatibility wise I'm not sure it's up to snuff.\n\nI think you mean Amol's zsh (there's no GnuWin32 port of zsh AFAIK).\nAmol's zsh is what I use, but it has a few annoying bugs, even after I\nfixed some, that prevent it from running a typical configure script,\nfor example.\n"},{"id":"55920","messageId":"20071015231242.GR27899@spearce.org","threadId":"10283","inReplyTo":"47130B25.4010304@viscovery.net","subject":"Re: Switching from CVS to GIT","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-15T23:12:42Z","receivedAt":"2007-10-15T23:12:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Sixt wrote:\n> FWIW, I'm using the MinGW port from cmd.exe, i.e. not from a posix shell, \n> on a *production* repository. gitk and git-gui work. Not all operations \n> that I regularly use are available[*] via the GUIs, like git-rebase or \n> non-fast-forwarding push, so the use of the command line is needed from \n> time to time.\n\nRebase in git-gui is starting to be developed. But its still not even\nclose to something I can use, let alone that I would be willing to ship\nto another person for testing.\n\nForce push (non-fast-forwarding push) is in git-gui.git's master\nbranch now as part of the 0.9.x series. There's a new checkbox\noption in the push dialog to trigger adding --force to git-push\ncommand line.\n\n> Unfortunately, \"Fetch\" does not yet work[*] from within git-gui, so you \n> have to fall back to git-fetch on the command line.\n> \n> [*] Note the distinction between \"not available\" and \"does not work\".\n\nWhat's broken? Is this that Git protocol dump showing up in\ngit-gui's console window thing?\n\nAre you using the C based fetch that is in git.git's next branch,\nor the shell script based one that is in master? Which Tcl/Tk\nversion are you using to run git-gui?\n\n-- \nShawn.\n"},{"id":"55927","messageId":"Pine.LNX.4.64.0710151859590.7638@iabervon.org","threadId":"10283","inReplyTo":"u7ilpjp3x.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-16T00:45:02Z","receivedAt":"2007-10-16T00:45:02Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"Responding only to those portions where I think Windows experience and a \nWindows perspective would be helpful...\n\nOn Mon, 15 Oct 2007, Eli Zaretskii wrote:\n\n> > - no proper filename semantics (case-insensitivity and stupid rules for\n> > allowed characters in filenames, like \":\" in filenames in\n> > cross-platform projects)\n> \n> There's a flag on Windows to open files case-sensitively, if you need\n> that. In any case, I don't see how this can be of any real relevance\n> to porting GIT. As for \":\" in file names, simply don't use it, like\n> you don't use white space or characters below 32 decimal: it's\n> inconvenient, even if it's allowed.\n\nI believe the hassle is that readdir doesn't necessarily report a README in \na directory which is supposed to have a README, when it has a readme \ninstead. I think we want O(n) comparison of sorted lists, which doesn't \nwork if equivalent names don't sort the same.\n\n> > - no acceptable level of performance in filesystem and VFS (readdir,\n> > stat, open and read/write are annoyingly slow)\n> \n> With what libraries? Native `stat' and `readdir' are quite fast.\n> Perhaps you mean the ported glibc (libgw32c), where `readdir' is\n> indeed painfully slow, but then you don't need to use it.\n\nWe want getting stat info, using readdir to figure out what files exist, \nfor 106083 files in 1603 directories with a hot cache to take under 1s; \notherwise \"git status\" takes a noticeable amount of time with a medium-big \nproject, and we want people to be able to get info on what's changed \neffectively instantly. My impression is that Windows' native stat and \nreaddir are plenty fast for what normal Windows programs want, but we \nactually expect reasonable performance on an unreasonably-big \nmetadata-heavy input. AFAICT, nothing but Linux is optimized for this, but \nwe're used to being able to find out if there's any change to a large \ndirectory structure in practically no time. On the other hand, we really \njust want to beat users' expectations for this operation, not our own \nexpectations, so this may only be a problem for people benchmarking \nWindows git against Linux git.\n\n> > - no real \"mmap\" (which kills perfomance and complicates code)\n> \n> You only need mmap because you are accustomed to use it on GNU/Linux.\n\nI believe the need here is quick setup and fast access to sparse portions \nof several 100M files. It's hard to beat a page fault for read speed.\n\nWe also expect to be able to make a sequence of file system operations \nsuch that programs starting at any time see the same database as the files \ncontaining the database get restructured. My impression is that this is \nvery hard or impossible with Windows, and also that it doesn't matter for \nWindows users, because they'll only have one program at a time accessing \nthe repository. A lot of our filesystem demands are about making a wide \nvariety of race conditions give the same result regardless of how the race \ngoes, and we're just being overly careful for a Windows environment \n(although not necessarily for users with a UNIX background using Windows \nonly because they have to).\n\n> > - it has only one argument (limited in size) passed to started\n> > programs, which means that there is no possible way to safely pass\n> > file and text arguments on command line (more than one, that is)\n> \n> Not enough context, so I cannot talk intelligently about this. Why do\n> you need interprocess communication in the first place? why not simply\n> give birth to a subsidiary process and pass it a command line (which\n> can be up to 32KB)?\n\nA unixy pipeline was convenient, given what else we had already written. \nIt's getting converted to single tasks, but it's not a top priority for \nmost developers, since streaming 100M from one program to the next under \nmost of our environments is trivial.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"55932","messageId":"fcaeb9bf0710151924r258dd561hd13c22319d17f80f@mail.gmail.com","threadId":"10283","inReplyTo":"7287AD62-3274-4B20-881C-D02E08C4B2EF@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-10-16T02:24:50Z","receivedAt":"2007-10-16T02:24:50Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/16/07, Steffen Prohaska wrote:\n>\n> On Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:\n> > There is a port of BusyBox' dash, which is nearing completion. Once\n> > Nguyen says it is ready enough, we will try to integrate it into\n> > msysGit.\n>\n> Gnuarch [1] recommends zsh from the unxutils project [2].\n\nAll zsh links in [2] are dead. I did try hard to find the legendary\nzsh for Windows before giving up and porting busybox's ash instead. If\nyou have zsh source of the port, please send me. Thank you.\n\n> Steffen\n>\n> [1] http://www.gnuarch.org/gnuarchwiki/Native_WIN32_Support\n> [2] http://unxutils.sourceforge.net/\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\n-- \nDuy\n"},{"id":"55940","messageId":"uprzfithw.fsf@gnu.org","threadId":"10283","inReplyTo":"fcaeb9bf0710151924r258dd561hd13c22319d17f80f@mail.gmail.com","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T04:16:43Z","receivedAt":"2007-10-16T04:16:43Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 09:24:50 +0700\n> From: \"Nguyen Thai Ngoc Duy\" \n> Cc: \"Git Mailing List\" , \"Alex Riesen\" , \n> \t\"Eli Zaretskii\" , \"Andreas Ericsson\" , \n> \ttsuna@lrde.epita.fr, \n> \t\"Johannes Schindelin\" \n> \n> I did try hard to find the legendary\n> zsh for Windows before giving up and porting busybox's ash instead.\n\nWhere can one find this port of busybox's ash?\n"},{"id":"55942","messageId":"uodezisvg.fsf@gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710151859590.7638@iabervon.org","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T04:30:11Z","receivedAt":"2007-10-16T04:30:11Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)\n> From: Daniel Barkalow \n> cc: Alex Riesen , Johannes.Schindelin@gmx.de, ae@op5.se, \n> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n> \n> I believe the hassle is that readdir doesn't necessarily report a README in \n> a directory which is supposed to have a README, when it has a readme \n> instead.\n\nSorry I'm asking potentially stupid questions out of ignorance: why\nwould you want readdir to return `README' when you have `readme'?\n\n> I think we want O(n) comparison of sorted lists, which doesn't \n> work if equivalent names don't sort the same.\n\nYou comparison function should be case-insensitive on Windows, or am I\nmissing something?\n\n> > > - no acceptable level of performance in filesystem and VFS (readdir,\n> > > stat, open and read/write are annoyingly slow)\n> > \n> > With what libraries? Native `stat' and `readdir' are quite fast.\n> > Perhaps you mean the ported glibc (libgw32c), where `readdir' is\n> > indeed painfully slow, but then you don't need to use it.\n> \n> We want getting stat info, using readdir to figure out what files exist, \n> for 106083 files in 1603 directories with a hot cache to take under 1s; \n> otherwise \"git status\" takes a noticeable amount of time with a medium-big \n> project, and we want people to be able to get info on what's changed \n> effectively instantly. My impression is that Windows' native stat and \n> readdir are plenty fast for what normal Windows programs want, but we \n> actually expect reasonable performance on an unreasonably-big \n> metadata-heavy input.\n\nIf that's the issue, then it's not a good idea to call `stat' and\n`readdir' on Windows at all. `stat' is a single system call on Posix\nsystems, while on Windows it usually needs to go out of its way\ncalling half a dozen system services to gather the `struct stat' info.\nYou need to call something like FindFirstFile, which can do the job of\n`stat' and `readdir' together (and of `fnmatch', if you need to filter\nonly some files) in one go. I don't know whether this will scan 100K\nfiles under one second (maybe I will try it one of these days), but it\nwill definitely be faster than `readdir'+`stat' by maybe as much as an\norder of magnitude.\n\n> > > - no real \"mmap\" (which kills perfomance and complicates code)\n> > \n> > You only need mmap because you are accustomed to use it on GNU/Linux.\n> \n> I believe the need here is quick setup and fast access to sparse portions \n> of several 100M files. It's hard to beat a page fault for read speed.\n\nIf you need memory-mapped files, they are available on Windows. I\nthought the original comment about `mmap' was because it was used to\nallocate memory, not read files into memory.\n\n> We also expect to be able to make a sequence of file system operations \n> such that programs starting at any time see the same database as the files \n> containing the database get restructured.\n\nSorry, I don't understand this; please tell more about the operations,\n``the same database'' issue (what database?) and what do you mean by\n``the files containing the database get restructured''.\n\n> A unixy pipeline was convenient\n\nWindows supports pipelines with almost 100% the same functionality as\nPosix. Again, perhaps I'm missing something.\n"},{"id":"55947","messageId":"471448D0.6080200@op5.se","threadId":"10283","inReplyTo":"uodezisvg.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-16T05:14:56Z","receivedAt":"2007-10-16T05:14:56Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Eli Zaretskii wrote:\n>> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)\n>> From: Daniel Barkalow \n>> cc: Alex Riesen , Johannes.Schindelin@gmx.de, ae@op5.se, \n>> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n>>\n>> I believe the hassle is that readdir doesn't necessarily report a README in \n>> a directory which is supposed to have a README, when it has a readme \n>> instead.\n> \n> Sorry I'm asking potentially stupid questions out of ignorance: why\n> would you want readdir to return `README' when you have `readme'?\n> \n\nBecause it might have been checked in as README, and since git is case\nsensitive that is what it'll think should be there when it reads the\ndirectories. If it's not, users get to see\n\n\tremoved: README\n\tuntracked: readme\n\nand there's really no easy way out of this one, since users on a case-\nsensitive filesystem might be involved in this project too, so it\ncould be an intentional rename, but we don't know for sure. Just\nclobbering the in-git file is wrong, but overwriting a file on disk\nis wrong too. git tries hard to not ever lose any data for the user.\n\n> \n>>>> - no acceptable level of performance in filesystem and VFS (readdir,\n>>>> stat, open and read/write are annoyingly slow)\n>>> With what libraries? Native `stat' and `readdir' are quite fast.\n>>> Perhaps you mean the ported glibc (libgw32c), where `readdir' is\n>>> indeed painfully slow, but then you don't need to use it.\n>> We want getting stat info, using readdir to figure out what files exist, \n>> for 106083 files in 1603 directories with a hot cache to take under 1s; \n>> otherwise \"git status\" takes a noticeable amount of time with a medium-big \n>> project, and we want people to be able to get info on what's changed \n>> effectively instantly. My impression is that Windows' native stat and \n>> readdir are plenty fast for what normal Windows programs want, but we \n>> actually expect reasonable performance on an unreasonably-big \n>> metadata-heavy input.\n> \n> If that's the issue, then it's not a good idea to call `stat' and\n> `readdir' on Windows at all. `stat' is a single system call on Posix\n> systems, while on Windows it usually needs to go out of its way\n> calling half a dozen system services to gather the `struct stat' info.\n> You need to call something like FindFirstFile, which can do the job of\n> `stat' and `readdir' together (and of `fnmatch', if you need to filter\n> only some files) in one go. I don't know whether this will scan 100K\n> files under one second (maybe I will try it one of these days), but it\n> will definitely be faster than `readdir'+`stat' by maybe as much as an\n> order of magnitude.\n> \n\nTo be honest though, there are so many places which do the readdir+stat\nthat I don't think it'd be worth factoring it out, especially since it\n*works* on windows. It's just slow, and only slow compared to various\nunices. I *think* (correct me if I'm wrong) that git is still faster\nthan a whole bunch of other scm's on windows, but to one who's used to\nits performance on Linux that waiting several seconds to scan 10k files\njust feels wrong.\n\n\n>> We also expect to be able to make a sequence of file system operations \n>> such that programs starting at any time see the same database as the files \n>> containing the database get restructured.\n> \n> Sorry, I don't understand this; please tell more about the operations,\n> ``the same database'' issue (what database?)\n\nThe object database, located under .git/objects.\n\n> and what do you mean by\n> ``the files containing the database get restructured''.\n> \n\n/* I'm on a limb here. Nicolas Pitre knows the git packfile format, so\n * perhaps he'll be kind enough to correct me if I'm wrong */\n\nThe mmap() stuff is primarily convenient when reading huge packfiles. As\nfar as I understand it, they're ordered by some sort of delta similarity\nscore, so mmap()'ing 100MiB or so of a certain packfile will most likely\nmean we have a couple of thousand \"connected\" revisions in memory. That\ndatabase gets sort of restructured as the memory-chunk that's mmap()'ed\nget moved to read in the next couple of thousand revisions.\n\nIn all honesty, this doesn't matter much for already fully packed projects\nunless they're significantly larger than the Linux kernel, since git is so\namazingly good at compressing large repos to a small size. Linux is ~180\nMiB fully packed, and most developer's systems could just read() that\nentire packfile into memory without much problem. But then again, no-one's\never had problems supporting the \"normal\" cases.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55951","messageId":"Pine.LNX.4.64.0710160032020.7638@iabervon.org","threadId":"10283","inReplyTo":"uodezisvg.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-16T05:56:46Z","receivedAt":"2007-10-16T05:56:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 16 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)\n> > From: Daniel Barkalow \n> > cc: Alex Riesen , Johannes.Schindelin@gmx.de, ae@op5.se, \n> > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n> > \n> > I believe the hassle is that readdir doesn't necessarily report a README in \n> > a directory which is supposed to have a README, when it has a readme \n> > instead.\n> \n> Sorry I'm asking potentially stupid questions out of ignorance: why\n> would you want readdir to return `README' when you have `readme'?\n\nSay the project upstream has the file being \"README\", but, for some \nreason, it has ended up checked out as \"readme\" in your directory. Since \nyour filesystem is case insensitive, it's supposed to be the same file, \nbut when git goes through the list of files in the directory, it sees \n\"readme\", and there's nothing between reachable.h and read-cache.c in the \nlist of tracked files. We've got a sorted list of filenames we're tracking \nalong with their most-recently-seen content, and we want to merge the \nresults of readdir with them, and this is obviously more straightforward \nif the filename that's the match for \"README\" is provided byte-for-byte \nthe same, and therefore sorts the same.\n\n> > I think we want O(n) comparison of sorted lists, which doesn't \n> > work if equivalent names don't sort the same.\n> \n> You comparison function should be case-insensitive on Windows, or am I\n> missing something?\n\nWe want both lists sorted, so that we can step through the pair together \nand always reach matches together. This requires that the equivalent names \nsort together, as well as comparing equal.\n\n> > > > - no acceptable level of performance in filesystem and VFS (readdir,\n> > > > stat, open and read/write are annoyingly slow)\n> > > \n> > > With what libraries? Native `stat' and `readdir' are quite fast.\n> > > Perhaps you mean the ported glibc (libgw32c), where `readdir' is\n> > > indeed painfully slow, but then you don't need to use it.\n> > \n> > We want getting stat info, using readdir to figure out what files exist, \n> > for 106083 files in 1603 directories with a hot cache to take under 1s; \n> > otherwise \"git status\" takes a noticeable amount of time with a medium-big \n> > project, and we want people to be able to get info on what's changed \n> > effectively instantly. My impression is that Windows' native stat and \n> > readdir are plenty fast for what normal Windows programs want, but we \n> > actually expect reasonable performance on an unreasonably-big \n> > metadata-heavy input.\n> \n> If that's the issue, then it's not a good idea to call `stat' and\n> `readdir' on Windows at all. `stat' is a single system call on Posix\n> systems, while on Windows it usually needs to go out of its way\n> calling half a dozen system services to gather the `struct stat' info.\n> You need to call something like FindFirstFile, which can do the job of\n> `stat' and `readdir' together (and of `fnmatch', if you need to filter\n> only some files) in one go. I don't know whether this will scan 100K\n> files under one second (maybe I will try it one of these days), but it\n> will definitely be faster than `readdir'+`stat' by maybe as much as an\n> order of magnitude.\n\nAh, that's helpful. We don't actually care too much about the particular \ninfo in stat; we just want to know quickly if the file has changed, so we \ncan hash only the ones that have been touched and get the actual content \nchanges.\n\n> > > > - no real \"mmap\" (which kills perfomance and complicates code)\n> > > \n> > > You only need mmap because you are accustomed to use it on GNU/Linux.\n> > \n> > I believe the need here is quick setup and fast access to sparse portions \n> > of several 100M files. It's hard to beat a page fault for read speed.\n> \n> If you need memory-mapped files, they are available on Windows. I\n> thought the original comment about `mmap' was because it was used to\n> allocate memory, not read files into memory.\n\nNo, we get our memory with malloc like normal people. The mmap is because \nwe want to feed files and parts of files to zlib, and mmap makes that \neasy.\n\n> > We also expect to be able to make a sequence of file system operations \n> > such that programs starting at any time see the same database as the files \n> > containing the database get restructured.\n> \n> Sorry, I don't understand this; please tell more about the operations,\n> ``the same database'' issue (what database?) and what do you mean by\n> ``the files containing the database get restructured''.\n\nGit is built around a database of objects, which includes \"blobs\" (file \ncontent), \"trees\" (directory structure), \"commits\" (history linkage), and \n\"tags\" (additional annotations). Each of these objects gets hashed, and is \nreferenced by hash. So we need to be able to get the object with a given \nhash quickly, and write an object and take its hash (ideally, stream the \nwrite and find out the hash at the end, with the database key set at that \npoint). Also, this database should be compressed effectively, because it \nought to compress really well, since a lot of the blobs and trees are only \nslightly different from other blobs or trees (by whatever changes were \nmade between that revision and other revisions).\n\nThe current implementation of the persistant storage of this database is a \nbit complicated, with the goal being that creating objects is really fast, \nand looking up objects doesn't degrade too quickly, and there are \noptimization operations available that take some time and speed up future \nlookups and reduce the storage overhead (especially so that data can be \ntransferred efficiently). The tricky thing is that, while the optimization \nprocess is running, other programs may be reading the database, so (1) the \nfiles that are no longer needed, because better-optimized versions are in \nplace, may be open in another task, and (2) complete and correct new \nfiles have to appear and be such that pre-existing tasks will find them \nbefore old files can be removed. The optimization creates \"pack files\" and \n\"pack indices\", where the pack file has a lot of objects with delta \ncompression between them and zlib compression of them, and the index files \ntell where everything in the pack file is. So we mmap the index files to \nsearch through, and mmap portions of the pack files to get the data out \nof, and we may be using them as they're replaced with more comprehensive \npack files by another task.\n\nNow, it's entirely possible that a completely different database \nimplementation would be better on Windows, but our current one does a lot \nof creating files under different names, moving them to names where \nthey'll be seen (since this is atomic under POSIX, and partial files are \nnever seen by other tasks). Also, once we have new files in place, we \nunlink the files that they replace, so that new tasks will use the new \nones and tasks that already have old ones open can still get the data out \nof them. Also, the files generally get mmaped, \n\n> > A unixy pipeline was convenient\n> \n> Windows supports pipelines with almost 100% the same functionality as\n> Posix. Again, perhaps I'm missing something.\n\nI'm probably the one missing something here; I don't really know anything \nabout Windows, and I only know what code other people have had problems \nporting. Mostly what we use for IPC is pipelines, so, if they work well, I \ndon't know what the problem is.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"55954","messageId":"85ejfvh9tz.fsf@lola.goethe.zz","threadId":"10283","inReplyTo":"uodezisvg.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-16T06:06:48Z","receivedAt":"2007-10-16T06:06:48Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Eli Zaretskii writes:\n\n>> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)\n>> From: Daniel Barkalow \n>> cc: Alex Riesen , Johannes.Schindelin@gmx.de, ae@op5.se, \n>> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n>> \n>> I believe the hassle is that readdir doesn't necessarily report a README in \n>> a directory which is supposed to have a README, when it has a readme \n>> instead.\n>\n> Sorry I'm asking potentially stupid questions out of ignorance: why\n> would you want readdir to return `README' when you have `readme'?\n>\n>> I think we want O(n) comparison of sorted lists, which doesn't \n>> work if equivalent names don't sort the same.\n>\n> You comparison function should be case-insensitive on Windows, or am\n> I missing something?\n\nWell, are \"I\" and \"i\" the same letters? What about \"İ\" and \"i\"? Or\n\"I\" and \"ı\"? What about Greek where uppercasing loses accents\n(actually not unusual in literate French, either). And what about\nGerman ß and SS/SZ?\n\n\"case-insensitive\" is a simple word, but the devil is in the details,\nand that means basically requiring a system-provided sorting function.\nAnd actually the _killer_ detail here is that git _must_ have the same\nsorting order on every platform, since the order of files in a\ndirectory tree affects its SHA-1 sum. So a system-dependent sorting\norder breaks git interoperability.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"55956","messageId":"471455ED.8070408@viscovery.net","threadId":"10283","inReplyTo":"20071015231242.GR27899@spearce.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-16T06:10:53Z","receivedAt":"2007-10-16T06:10:53Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Shawn O. Pearce schrieb:\n> Johannes Sixt wrote:\n>> Unfortunately, \"Fetch\" does not yet work[*] from within git-gui, so you \n>> have to fall back to git-fetch on the command line.\n>>\n>> [*] Note the distinction between \"not available\" and \"does not work\".\n> \n> What's broken? Is this that Git protocol dump showing up in\n> git-gui's console window thing?\n> \n> Are you using the C based fetch that is in git.git's next branch,\n> or the shell script based one that is in master? Which Tcl/Tk\n> version are you using to run git-gui?\n\nIt's the scripted fetch that does not work. The symptom is that the output \nof at least one of the commands (upload-pack, I think, because what I see is \nwire protocol) goes to a newly spawned console instead of wherever it was \nredirected to.\n\nI didn't bother reporting since builtin-fetch is on the way (which will \nhopefully make this a moot point) and our team here is comfortable with \ncalling git fetch on the command line.\n\n-- Hannes\n"},{"id":"55957","messageId":"C1BDE454-BA17-4421-9877-7D97811979EC@zib.de","threadId":"10283","inReplyTo":"fcaeb9bf0710151924r258dd561hd13c22319d17f80f@mail.gmail.com","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-16T06:17:25Z","receivedAt":"2007-10-16T06:17:25Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 16, 2007, at 4:24 AM, Nguyen Thai Ngoc Duy wrote:\n\n> On 10/16/07, Steffen Prohaska wrote:\n>>\n>> On Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:\n>>> There is a port of BusyBox' dash, which is nearing completion. Once\n>>> Nguyen says it is ready enough, we will try to integrate it into\n>>> msysGit.\n>>\n>> Gnuarch [1] recommends zsh from the unxutils project [2].\n>\n> All zsh links in [2] are dead. I did try hard to find the legendary\n> zsh for Windows before giving up and porting busybox's ash instead. If\n> you have zsh source of the port, please send me. Thank you.\n\nIt is included in UnxUtilsSrc.zip, updated on 2007-03-01 06:22, from\n\nhttp://sourceforge.net/projects/unxutils\nhttp://sourceforge.net/project/showfiles.php?group_id=9328\n\n\tSteffen\n"},{"id":"55960","messageId":"20071016062144.GD13801@spearce.org","threadId":"10283","inReplyTo":"471455ED.8070408@viscovery.net","subject":"Re: Switching from CVS to GIT","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-16T06:21:44Z","receivedAt":"2007-10-16T06:21:44Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Sixt wrote:\n> >Johannes Sixt wrote:\n> >>Unfortunately, \"Fetch\" does not yet work[*] from within git-gui, so you \n> >>have to fall back to git-fetch on the command line.\n> \n> It's the scripted fetch that does not work. The symptom is that the output \n> of at least one of the commands (upload-pack, I think, because what I see \n> is wire protocol) goes to a newly spawned console instead of wherever it \n> was redirected to.\n> \n> I didn't bother reporting since builtin-fetch is on the way (which will \n> hopefully make this a moot point) and our team here is comfortable with \n> calling git fetch on the command line.\n\nHmm. The way the builtin-fetch works this shouldn't happen, but\nI'd appreciate it if you could test and report back before that\ntopic merges into master.\n\n-- \nShawn.\n"},{"id":"55961","messageId":"E1Ihfrl-0007w1-3I@fencepost.gnu.org","threadId":"10283","inReplyTo":"471448D0.6080200@op5.se","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T06:25:21Z","receivedAt":"2007-10-16T06:25:21Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 07:14:56 +0200\n> From: Andreas Ericsson \n> CC: Daniel Barkalow , raa.lkml@gmail.com, \n> Johannes.Schindelin@gmx.de, tsuna@lrde.epita.fr, git@vger.kernel.org, \n> make-w32@gnu.org\n> \n> > Sorry I'm asking potentially stupid questions out of ignorance: why\n> > would you want readdir to return `README' when you have `readme'?\n> > \n> \n> Because it might have been checked in as README, and since git is case\n> sensitive that is what it'll think should be there when it reads the\n> directories. If it's not, users get to see\n> \n> \tremoved: README\n> \tuntracked: readme\n\nThis is a non-issue, then: Windows filesystems are case-preserving, so\nif `README' became `readme', someone deliberately renamed it, in which\ncase it's okay for git to react as above.\n\n> could be an intentional rename, but we don't know for sure.\n\nIt _must_ have been an intentional rename. While years ago there used\nto be old DOS programs that could cause such a rename as a side effect\nof modifying a file, that time is long gone. There's no longer a need\nto cater to such programs, as even DOS programs can support\ncase-preserving APIs on Windows.\n\n> To be honest though, there are so many places which do the readdir+stat\n> that I don't think it'd be worth factoring it out\n\nSomething for Windows users to decide, I guess. It's not hard to\nrefactor this, it just needs a motivated volunteer.\n\n> especially since it\n> *works* on windows. It's just slow, and only slow compared to various\n> unices.\n\nI think only the Linux filesystem is as fast as you say. But I may be\nwrong (did someone compare with *BSD, say?).\n\n> I *think* (correct me if I'm wrong) that git is still faster\n> than a whole bunch of other scm's on windows, but to one who's used to\n> its performance on Linux that waiting several seconds to scan 10k files\n> just feels wrong.\n\nUnless that 10K is a typo and you really meant 100K, I don't think 10K\nfiles should take several seconds to scan on Windows. I just tried\n\"find -print\" on a directory with 32K files in 4K subdirectories, and\nit took 8 sec elapsed with a hot cache. So 10K files should take at\nmost 2 seconds, even without optimizing file traversal code. Doing\nthe same with native Windows system calls (\"dir /s\") brings that down\nto 4 seconds for 32K files.\n\nOn the other hand, what packages have 100K files? If there's only one\n-- the Linux kernel -- then I think this kind of performance is for\nall practical purposes unimportant on Windows, because while it is\nreasonable to assume that someone would like to use git on Windows,\nassuming that someone will develop the Linux kernel on Windows is --\nhow should I put it -- _really_ far-fetched ;-)\n\nAs for speed of file ops ``just feeling wrong'': it's not limited to\ngit in any way. You will see the same with \"tar -x\", with \"find\" and\neven with \"cp -r\", when you compare Linux filesystems, especially on a\nfast 64-bit machine, with comparable Windows operations. A Windows\nuser who occasionally works on GNU/Linux already knows that, so seeing\nthe same in git will not come as a surprise. Again, I wonder how this\ncompares with other free OSes, like FreeBSD (unless they use the same\nfilesystem), and with proprietary Unices, like AIX and Solaris.\n"},{"id":"55962","messageId":"47145A4C.2070206@viscovery.net","threadId":"10283","inReplyTo":"20071016062144.GD13801@spearce.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-16T06:29:32Z","receivedAt":"2007-10-16T06:29:32Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Shawn O. Pearce schrieb:\n> Johannes Sixt wrote:\n>>> Johannes Sixt wrote:\n>>>> Unfortunately, \"Fetch\" does not yet work[*] from within git-gui, so you \n>>>> have to fall back to git-fetch on the command line.\n>> It's the scripted fetch that does not work. The symptom is that the output \n ^^^^^^^^^^^^^^\n>> of at least one of the commands (upload-pack, I think, because what I see \n>> is wire protocol) goes to a newly spawned console instead of wherever it \n>> was redirected to.\n>>\n>> I didn't bother reporting since builtin-fetch is on the way (which will \n>> hopefully make this a moot point) and our team here is comfortable with \n>> calling git fetch on the command line.\n> \n> Hmm. The way the builtin-fetch works this shouldn't happen, but\n> I'd appreciate it if you could test and report back before that\n> topic merges into master.\n\nThis happens with git 1.5.3 plus the git-gui that comes with that.\n\nFWIW, I'm in the process of merging master of git.git into git/mingw.git, \nand then the builtin-fetch series (because on top of that there is my \nfork/exec removal series, which I'd like to adjust for Windows). And *then* \nI'll be able to report back to you.\n\n-- Hannes\n"},{"id":"55963","messageId":"47145D6D.80001@viscovery.net","threadId":"10283","inReplyTo":"uodezisvg.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-16T06:42:53Z","receivedAt":"2007-10-16T06:42:53Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Eli Zaretskii schrieb:\n> If that's the issue, then it's not a good idea to call `stat' and\n> `readdir' on Windows at all. `stat' is a single system call on Posix\n> systems, while on Windows it usually needs to go out of its way\n> calling half a dozen system services to gather the `struct stat' info.\n\nThanks to Marius Storm-Olsen we already have a stat replacement that's twice \nas fast as msvcrt's stat. I calls only one API function \n(GetFileAttributesEx, but of course I don't know what's going on under its \nhood), because we need only a small part of struct stat filled in correctly.\n\n-- Hannes\n"},{"id":"55965","messageId":"E1IhgT2-0000bg-O6@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710160032020.7638@iabervon.org","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T07:03:52Z","receivedAt":"2007-10-16T07:03:52Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)\n> From: Daniel Barkalow \n> cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se, \n> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n> \n> Ah, that's helpful. We don't actually care too much about the particular \n> info in stat; we just want to know quickly if the file has changed, so we \n> can hash only the ones that have been touched and get the actual content \n> changes.\n\nAs I wrote in my other message, using native APIs improves performance\nby at least a factor of two.\n\n> The tricky thing is that, while the optimization \n> process is running, other programs may be reading the database, so (1) the \n> files that are no longer needed, because better-optimized versions are in \n> place, may be open in another task\n\nIs this because another user might be accessing the database, or are\nthere other popular use cases that cause this? If the former, then\nthis is not terribly important on Windows, since the situation when\nmore than one user is logged and actively works is quite rare,\nbasically limited to some scheduled task (the equivalent of a cron\njob) running for some user while another one is logged in\ninteractively.\n\nThis might be different on machines that use Cygwin, though.\n\n> Now, it's entirely possible that a completely different database \n> implementation would be better on Windows, but our current one does a lot \n> of creating files under different names, moving them to names where \n> they'll be seen (since this is atomic under POSIX, and partial files are \n> never seen by other tasks). Also, once we have new files in place, we \n> unlink the files that they replace, so that new tasks will use the new \n> ones and tasks that already have old ones open can still get the data out \n> of them. Also, the files generally get mmaped, \n\nPerhaps mmap introduces complications (I simply don't know), but in\ngeneral, as I show elsewhere in this thread, you can do similar things\non Windows, if you use native APIs (as opposed to emulations of Posix,\nlike `open'), although you may need to rename the old file to get it\nout of the way of the new one with the same name, because otherwise\nthe old file will still be seen, even if deleted, as long as it's open\nin some process.\n"},{"id":"55967","messageId":"Pine.LNX.4.64.0710160229520.7638@iabervon.org","threadId":"10283","inReplyTo":"E1Ihfrl-0007w1-3I@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-16T07:07:12Z","receivedAt":"2007-10-16T07:07:12Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 16 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Tue, 16 Oct 2007 07:14:56 +0200\n> > From: Andreas Ericsson \n> > CC: Daniel Barkalow , raa.lkml@gmail.com, \n> > Johannes.Schindelin@gmx.de, tsuna@lrde.epita.fr, git@vger.kernel.org, \n> > make-w32@gnu.org\n> > \n> > > Sorry I'm asking potentially stupid questions out of ignorance: why\n> > > would you want readdir to return `README' when you have `readme'?\n> > > \n> > \n> > Because it might have been checked in as README, and since git is case\n> > sensitive that is what it'll think should be there when it reads the\n> > directories. If it's not, users get to see\n> > \n> > \tremoved: README\n> > \tuntracked: readme\n> \n> This is a non-issue, then: Windows filesystems are case-preserving, so\n> if `README' became `readme', someone deliberately renamed it, in which\n> case it's okay for git to react as above.\n> \n> > could be an intentional rename, but we don't know for sure.\n> \n> It _must_ have been an intentional rename. While years ago there used\n> to be old DOS programs that could cause such a rename as a side effect\n> of modifying a file, that time is long gone. There's no longer a need\n> to cater to such programs, as even DOS programs can support\n> case-preserving APIs on Windows.\n\nI'm partially worried about cases where checking out a \"README\" fails to \nreplace the name of an existing \"readme\", or something of that sort.\n\n> > To be honest though, there are so many places which do the readdir+stat\n> > that I don't think it'd be worth factoring it out\n> \n> Something for Windows users to decide, I guess. It's not hard to\n> refactor this, it just needs a motivated volunteer.\n> \n> > especially since it\n> > *works* on windows. It's just slow, and only slow compared to various\n> > unices.\n> \n> I think only the Linux filesystem is as fast as you say. But I may be\n> wrong (did someone compare with *BSD, say?).\n\nI think you're right (nothing else can compete with Linux for doing half a \nmillion trivial syscalls), but other unixes aren't terrible, either. \nIIRC, on OS X, we had problems when we were doing 4 times as many syscalls \nas necessary, but was fine with that fixed.\n\n> > I *think* (correct me if I'm wrong) that git is still faster\n> > than a whole bunch of other scm's on windows, but to one who's used to\n> > its performance on Linux that waiting several seconds to scan 10k files\n> > just feels wrong.\n> \n> Unless that 10K is a typo and you really meant 100K, I don't think 10K\n> files should take several seconds to scan on Windows. I just tried\n> \"find -print\" on a directory with 32K files in 4K subdirectories, and\n> it took 8 sec elapsed with a hot cache. So 10K files should take at\n> most 2 seconds, even without optimizing file traversal code. Doing\n> the same with native Windows system calls (\"dir /s\") brings that down\n> to 4 seconds for 32K files.\n> \n> On the other hand, what packages have 100K files? If there's only one\n> -- the Linux kernel -- then I think this kind of performance is for\n> all practical purposes unimportant on Windows, because while it is\n> reasonable to assume that someone would like to use git on Windows,\n> assuming that someone will develop the Linux kernel on Windows is --\n> how should I put it -- _really_ far-fetched ;-)\n\nActually, there are a number of projects much bigger than the Linux \nkernel; I think KDE was considering using git, and wanted Windows support, \nand KDE is insanely huge, mostly as a result of having one big repository \nfor everything.\n\n> As for speed of file ops ``just feeling wrong'': it's not limited to\n> git in any way. You will see the same with \"tar -x\", with \"find\" and\n> even with \"cp -r\", when you compare Linux filesystems, especially on a\n> fast 64-bit machine, with comparable Windows operations. A Windows\n> user who occasionally works on GNU/Linux already knows that, so seeing\n> the same in git will not come as a surprise. Again, I wonder how this\n> compares with other free OSes, like FreeBSD (unless they use the same\n> filesystem), and with proprietary Unices, like AIX and Solaris.\n\nFor most things, Unix filesystems are fast enough that the bulk of the \ntime is spent elsewhere. \"git status\" without any changes and a hot cache \nis unusual in being both a common operation and entirely trivial syscalls \nif the filesystem makes it efficient.\n\nThe problem we've had is that Linux users who occasionally work on Windows \nsay git seems impossibly slow on Windows.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"55968","messageId":"2EA3BEC9-5B13-44D3-B190-CA77499F642C@zib.de","threadId":"10283","inReplyTo":"471448D0.6080200@op5.se","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-16T07:14:03Z","receivedAt":"2007-10-16T07:14:03Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 16, 2007, at 7:14 AM, Andreas Ericsson wrote:\n\n> Eli Zaretskii wrote:\n>>> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)\n>>> From: Daniel Barkalow \n>>> cc: Alex Riesen , Johannes.Schindelin@gmx.de, \n>>> ae@op5.se, tsuna@lrde.epita.fr, git@vger.kernel.org, make- \n>>> w32@gnu.org\n>>>\n>>> I believe the hassle is that readdir doesn't necessarily report a \n>>> README in a directory which is supposed to have a README, when it \n>>> has a readme instead.\n>> Sorry I'm asking potentially stupid questions out of ignorance: why\n>> would you want readdir to return `README' when you have `readme'?\n>\n> Because it might have been checked in as README, and since git is case\n> sensitive that is what it'll think should be there when it reads the\n> directories. If it's not, users get to see\n>\n> \tremoved: README\n> \tuntracked: readme\n>\n> and there's really no easy way out of this one, since users on a case-\n> sensitive filesystem might be involved in this project too, so it\n> could be an intentional rename, but we don't know for sure. Just\n> clobbering the in-git file is wrong, but overwriting a file on disk\n> is wrong too. git tries hard to not ever lose any data for the user.\n\nMaybe we need a configuration similar to core.autocrlf (which controls\nnewline conversion) to control filename comparison and normalization?\n\nMost obviously for the case (in-)sensitivity on Windows, but I also\nremember the unicode normalization happening on Mac's HFS filesystem\nthat caused trouble in the past.\n\n\tSteffen\n"},{"id":"55970","messageId":"E1Ihgfs-0004DL-S5@fencepost.gnu.org","threadId":"10283","inReplyTo":"47145D6D.80001@viscovery.net","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T07:17:08Z","receivedAt":"2007-10-16T07:17:08Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 08:42:53 +0200\n> From: Johannes Sixt \n> Cc: Daniel Barkalow , raa.lkml@gmail.com,\n> \tJohannes.Schindelin@gmx.de, ae@op5.se,\n> \tBenoit SIGOURE ,\n> \t\"git@vger.kernel.org >> Git Mailing List\" ,\n> \tMake Windows \n> \n> Thanks to Marius Storm-Olsen we already have a stat replacement that's twice \n> as fast as msvcrt's stat. I calls only one API function \n> (GetFileAttributesEx, but of course I don't know what's going on under its \n> hood), because we need only a small part of struct stat filled in correctly.\n\nYes, I've seen that. What I'm saying is that you can combine\n`readdir' with `stat' in one API call (FindFirstFile/FindNextFile),\nwhich will both read the directory and return you the attributes you\nget from `stat'. Think about `readdir' that brings you mode bits and\nmodification time together with the name, as some modern systems do.\n"},{"id":"56006","messageId":"fcaeb9bf0710160309y51101fbaicae463a10612010c@mail.gmail.com","threadId":"10283","inReplyTo":"uprzfithw.fsf@gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-10-16T10:09:08Z","receivedAt":"2007-10-16T10:09:08Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 10/16/07, Eli Zaretskii wrote:\n> > Date: Tue, 16 Oct 2007 09:24:50 +0700\n> > From: \"Nguyen Thai Ngoc Duy\" \n> > Cc: \"Git Mailing List\" , \"Alex Riesen\" ,\n> > \"Eli Zaretskii\" , \"Andreas Ericsson\" ,\n> > tsuna@lrde.epita.fr,\n> > \"Johannes Schindelin\" \n> >\n> > I did try hard to find the legendary\n> > zsh for Windows before giving up and porting busybox's ash instead.\n>\n> Where can one find this port of busybox's ash?\n>\n\nhttp://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox\n\nIn directory box/shell.\n-- \nDuy\n"},{"id":"56015","messageId":"Pine.LNX.4.64.0710161209190.8571@ds9.cixit.se","threadId":"10283","inReplyTo":"20071014221446.GC2776@steel.home","subject":"Re: Switching from CVS to GIT","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-16T11:13:49Z","receivedAt":"2007-10-16T11:13:49Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"> - it is the only OS in the world with multi-root (/a/b/c and /a/b/c\n> can be not the same, depending on what current \"drive\" is) and\n> multi-cwd, which hasn't had formed itself into a problem yet, but\n> surely will\n\nIt's not the only OS with drive letters (although I don't see Git\ncoming to my Symbian OS phone any time soon), but there is only one\nroot. The problem is that it isn't addressable in the file system, and\nthat the concept of what is the root is different depending on what you\nask (either it's above the drive letters, or \"My Computer\").\n\nYou can create a search path rooted in \"My Computer\" if you want (using\nshell APIs), but you probably can't get a readable text representation\nof it.\n\n> - it has only one argument (limited in size) passed to started\n> programs, which means that there is no possible way to safely pass\n> file and text arguments on command line (more than one, that is)\n\nWell, there are many other ways of passing arguments than on the\ncommand line, but they are probably difficult to access from console\napplications (things like DDE or whatever the current implementation is\ncalled).\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"56020","messageId":"E1IhlNu-00071d-0v@fencepost.gnu.org","threadId":"10283","inReplyTo":"fcaeb9bf0710160309y51101fbaicae463a10612010c@mail.gmail.com","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T12:18:54Z","receivedAt":"2007-10-16T12:18:54Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 17:09:08 +0700\n> From: \"Nguyen Thai Ngoc Duy\" \n> Cc: prohaska@zib.de, git@vger.kernel.org, raa.lkml@gmail.com, ae@op5.se, \n> \ttsuna@lrde.epita.fr, Johannes.Schindelin@gmx.de\n> \n> > Where can one find this port of busybox's ash?\n> >\n> \n> http://repo.or.cz/w/git/pclouds.git?a=shortlog;h=gitbox\n> \n> In directory box/shell.\n\nThanks!\n"},{"id":"56022","messageId":"Pine.LNX.4.64.0710161324490.25221@racer.site","threadId":"10283","inReplyTo":"E1Ihfrl-0007w1-3I@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T12:29:41Z","receivedAt":"2007-10-16T12:29:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[by explicit request culling make-w32 from the Cc list]\n\nOn Tue, 16 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Tue, 16 Oct 2007 07:14:56 +0200\n> > From: Andreas Ericsson \n> > CC: Daniel Barkalow , raa.lkml@gmail.com, \n> > Johannes.Schindelin@gmx.de, tsuna@lrde.epita.fr, git@vger.kernel.org, \n> > make-w32@gnu.org\n> > \n> > > Sorry I'm asking potentially stupid questions out of ignorance: why\n> > > would you want readdir to return `README' when you have `readme'?\n> > > \n> > \n> > Because it might have been checked in as README, and since git is case\n> > sensitive that is what it'll think should be there when it reads the\n> > directories. If it's not, users get to see\n> > \n> > \tremoved: README\n> > \tuntracked: readme\n> \n> This is a non-issue, then: Windows filesystems are case-preserving, so \n> if `README' became `readme', someone deliberately renamed it, in which \n> case it's okay for git to react as above.\n\nNo, it is not. On FAT filesystems, for example, I experienced Windows \nhappily naming a file \"head\" which was created under then name \"HEAD\".\n\nThis is the single reason why I cannot have non-bare repositories on a USB \nstick.\n\n> > could be an intentional rename, but we don't know for sure.\n> \n> It _must_ have been an intentional rename.\n\nNo. It can also be the output of a program which deletes the file first, \nand then (since the filesystem is so \"conveniently\" case insensitive) \ncreates it again, with a lowercase filename.\n\nAnd don't you tell me that there are no such programs. I have to use \nthem, and they are closed source.\n\nSigh.\n\n> > To be honest though, there are so many places which do the \n> > readdir+stat that I don't think it'd be worth factoring it out\n> \n> Something for Windows users to decide, I guess. It's not hard to \n> refactor this, it just needs a motivated volunteer.\n\nYou?\n\n> > I *think* (correct me if I'm wrong) that git is still faster\n> > than a whole bunch of other scm's on windows, but to one who's used to\n> > its performance on Linux that waiting several seconds to scan 10k files\n> > just feels wrong.\n> \n> Unless that 10K is a typo and you really meant 100K, I don't think 10K\n> files should take several seconds to scan on Windows. I just tried\n> \"find -print\" on a directory with 32K files in 4K subdirectories, and\n> it took 8 sec elapsed with a hot cache. So 10K files should take at\n> most 2 seconds, even without optimizing file traversal code. Doing\n> the same with native Windows system calls (\"dir /s\") brings that down\n> to 4 seconds for 32K files.\n\nOn Linux, I would have hit Control-C already. Such an operation typically \ntakes less than 0.1 seconds.\n\n> On the other hand, what packages have 100K files?\n\nMozilla, KDE, OpenOffice.org, X.org, ....\n\nCiao,\nDscho\n"},{"id":"56023","messageId":"Pine.LNX.4.64.0710161331440.25221@racer.site","threadId":"10283","inReplyTo":"2EA3BEC9-5B13-44D3-B190-CA77499F642C@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T12:33:22Z","receivedAt":"2007-10-16T12:33:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[culled make-w32 list by explicit request]\n\nOn Tue, 16 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 16, 2007, at 7:14 AM, Andreas Ericsson wrote:\n> \n> > Eli Zaretskii wrote:\n> > > > Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)\n> > > > From: Daniel Barkalow \n> > > > cc: Alex Riesen , Johannes.Schindelin@gmx.de,\n> > > > ae@op5.se, tsuna@lrde.epita.fr, git@vger.kernel.org,\n> > > > make-w32@gnu.org\n> > > > \n> > > > I believe the hassle is that readdir doesn't necessarily report a \n> > > > README in a directory which is supposed to have a README, when it \n> > > > has a readme instead.\n> > > Sorry I'm asking potentially stupid questions out of ignorance: why \n> > > would you want readdir to return `README' when you have `readme'?\n> > \n> > Because it might have been checked in as README, and since git is case \n> > sensitive that is what it'll think should be there when it reads the \n> > directories. If it's not, users get to see\n> > \n> > \tremoved: README\n> > \tuntracked: readme\n> > \n> > and there's really no easy way out of this one, since users on a case- \n> > sensitive filesystem might be involved in this project too, so it \n> > could be an intentional rename, but we don't know for sure. Just \n> > clobbering the in-git file is wrong, but overwriting a file on disk is \n> > wrong too. git tries hard to not ever lose any data for the user.\n> \n> Maybe we need a configuration similar to core.autocrlf (which controls \n> newline conversion) to control filename comparison and normalization?\n> \n> Most obviously for the case (in-)sensitivity on Windows, but I also \n> remember the unicode normalization happening on Mac's HFS filesystem \n> that caused trouble in the past.\n\nRobin Rosenberg has some preliminary code for that. The idea is to wrap \nall filesystem operations in cache.h, and do a filename normalisation \nfirst.\n\nCiao,\nDscho\n"},{"id":"56025","messageId":"Pine.LNX.4.64.0710161335500.8571@ds9.cixit.se","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161324490.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Peter Karlsson","fromEmail":"peter@softwolves.pp.se","sentAt":"2007-10-16T12:38:59Z","receivedAt":"2007-10-16T12:38:59Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"> No, it is not. On FAT filesystems, for example, I experienced Windows \n> happily naming a file \"head\" which was created under then name \"HEAD\".\n\nIf you create a file name with only capital letters, I believe Explorer\nand the file browser will display the name with an initial capital, and\nthe rest lowercase, or in all lowercase. IIRC, this is because such a\nfile is saved with only an MS-DOS name and no LFN entry, and those have\nspecial rules to avoid them being displayed in all-uppercase.\n\nI believe it is possible to create a LFN entry for such a file, but I\ncan't remember right now how to do it.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"56026","messageId":"Pine.LNX.4.64.0710161335260.25221@racer.site","threadId":"10283","inReplyTo":"E1IhgT2-0000bg-O6@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T12:39:12Z","receivedAt":"2007-10-16T12:39:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[culled make-w32, as per explicit request]\n\nOn Tue, 16 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)\n> > From: Daniel Barkalow \n> > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se, \n> > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n> > \n> > Ah, that's helpful. We don't actually care too much about the \n> > particular info in stat; we just want to know quickly if the file has \n> > changed, so we can hash only the ones that have been touched and get \n> > the actual content changes.\n> \n> As I wrote in my other message, using native APIs improves performance \n> by at least a factor of two.\n\nSomehow this does not appeal to my \"portability is good\" side. You know, \nif we had to do such trickeries for every platform we support, we'd soon \nbe as big as Subversion *cough*.\n\nFor me, this is the most annoying part about programming Win32. They went \nout of their way to make it incompatible with everything else, and as a \nconsequence it is a PITA to maintain crossplatform programs.\n\n> > The tricky thing is that, while the optimization process is running, \n> > other programs may be reading the database, so (1) the files that are \n> > no longer needed, because better-optimized versions are in place, may \n> > be open in another task\n> \n> Is this because another user might be accessing the database, or are \n> there other popular use cases that cause this? If the former, then this \n> is not terribly important on Windows, since the situation when more than \n> one user is logged and actively works is quite rare, basically limited \n> to some scheduled task (the equivalent of a cron job) running for some \n> user while another one is logged in interactively.\n\nQuite to the contrary. Explorer often accesses files it should not lock. \nOn the machine I test msysGit on, this is the most common reason for a \ntest case to fail: it cannot delete the temporary directory, which \n_should_ be unused. Indeed, a second after that, it _is_ unused.\n\nCiao,\nDscho\n"},{"id":"56031","messageId":"86sl4bjkef.fsf@lola.quinscape.zz","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161335260.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-16T12:47:52Z","receivedAt":"2007-10-16T12:47:52Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> [culled make-w32, as per explicit request]\n>\n> On Tue, 16 Oct 2007, Eli Zaretskii wrote:\n>\n>> > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)\n>> > From: Daniel Barkalow \n>> > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se, \n>> > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n>> > \n>> > Ah, that's helpful. We don't actually care too much about the \n>> > particular info in stat; we just want to know quickly if the file has \n>> > changed, so we can hash only the ones that have been touched and get \n>> > the actual content changes.\n>> \n>> As I wrote in my other message, using native APIs improves\n>> performance by at least a factor of two.\n>\n> Somehow this does not appeal to my \"portability is good\" side. You\n> know, if we had to do such trickeries for every platform we support,\n> we'd soon be as big as Subversion *cough*.\n\nWith a reasonable way of factoring out things, the per-platform\noverhead should be tolerable.\n\n> For me, this is the most annoying part about programming Win32.\n> They went out of their way to make it incompatible with everything\n> else, and as a consequence it is a PITA to maintain crossplatform\n> programs.\n\nWell, they certainly score high on the \"almost, but not quite,\nentirely unlike tea\" metric. Enough compatibility to make it into\nprojects with cross-platform specifications, and enough\nincompatibility to make it inconvenient to support anything but\nWindows once they made it into the door.\n\n-- \nDavid Kastrup\n"},{"id":"56027","messageId":"E1IhlvV-0002qv-1K@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161324490.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T12:53:37Z","receivedAt":"2007-10-16T12:53:37Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 13:29:41 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Andreas Ericsson , barkalow@iabervon.org, raa.lkml@gmail.com, \n> tsuna@lrde.epita.fr, git@vger.kernel.org\n> \n> > > \tremoved: README\n> > > \tuntracked: readme\n> > \n> > This is a non-issue, then: Windows filesystems are case-preserving, so \n> > if `README' became `readme', someone deliberately renamed it, in which \n> > case it's okay for git to react as above.\n> \n> No, it is not. On FAT filesystems, for example, I experienced Windows \n> happily naming a file \"head\" which was created under then name \"HEAD\".\n\nWhat program did that, and how did you see that the file was named\n\"head\" instead of \"HEAD\"? (The latter question is because Explorer,\nfor example, does not show the file names exactly like they are\nwritten in the directory, it capitalises them. But this is\napplication-level code; in the directory the file names are written\nlike you gave them in the argument to whatever \"create file\" API you\nused.\n\n> No. It can also be the output of a program which deletes the file first, \n> and then (since the filesystem is so \"conveniently\" case insensitive) \n> creates it again, with a lowercase filename.\n> \n> And don't you tell me that there are no such programs. I have to use \n> them, and they are closed source.\n\nCan you name them?\n\n> > Something for Windows users to decide, I guess. It's not hard to \n> > refactor this, it just needs a motivated volunteer.\n> \n> You?\n\nMaybe some day.\n\n> > Unless that 10K is a typo and you really meant 100K, I don't think 10K\n> > files should take several seconds to scan on Windows. I just tried\n> > \"find -print\" on a directory with 32K files in 4K subdirectories, and\n> > it took 8 sec elapsed with a hot cache. So 10K files should take at\n> > most 2 seconds, even without optimizing file traversal code. Doing\n> > the same with native Windows system calls (\"dir /s\") brings that down\n> > to 4 seconds for 32K files.\n> \n> On Linux, I would have hit Control-C already. Such an operation typically \n> takes less than 0.1 seconds.\n\nWe were not comparing Linux with Windows, we were talking about\nWindows user experience. On Windows 4 seconds is not too long.\n"},{"id":"56032","messageId":"86odezjjv1.fsf@lola.quinscape.zz","threadId":"10283","inReplyTo":"E1IhlvV-0002qv-1K@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-16T12:59:30Z","receivedAt":"2007-10-16T12:59:30Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Eli Zaretskii writes:\n\n>> Date: Tue, 16 Oct 2007 13:29:41 +0100 (BST)\n>> From: Johannes Schindelin \n>> \n>> On Linux, I would have hit Control-C already. Such an operation\n>> typically takes less than 0.1 seconds.\n>\n> We were not comparing Linux with Windows, we were talking about\n> Windows user experience. On Windows 4 seconds is not too long.\n\nIf it is accompanied by some animation of papers winging across the\nscreen or a progress bar or similar. Otherwise people might think\nthat Windows crashed and reboot.\n\nAnyway, the problem is that 4 seconds for 32K files means 40 seconds\n(at least) for 320K files. At some point of time, things become\nreally unpleasant.\n\n-- \nDavid Kastrup\n"},{"id":"56028","messageId":"E1Ihm5Y-0005kT-AU@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161335500.8571@ds9.cixit.se","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T13:04:00Z","receivedAt":"2007-10-16T13:04:00Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 13:38:59 +0100 (CET)\n> From: Peter Karlsson \n> cc: Eli Zaretskii , Andreas Ericsson ,\n> barkalow@iabervon.org, raa.lkml@gmail.com, tsuna@lrde.epita.fr,\n> git@vger.kernel.org\n> \n> If you create a file name with only capital letters, I believe Explorer\n> and the file browser will display the name with an initial capital, and\n> the rest lowercase, or in all lowercase.\n\nThat's true, but the names are only displayed like that, what's on\ndisk is not changed in any way.\n\n> IIRC, this is because such a\n> file is saved with only an MS-DOS name and no LFN entry, and those have\n> special rules to avoid them being displayed in all-uppercase.\n\nI don't think this true anymore in modern versions of Windows, but I\nmight be mistaken. In any case, the reason for the Explorer behavior\nis immaterial for us, what matters is that file names on disk preserve\nthe lettercase of the program that created them, at least AFAIK.\n"},{"id":"56034","messageId":"Pine.LNX.4.64.0710161414270.25221@racer.site","threadId":"10283","inReplyTo":"E1IhlvV-0002qv-1K@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T13:15:56Z","receivedAt":"2007-10-16T13:15:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Tue, 16 Oct 2007 13:29:41 +0100 (BST)\n> > From: Johannes Schindelin \n> > cc: Andreas Ericsson , barkalow@iabervon.org, raa.lkml@gmail.com, \n> > tsuna@lrde.epita.fr, git@vger.kernel.org\n> > \n> > > > \tremoved: README\n> > > > \tuntracked: readme\n> > > \n> > > This is a non-issue, then: Windows filesystems are case-preserving, so \n> > > if `README' became `readme', someone deliberately renamed it, in which \n> > > case it's okay for git to react as above.\n> > \n> > No, it is not. On FAT filesystems, for example, I experienced Windows \n> > happily naming a file \"head\" which was created under then name \"HEAD\".\n> \n> What program did that, and how did you see that the file was named\n> \"head\" instead of \"HEAD\"?\n\nGit and ... Git.\n\n> > > Something for Windows users to decide, I guess. It's not hard to \n> > > refactor this, it just needs a motivated volunteer.\n> > \n> > You?\n> \n> Maybe some day.\n\nCool.\n\n> > > Unless that 10K is a typo and you really meant 100K, I don't think \n> > > 10K files should take several seconds to scan on Windows. I just \n> > > tried \"find -print\" on a directory with 32K files in 4K \n> > > subdirectories, and it took 8 sec elapsed with a hot cache. So 10K \n> > > files should take at most 2 seconds, even without optimizing file \n> > > traversal code. Doing the same with native Windows system calls \n> > > (\"dir /s\") brings that down to 4 seconds for 32K files.\n> > \n> > On Linux, I would have hit Control-C already. Such an operation \n> > typically takes less than 0.1 seconds.\n> \n> We were not comparing Linux with Windows, we were talking about Windows \n> user experience. On Windows 4 seconds is not too long.\n\nWell, I was talking about user experience. In this case of a user who \nhappens to be on Windows, but knows Linux' speed.\n\nCiao,\nDscho\n"},{"id":"56033","messageId":"4D822762-D344-465E-B77D-90A64D61F5A9@zib.de","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161331440.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-16T13:16:04Z","receivedAt":"2007-10-16T13:16:04Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 16, 2007, at 2:33 PM, Johannes Schindelin wrote:\n\n>> Maybe we need a configuration similar to core.autocrlf (which \n>> controls\n>> newline conversion) to control filename comparison and normalization?\n>>\n>> Most obviously for the case (in-)sensitivity on Windows, but I also\n>> remember the unicode normalization happening on Mac's HFS filesystem\n>> that caused trouble in the past.\n>\n> Robin Rosenberg has some preliminary code for that. The idea is to \n> wrap\n> all filesystem operations in cache.h, and do a filename normalisation\n> first.\n\nAt that point we could add a safety check. Paths that differ only by\ncase, or whitespace, or ... (add general and project specific rules \nhere)\nshould be denied. This would guarantee that tree objects can always be\nchecked out. Even if the filesystem capabilities are limited.\n\nRobin, what do you think?\n\n\tSteffen\n"},{"id":"56035","messageId":"E1IhmHM-0002hB-HR@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161335260.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T13:16:12Z","receivedAt":"2007-10-16T13:16:12Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 13:39:12 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Daniel Barkalow , raa.lkml@gmail.com, ae@op5.se, \n> tsuna@lrde.epita.fr, git@vger.kernel.org\n> \n> > As I wrote in my other message, using native APIs improves performance \n> > by at least a factor of two.\n> \n> Somehow this does not appeal to my \"portability is good\" side. You know, \n> if we had to do such trickeries for every platform we support, we'd soon \n> be as big as Subversion *cough*.\n\nYou have to decide whether you care about performance enough to do\nthat or not. If you do, then introducing file I/O abstractions at\nhigher level than the normal ``use-library-functions'' method is not\nsuch a hard problem, and doesn't make the binary larger because each\nplatform gets only its own backend. In practice, I have found that in\nmost cases a few well-designed and strategically placed macros is all\nyou need.\n\n> For me, this is the most annoying part about programming Win32. They went \n> out of their way to make it incompatible with everything else, and as a \n> consequence it is a PITA to maintain crossplatform programs.\n\nPortability is a two-way street. A program that wasn't designed to be\nportable will by definition be hard to port. To me, what's annoying\nis a program that was designed around a single-OS model of APIs.\n\nCross-platform programs are not that hard if you design them to be\nlike that from the ground up. I'm working for a firm that does that\nfor a living: we develop software that compiles and runs on Windows\nand Linux from the same source.\n\n> Explorer often accesses files it should not lock. \n> On the machine I test msysGit on, this is the most common reason for a \n> test case to fail: it cannot delete the temporary directory, which \n> _should_ be unused. Indeed, a second after that, it _is_ unused.\n\nOne more reason not to launch Explorer, if you ask me ;-) But maybe\nyou have valid reasons to do that. All I can say is that I never saw\nsuch problems, but then I don't usually run programs that rewrite\nfiles in a frenzy.\n"},{"id":"56038","messageId":"Pine.LNX.4.64.0710161419140.25221@racer.site","threadId":"10283","inReplyTo":"4D822762-D344-465E-B77D-90A64D61F5A9@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T13:21:52Z","receivedAt":"2007-10-16T13:21:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 16, 2007, at 2:33 PM, Johannes Schindelin wrote:\n> \n> > > Maybe we need a configuration similar to core.autocrlf (which controls\n> > > newline conversion) to control filename comparison and normalization?\n> > > \n> > > Most obviously for the case (in-)sensitivity on Windows, but I also\n> > > remember the unicode normalization happening on Mac's HFS filesystem\n> > > that caused trouble in the past.\n> > \n> > Robin Rosenberg has some preliminary code for that. The idea is to wrap\n> > all filesystem operations in cache.h, and do a filename normalisation\n> > first.\n> \n> At that point we could add a safety check. Paths that differ only by\n> case, or whitespace, or ... (add general and project specific rules here)\n> should be denied. This would guarantee that tree objects can always be\n> checked out. Even if the filesystem capabilities are limited.\n\nThis would be an independent change. The method I talked about only ever \nlooks at one filename, never what is already there.\n\nWhat you want would probably be all too easy with a pre-commit hook. No \nneed to clutter the git-core with code that is usually not needed (you'd \nonly ever activate it on Linux when other developers use Windows or \nMacOSX).\n\nCiao,\nDscho\n"},{"id":"56040","messageId":"Pine.LNX.4.64.0710161422110.25221@racer.site","threadId":"10283","inReplyTo":"E1IhmHM-0002hB-HR@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T13:24:34Z","receivedAt":"2007-10-16T13:24:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Tue, 16 Oct 2007 13:39:12 +0100 (BST)\n> > From: Johannes Schindelin \n> > cc: Daniel Barkalow , raa.lkml@gmail.com, ae@op5.se, \n> > tsuna@lrde.epita.fr, git@vger.kernel.org\n> > \n> > > As I wrote in my other message, using native APIs improves \n> > > performance by at least a factor of two.\n> > \n> > Somehow this does not appeal to my \"portability is good\" side. You \n> > know, if we had to do such trickeries for every platform we support, \n> > we'd soon be as big as Subversion *cough*.\n> \n> You have to decide whether you care about performance enough to do\n> that or not.\n\nYes, I know that we'll have to use more special casing of Windows for \nperformance reasons. I was only lamenting that it would not need to be \nthat way. Just ignore me.\n\n> > For me, this is the most annoying part about programming Win32. They \n> > went out of their way to make it incompatible with everything else, \n> > and as a consequence it is a PITA to maintain crossplatform programs.\n> \n> Portability is a two-way street. A program that wasn't designed to be \n> portable will by definition be hard to port. To me, what's annoying is \n> a program that was designed around a single-OS model of APIs.\n\nYou're obviously not talking about git here.\n\n> > Explorer often accesses files it should not lock. On the machine I \n> > test msysGit on, this is the most common reason for a test case to \n> > fail: it cannot delete the temporary directory, which _should_ be \n> > unused. Indeed, a second after that, it _is_ unused.\n> \n> One more reason not to launch Explorer, if you ask me ;-) But maybe you \n> have valid reasons to do that. All I can say is that I never saw such \n> problems, but then I don't usually run programs that rewrite files in a \n> frenzy.\n\nFunny. Last time I checked the toolbar went away, as well as the desktop, \nwhen I killed explorer.exe.\n\nCiao,\nDscho\n"},{"id":"56041","messageId":"26554F2D-B44D-4691-A696-9B6924E08599@zib.de","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161419140.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-16T13:50:18Z","receivedAt":"2007-10-16T13:50:18Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 16, 2007, at 3:21 PM, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Tue, 16 Oct 2007, Steffen Prohaska wrote:\n>\n>> On Oct 16, 2007, at 2:33 PM, Johannes Schindelin wrote:\n>>\n>>>> Maybe we need a configuration similar to core.autocrlf (which \n>>>> controls\n>>>> newline conversion) to control filename comparison and \n>>>> normalization?\n>>>>\n>>>> Most obviously for the case (in-)sensitivity on Windows, but I also\n>>>> remember the unicode normalization happening on Mac's HFS \n>>>> filesystem\n>>>> that caused trouble in the past.\n>>>\n>>> Robin Rosenberg has some preliminary code for that. The idea is \n>>> to wrap\n>>> all filesystem operations in cache.h, and do a filename \n>>> normalisation\n>>> first.\n>>\n>> At that point we could add a safety check. Paths that differ only by\n>> case, or whitespace, or ... (add general and project specific \n>> rules here)\n>> should be denied. This would guarantee that tree objects can \n>> always be\n>> checked out. Even if the filesystem capabilities are limited.\n>\n> This would be an independent change. The method I talked about \n> only ever\n> looks at one filename, never what is already there.\n\nOh, hmm ... obviously, ... if I think about it ;)\n\n\n> What you want would probably be all too easy with a pre-commit \n> hook. No\n> need to clutter the git-core with code that is usually not needed \n> (you'd\n> only ever activate it on Linux when other developers use Windows or\n> MacOSX).\n\nPersonally, I'd be very happy if git enforced the minimal consent \nbetween\n(supported) filesystems and provided a system to guarantee that I can \nonly\ncreate tree objects that can be checked out on all (supported) \nfilesystems.\n\nI'd _always_ switch on such a mechanism. I think the idea of relying on\nfilenames that only differ by whitespace or case is insane \nindependent of\nthe capabilities of the filesystem used. Humans hardly see such \ndifferences.\nThere may be other characters that should be avoided purely for \ntechnical reasons. If git checked this, too, I'd be happy.\n\nAn update hook is only very loosely coupled to git. I'd prefer a tighter\nintegration. 'git add ' should immediately report the \nproblem.\nBut, maybe I'll try a commit hook first.\n\n\tSteffen\n"},{"id":"56042","messageId":"Pine.LNX.4.64.0710161512450.25221@racer.site","threadId":"10283","inReplyTo":"26554F2D-B44D-4691-A696-9B6924E08599@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T14:14:19Z","receivedAt":"2007-10-16T14:14:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Steffen Prohaska wrote:\n\n> On Oct 16, 2007, at 3:21 PM, Johannes Schindelin wrote:\n> \n> > What you want would probably be all too easy with a pre-commit hook. \n> > No need to clutter the git-core with code that is usually not needed \n> > (you'd only ever activate it on Linux when other developers use \n> > Windows or MacOSX).\n> \n> Personally, I'd be very happy if git enforced the minimal consent \n> between (supported) filesystems and provided a system to guarantee that \n> I can only create tree objects that can be checked out on all \n> (supported) filesystems.\n\nThis will not happen. In the Linux kernel, there were exactly such cases, \nwhere the filenames differed only in case.\n\nAlso, some projects I checked out (notably Perl) assume that Makefile is \ndifferent from makefile.\n\nSo I think this will always be something Windows users would wish to \nimpose onto others, while Linux users would always refuse.\n\nCiao,\nDscho\n"},{"id":"56043","messageId":"F17B71A6-879A-4036-908E-A74433BC39ED@zib.de","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161512450.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-16T14:36:31Z","receivedAt":"2007-10-16T14:36:31Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 16, 2007, at 4:14 PM, Johannes Schindelin wrote:\n\n> On Tue, 16 Oct 2007, Steffen Prohaska wrote:\n>\n>> On Oct 16, 2007, at 3:21 PM, Johannes Schindelin wrote:\n>>\n>>> What you want would probably be all too easy with a pre-commit hook.\n>>> No need to clutter the git-core with code that is usually not needed\n>>> (you'd only ever activate it on Linux when other developers use\n>>> Windows or MacOSX).\n>>\n>> Personally, I'd be very happy if git enforced the minimal consent\n>> between (supported) filesystems and provided a system to guarantee \n>> that\n>> I can only create tree objects that can be checked out on all\n>> (supported) filesystems.\n>\n> This will not happen. In the Linux kernel, there were exactly such \n> cases,\n> where the filenames differed only in case.\n>\n> Also, some projects I checked out (notably Perl) assume that \n> Makefile is\n> different from makefile.\n\nweird Linux and Perl world, indeed.\n\n\n> So I think this will always be something Windows users\n\nand Mac users, who also need to deal with a case-preserving,\nbut case-insensitive filesystem.\n\n> would wish to\n> impose onto others, while Linux users would always refuse.\n\nmaybe Linux kernel developers. When I work on Linux, I'd be happy\nif git saved me from creating directories containing Readme and\nreadme at the same time.\n\n\tSteffen\n"},{"id":"56057","messageId":"E1Ihnvq-0002Xr-F9@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161422110.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T15:02:06Z","receivedAt":"2007-10-16T15:02:06Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 14:24:34 +0100 (BST)\n> From: Johannes Schindelin \n> cc: barkalow@iabervon.org, raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, \n> git@vger.kernel.org\n> \n> Funny. Last time I checked the toolbar went away, as well as the desktop, \n> when I killed explorer.exe.\n\nThat's a ``feature'': Explorer is the parent of all the desktop\ndisplay. Kinda like the login shell on Unix: if you kill it, there\ngoes your whole session. Except that on Windows, the OS pays\nattention and restarts Explorer right away to get you back in\nbusiness. (In first versions of Windows, there was no restarting of\nExplorer, so if you killed it, you needed to reboot :-()\n"},{"id":"56059","messageId":"E1Iho67-0005iX-5W@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161512450.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T15:12:43Z","receivedAt":"2007-10-16T15:12:43Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 15:14:19 +0100 (BST)\n> From: Johannes Schindelin \n> cc: Git Mailing List , \n> Robin Rosenberg , \n> Eli Zaretskii , Daniel Barkalow , \n> Alex Riesen , tsuna@lrde.epita.fr, \n> Andreas Ericsson \n> \n> So I think this will always be something Windows users would wish to \n> impose onto others, while Linux users would always refuse.\n\nHere is one Windows user that will never try to impose that ;-)\n\nHowever, it's possible that an option could be supported to do that\nwhen the user particularly wants that in her database. Just a\nthought...\n"},{"id":"56060","messageId":"Pine.LNX.4.64.0710161616150.25221@racer.site","threadId":"10283","inReplyTo":"471455ED.8070408@viscovery.net","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T15:16:54Z","receivedAt":"2007-10-16T15:16:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Johannes Sixt wrote:\n\n> Shawn O. Pearce schrieb:\n> > Johannes Sixt wrote:\n> > > Unfortunately, \"Fetch\" does not yet work[*] from within git-gui, so you\n> > > have to fall back to git-fetch on the command line.\n> > > \n> > > [*] Note the distinction between \"not available\" and \"does not work\".\n> > \n> > What's broken? Is this that Git protocol dump showing up in\n> > git-gui's console window thing?\n> > \n> > Are you using the C based fetch that is in git.git's next branch,\n> > or the shell script based one that is in master? Which Tcl/Tk\n> > version are you using to run git-gui?\n> \n> It's the scripted fetch that does not work. The symptom is that the output of\n> at least one of the commands (upload-pack, I think, because what I see is\n> wire protocol) goes to a newly spawned console instead of wherever it was\n> redirected to.\n> \n> I didn't bother reporting since builtin-fetch is on the way (which will\n> hopefully make this a moot point) and our team here is comfortable with\n> calling git fetch on the command line.\n\nNote that Issue 57 on msysgit.googlecode.com talks exactly about the same \nissue.\n\nCiao,\nDscho\n"},{"id":"56061","messageId":"Pine.LNX.4.64.0710161617490.25221@racer.site","threadId":"10283","inReplyTo":"E1Ihnvq-0002Xr-F9@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-16T15:18:10Z","receivedAt":"2007-10-16T15:18:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Oct 2007, Eli Zaretskii wrote:\n\n> > Date: Tue, 16 Oct 2007 14:24:34 +0100 (BST)\n> > From: Johannes Schindelin \n> > cc: barkalow@iabervon.org, raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, \n> > git@vger.kernel.org\n> > \n> > Funny. Last time I checked the toolbar went away, as well as the desktop, \n> > when I killed explorer.exe.\n> \n> That's a ``feature'': Explorer is the parent of all the desktop\n> display. Kinda like the login shell on Unix: if you kill it, there\n> goes your whole session. Except that on Windows, the OS pays\n> attention and restarts Explorer right away to get you back in\n> business. (In first versions of Windows, there was no restarting of\n> Explorer, so if you killed it, you needed to reboot :-()\n\nI kinda knew that. But what's now with your recommendation to never run \nExplorer?\n\nCiao,\nDscho\n"},{"id":"56065","messageId":"E1IhoZT-0005cj-6w@fencepost.gnu.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161617490.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Eli Zaretskii","fromEmail":"eliz@gnu.org","sentAt":"2007-10-16T15:43:03Z","receivedAt":"2007-10-16T15:43:03Z","isPatch":false,"sender":{"key":"eliz@gnu.org","avatar":null},"body":"> Date: Tue, 16 Oct 2007 16:18:10 +0100 (BST)\n> From: Johannes Schindelin \n> cc: barkalow@iabervon.org, raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, \n> git@vger.kernel.org\n> \n> > That's a ``feature'': Explorer is the parent of all the desktop\n> > display. Kinda like the login shell on Unix: if you kill it, there\n> > goes your whole session. Except that on Windows, the OS pays\n> > attention and restarts Explorer right away to get you back in\n> > business. (In first versions of Windows, there was no restarting of\n> > Explorer, so if you killed it, you needed to reboot :-()\n> \n> I kinda knew that. But what's now with your recommendation to never run \n> Explorer?\n\nI meant not to open \"My Computer\" and use the GUI for browsing the\ndirectories. If you meant that the touching of files is done even if\nyou don't open the GUI, then just ignore my advice: Explorer cannot be\nkilled. I'm surprised that it touches files and directories,\nthough...\n"},{"id":"56067","messageId":"03e101c8100b$de7fa0d0$2e08a8c0@CAM.ARTIMI.COM","threadId":"10283","inReplyTo":"E1Ihfrl-0007w1-3I@fencepost.gnu.org","subject":"RE: Switching from CVS to GIT","fromName":"Dave Korn","fromEmail":"dave.korn@artimi.com","sentAt":"2007-10-16T15:47:31Z","receivedAt":"2007-10-16T15:47:31Z","isPatch":false,"sender":{"key":"dave.korn@artimi.com","avatar":null},"body":"On 16 October 2007 07:25, Eli Zaretskii wrote:\n\n> On the other hand, what packages have 100K files? If there's only one\n> -- the Linux kernel -- then I think this kind of performance is for\n> all practical purposes unimportant on Windows, because while it is\n> reasonable to assume that someone would like to use git on Windows,\n> assuming that someone will develop the Linux kernel on Windows is --\n> how should I put it -- _really_ far-fetched ;-)\n\n Hi there! Did someone call?\n\n Cross-development in general isn't what I'd call \"far-fetched\", and there's\nno law of cross-development that says the host has to be the same platform as\nthe target. :-)[*]\n\n cheers,\n DaveK\n\n[*] - this smiley sponsored by the Department of the Bleedin' Obvious.\n-- \nCan't think of a witty .sigline today....\n\n\nIndex: firmware_class.c\n===================================================================\nRCS file: /sources/repository/external_source/linux/linux-2.6.12.2/drivers/base/firmware_class.c,v\nretrieving revision 1.1\nretrieving revision 1.2\ndiff -p -u -r1.1 -r1.2\n--- firmware_class.c\t17 Jan 2006 16:49:35 -0000\t1.1\n+++ firmware_class.c\t15 Feb 2006 14:01:29 -0000\t1.2\n@@ -31,6 +31,7 @@ enum {\n };\n \n static int loading_timeout = 10;\t/* In seconds */\n+static char grow_faster = 1; /* Boolean */\n \n /* fw_lock could be moved to 'struct firmware_priv' but since it is just\n * guarding for corner cases a global lock should be OK */\n@@ -79,6 +80,28 @@ firmware_timeout_store(struct class *cla\n \n static CLASS_ATTR(timeout, 0644, firmware_timeout_show, firmware_timeout_store);\n \n+static ssize_t\n+firmware_grow_faster_show(struct class *class, char *buf)\n+{\n+\treturn sprintf(buf, \"%d\\n\", grow_faster);\n+}\n+\n+/**\n+ * firmware_grow_faster_store:\n+ * Description:\n+ *\tSets or clears a flag that causes the reallocate routine to\n+ *\tgrow the firmware buffer size more or less quickly.\n+ * \n+ **/\n+static ssize_t\n+firmware_grow_faster_store(struct class *class, const char *buf, size_t count)\n+{\n+\tgrow_faster = simple_strtol(buf, NULL, 10) != 0;\n+\treturn count;\n+}\n+\n+static CLASS_ATTR(grow_faster, 0644, firmware_grow_faster_show, firmware_grow_faster_store);\n+\n static void fw_class_dev_release(struct class_device *class_dev);\n int firmware_class_hotplug(struct class_device *dev, char **envp,\n \t\t\t int num_envp, char *buffer, int buffer_size);\n@@ -198,18 +221,27 @@ static int\n fw_realloc_buffer(struct firmware_priv *fw_priv, int min_size)\n {\n \tu8 *new_data;\n+ int new_size;\n \n \tif (min_size <= fw_priv->alloc_size)\n \t\treturn 0;\n \n-\tnew_data = vmalloc(fw_priv->alloc_size + PAGE_SIZE);\n+#define ONE_MEG (1024 * 1024)\n+\n+ new_size = grow_faster \n+ ? ((fw_priv->alloc_size >= ONE_MEG)\n+ ? (fw_priv->alloc_size + ONE_MEG)\n+ : ((fw_priv->alloc_size >= PAGE_SIZE) ? (fw_priv->alloc_size * 2) : PAGE_SIZE))\n+ : (fw_priv->alloc_size + PAGE_SIZE);\n+ new_data = vmalloc (new_size);\n \tif (!new_data) {\n-\t\tprintk(KERN_ERR \"%s: unable to alloc buffer\\n\", __FUNCTION__);\n+\t\tprintk(KERN_ERR \"%s: unable to alloc buffer old size %d new size %d\\n\",\n+ __FUNCTION__, fw_priv->alloc_size, new_size);\n \t\t/* Make sure that we don't keep incomplete data */\n \t\tfw_load_abort(fw_priv);\n \t\treturn -ENOMEM;\n \t}\n-\tfw_priv->alloc_size += PAGE_SIZE;\n+ fw_priv->alloc_size = new_size;\n \tif (fw_priv->fw->data) {\n \t\tmemcpy(new_data, fw_priv->fw->data, fw_priv->fw->size);\n \t\tvfree(fw_priv->fw->data);\n@@ -249,6 +281,13 @@ firmware_data_write(struct kobject *kobj\n \t\tgoto out;\n \n \tmemcpy(fw->data + offset, buffer, count);\n+ /* A successful write should cause us to reset the timeout\n+ delay, as very large firmware files might take a while to\n+ send through the sysfs file. We have the fw_lock taken at\n+ the moment but the timeout function doesn't lock as it only\n+ has to set a single volatile bit, so we're ok to mod it. */\n+ if (timer_pending (&fw_priv->timeout))\n+ mod_timer (&fw_priv->timeout, jiffies + loading_timeout * HZ);\n \n \tfw->size = max_t(size_t, offset + count, fw->size);\n \tretval = count;\n@@ -568,6 +607,12 @@ firmware_class_init(void)\n \t\t __FUNCTION__);\n \t\tclass_unregister(&firmware_class);\n \t}\n+\terror = class_create_file(&firmware_class, &class_attr_grow_faster);\n+\tif (error) {\n+\t\tprintk(KERN_ERR \"%s: class_create_file failed\\n\",\n+\t\t __FUNCTION__);\n+\t\tclass_unregister(&firmware_class);\n+\t}\n \treturn error;\n \n }\n\n\n_______________________________________________\nMake-w32 mailing list\nMake-w32@gnu.org\nhttp://lists.gnu.org/mailman/listinfo/make-w32\n"},{"id":"56070","messageId":"20071016155608.GA10603@old.davidb.org","threadId":"10283","inReplyTo":"E1Ihfrl-0007w1-3I@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-10-16T15:56:08Z","receivedAt":"2007-10-16T15:56:08Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:\n\n>On the other hand, what packages have 100K files? If there's only one\n>-- the Linux kernel -- then I think this kind of performance is for\n>all practical purposes unimportant on Windows, because while it is\n>reasonable to assume that someone would like to use git on Windows,\n>assuming that someone will develop the Linux kernel on Windows is --\n>how should I put it -- _really_ far-fetched ;-)\n\nOh, I wish others could think this clearly. Quoting a serious line off of\na task list at an unnamed company:\n\n - Make Linux kernel compile under windows.\n\nI don't think it will move past just being a wish list item, but there seem\nto be people that think it should be done.\n\nAdmittedly, they don't want developers doing it on windows, but want to\nintegrate kernel building into a windows-heavy build and release process.\n\nDavid\n"},{"id":"56071","messageId":"alpine.LFD.0.9999.0710161201510.19446@xanadu.home","threadId":"10283","inReplyTo":"20071016155608.GA10603@old.davidb.org","subject":"Re: Switching from CVS to GIT","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-16T16:04:29Z","receivedAt":"2007-10-16T16:04:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 16 Oct 2007, David Brown wrote:\n\n> On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:\n> \n> > On the other hand, what packages have 100K files? If there's only one\n> > -- the Linux kernel -- then I think this kind of performance is for\n> > all practical purposes unimportant on Windows, because while it is\n> > reasonable to assume that someone would like to use git on Windows,\n> > assuming that someone will develop the Linux kernel on Windows is --\n> > how should I put it -- _really_ far-fetched ;-)\n> \n> Oh, I wish others could think this clearly. Quoting a serious line off of\n> a task list at an unnamed company:\n> \n> - Make Linux kernel compile under windows.\n> \n> I don't think it will move past just being a wish list item, but there seem\n> to be people that think it should be done.\n\nLinux is compilable on Windows, and has been for a long time already.\nWith Cygwin it is pretty trivial to do. I prefer native Linux though.\n\n\nNicolas\n"},{"id":"56073","messageId":"03f401c81010$d8833de0$2e08a8c0@CAM.ARTIMI.COM","threadId":"10283","inReplyTo":"20071016155608.GA10603@old.davidb.org","subject":"RE: Switching from CVS to GIT","fromName":"Dave Korn","fromEmail":"dave.korn@artimi.com","sentAt":"2007-10-16T16:23:11Z","receivedAt":"2007-10-16T16:23:11Z","isPatch":false,"sender":{"key":"dave.korn@artimi.com","avatar":null},"body":"On 16 October 2007 16:56, David Brown wrote:\n\n> On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:\n> \n>> On the other hand, what packages have 100K files? If there's only one\n>> -- the Linux kernel -- then I think this kind of performance is for\n>> all practical purposes unimportant on Windows, because while it is\n>> reasonable to assume that someone would like to use git on Windows,\n>> assuming that someone will develop the Linux kernel on Windows is --\n>> how should I put it -- _really_ far-fetched ;-)\n> \n> Oh, I wish others could think this clearly. Quoting a serious line off of\n> a task list at an unnamed company:\n> \n> - Make Linux kernel compile under windows.\n> \n> I don't think it will move past just being a wish list item, but there seem\n> to be people that think it should be done.\n> \n> Admittedly, they don't want developers doing it on windows, but want to\n> integrate kernel building into a windows-heavy build and release process.\n\n Do that kind of thing here all the time, hence my previous post. Apart from\nthe netfilter stuff with the filenames-that-match-in-all-but-case, no real\nproblems, took me a couple of hours one afternoon.\n\n Cygwin is a good match for linux dev work.\n\n cheers,\n DaveK\n-- \nCan't think of a witty .sigline today....\n"},{"id":"56082","messageId":"4714EDE7.3010407@op5.se","threadId":"10283","inReplyTo":"E1Ihfrl-0007w1-3I@fencepost.gnu.org","subject":"Re: Switching from CVS to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-16T16:59:19Z","receivedAt":"2007-10-16T16:59:19Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Eli Zaretskii wrote:\n>> From: Andreas Ericsson \n> \n>> I *think* (correct me if I'm wrong) that git is still faster\n>> than a whole bunch of other scm's on windows, but to one who's used to\n>> its performance on Linux that waiting several seconds to scan 10k files\n>> just feels wrong.\n> \n> Unless that 10K is a typo and you really meant 100K, I don't think 10K\n> files should take several seconds to scan on Windows. I just tried\n> \"find -print\" on a directory with 32K files in 4K subdirectories, and\n> it took 8 sec elapsed with a hot cache. So 10K files should take at\n> most 2 seconds, even without optimizing file traversal code. Doing\n> the same with native Windows system calls (\"dir /s\") brings that down\n> to 4 seconds for 32K files.\n> \n\nIt was a typo. Thanks for correcting me.\n\n> On the other hand, what packages have 100K files? If there's only one\n> -- the Linux kernel -- then I think this kind of performance is for\n> all practical purposes unimportant on Windows\n\nBut it's most definitely not. The *huge* projects that have looked at\ngit have sometimes turned it down simply because they're either cross-\nplatform (Mozilla) or they have translators that use windows exclusively\n(KDE and Mozilla, just to mention two).\n\nBoth Mozilla and KDE repos are *much* larger than the Linux repo.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56083","messageId":"Pine.LNX.4.64.0710161201320.7638@iabervon.org","threadId":"10283","inReplyTo":"Pine.LNX.4.64.0710161335260.25221@racer.site","subject":"Re: Switching from CVS to GIT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-10-16T17:04:21Z","receivedAt":"2007-10-16T17:04:21Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 16 Oct 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> [culled make-w32, as per explicit request]\n> \n> On Tue, 16 Oct 2007, Eli Zaretskii wrote:\n> \n> > > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)\n> > > From: Daniel Barkalow \n> > > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se, \n> > > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org\n> > > \n> > > Ah, that's helpful. We don't actually care too much about the \n> > > particular info in stat; we just want to know quickly if the file has \n> > > changed, so we can hash only the ones that have been touched and get \n> > > the actual content changes.\n> > \n> > As I wrote in my other message, using native APIs improves performance \n> > by at least a factor of two.\n> \n> Somehow this does not appeal to my \"portability is good\" side. You know, \n> if we had to do such trickeries for every platform we support, we'd soon \n> be as big as Subversion *cough*.\n\nI think that it would be a worthwhile project, from the point of view of \nmaking the code easier to follow and making the internal APIs clearer, to \norganize git's source to abstract the object database to read_sha1_file(), \nhas_sha1_file(), hash_sha1_file(), and write_sha1_file() as the arbiters \nof what is in the local database (with other functions public as support \nfor over-the-wire protocols, which may, by not-really-coincidence, by used \nfor local storage as well); then Windows could have an entirely different \nstorage mechanism that doesn't rely on filesystem metadata speed.\n\nIt would also be worthwhile to untangle the index's stat cache aspects and \nits tree-object-related aspects, so that there can be a platform- and \nrepository-specific concept of how to handle the working area, and then \nWindows could do different stuff for the default case of setting up a \ndirectory on the local filesystem.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"56103","messageId":"20071016180632.GA24953@ednor.casa.cgf.cx","threadId":"10283","inReplyTo":"03f401c81010$d8833de0$2e08a8c0@CAM.ARTIMI.COM","subject":"Re: Switching from CVS to GIT","fromName":"Christopher Faylor","fromEmail":"cgf-use-the-mailinglist-please@gnu.org","sentAt":"2007-10-16T18:06:32Z","receivedAt":"2007-10-16T18:06:32Z","isPatch":false,"sender":{"key":"cgf-use-the-mailinglist-please@gnu.org","avatar":null},"body":"On Tue, Oct 16, 2007 at 05:23:11PM +0100, Dave Korn wrote:\n>On 16 October 2007 16:56, David Brown wrote:\n>\n>> On Tue, Oct 16, 2007 at 02:25:21AM -0400, Eli Zaretskii wrote:\n>> \n>>> On the other hand, what packages have 100K files? If there's only one\n>>> -- the Linux kernel -- then I think this kind of performance is for\n>>> all practical purposes unimportant on Windows, because while it is\n>>> reasonable to assume that someone would like to use git on Windows,\n>>> assuming that someone will develop the Linux kernel on Windows is --\n>>> how should I put it -- _really_ far-fetched ;-)\n>> \n>> Oh, I wish others could think this clearly. Quoting a serious line off of\n>> a task list at an unnamed company:\n>> \n>> - Make Linux kernel compile under windows.\n>> \n>> I don't think it will move past just being a wish list item, but there seem\n>> to be people that think it should be done.\n>> \n>> Admittedly, they don't want developers doing it on windows, but want to\n>> integrate kernel building into a windows-heavy build and release process.\n>\n> Do that kind of thing here all the time, hence my previous post. Apart from\n>the netfilter stuff with the filenames-that-match-in-all-but-case, no real\n>problems, took me a couple of hours one afternoon.\n\nDitto.\n\nCoincidentially enough this is the reason I wrote managed mode for cygwin's\nmount.\n\nBut, we're pretty far off-topic aren't we?\n\ncgf\n"},{"id":"56284","messageId":"200710172133.34273.robin.rosenberg.lists@dewire.com","threadId":"10283","inReplyTo":"4D822762-D344-465E-B77D-90A64D61F5A9@zib.de","subject":"Re: Switching from CVS to GIT","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-10-17T19:33:32Z","receivedAt":"2007-10-17T19:33:32Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 16 oktober 2007 skrev Steffen Prohaska:\n> \n> On Oct 16, 2007, at 2:33 PM, Johannes Schindelin wrote:\n> \n> >> Maybe we need a configuration similar to core.autocrlf (which \n> >> controls\n> >> newline conversion) to control filename comparison and normalization?\n> >>\n> >> Most obviously for the case (in-)sensitivity on Windows, but I also\n> >> remember the unicode normalization happening on Mac's HFS filesystem\n> >> that caused trouble in the past.\n> >\n> > Robin Rosenberg has some preliminary code for that. The idea is to \n> > wrap\n> > all filesystem operations in cache.h, and do a filename normalisation\n> > first.\n> \n> At that point we could add a safety check. Paths that differ only by\n> case, or whitespace, or ... (add general and project specific rules \n> here)\n> should be denied. This would guarantee that tree objects can always be\n> checked out. Even if the filesystem capabilities are limited.\n> \n> Robin, what do you think?\n\nMy code only normalizes filenames to UTF-8 inside git, which isn't the same \nthing. I think that can be extended to handling MacOSX normalized UTF-8 and\nWindows UTF-16 so, when you check out a thing from git there will be no \nsurprises. Case insensitivity is another dimension. I have no idea as to the\nperformance of the code, it's more like a proof-that-it-can-be-done.\n\nThe code cannot \"fail\", it always does something reasonable, like not \nconverting when that is not possible. Something else has to be done for \nvalidation.\n\nThe UTF-16 that windows use is not a current issue because git only does \nlocal code page. Jgit, but it isn't very smart either because git doesn't say \nanything about filename encoding, while Windows/MacOSX/CIFS and other \nfilesystems does.\n\nThe fact that git uses eigth bit file names may also be a reason performance \nis slower on Windows, because the eight-bit Win32API transforms all strings \nand filenames to the native UTF-16 encoding on *every* system call, in and \nout; that's a lot of work when you do it thousands of times. If git itself \ndid the transform it might be made smarter and more suited to git's purposes, \nand most importantly faster. I have no idea about the performance hit. One\nhas to measure something.\n\nI notice a number of SCM's out there, including one with a \\$\\d{4} pricetag \ngets you into trouble if you rename a file from Foo to FOO on Windows.\n\n-- robin\n"}]}