{"thread":{"id":"6574","subject":"MinGW port usable","startedAt":"2007-01-29T22:20:43Z","lastAt":"2007-02-02T08:55:38Z","messageCount":39,"participants":["Johannes Sixt","Shawn O. Pearce","Linus Torvalds","Christian MICHON","Daniel Barkalow","Junio C Hamano","Andreas Ericsson","Johannes Schindelin","H. Peter Anvin","Davide Libenzi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"32981","messageId":"200701292320.43888.johannes.sixt@telecom.at","threadId":"6574","inReplyTo":null,"subject":"MinGW port usable","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-01-29T22:20:43Z","receivedAt":"2007-01-29T22:20:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"I'd like to point interested parties to the MinGW port at\n\n git://repo.or.cz/git/mingw.git\n\nwhich is now in a usable state, methinks. I'm using it with git-gui and gitk \non a (almost) production repository.\n\nThe README.MinGW at \nhttp://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master gives \nan overview on the state. The transfer via native git protocol does not work \nand cannot be made working without major surgery(*). Theoretically, using \nnetcat (nc) as GIT_PROXY_COMMAND should work, but not in my setup for some \nreason that I still do not know.\n\n(*) The reason is that on Windows read() and write() cannot operate on \ndescriptors created by socket(). A work-around is to implement a (threaded) \nproxy, but that's almost the same as if netcat were used as \nGIT_PROXY_COMMAND.\n\nJunio, you may like to cherry-pick these two non-critical commits from my \nrepository:\n\n8c8bb94f94f1d972c7ffadda4744cf343fac6f34 gitk: Use peek-remote instead of \nls-remote.\n46580d2192d79a469f8b40fc1081db9116ad5517 Add a missing fork() error check.\n\n-- Hannes\n"},{"id":"32982","messageId":"20070129223513.GA31372@spearce.org","threadId":"6574","inReplyTo":"200701292320.43888.johannes.sixt@telecom.at","subject":"Re: MinGW port usable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-29T22:35:13Z","receivedAt":"2007-01-29T22:35:13Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Sixt wrote:\n> I'd like to point interested parties to the MinGW port at\n> \n> git://repo.or.cz/git/mingw.git\n> \n> which is now in a usable state, methinks. I'm using it with git-gui and gitk \n> on a (almost) production repository.\n\nWell, that's pretty sweet that git-gui is working in a MinGW case.\n\nLast night I pushed out a number of changes to avoid cygpath when\nwe don't have it in PATH (commit 20ddfcaa). Were you testing with\nthat version, or something earlier?\n\n-- \nShawn.\n"},{"id":"32983","messageId":"Pine.LNX.4.64.0701291438580.3611@woody.linux-foundation.org","threadId":"6574","inReplyTo":"200701292320.43888.johannes.sixt@telecom.at","subject":"Re: MinGW port usable","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-29T22:46:23Z","receivedAt":"2007-01-29T22:46:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 29 Jan 2007, Johannes Sixt wrote:\n\n> I'd like to point interested parties to the MinGW port at\n> \n> git://repo.or.cz/git/mingw.git\n> \n> which is now in a usable state, methinks. I'm using it with git-gui and gitk \n> on a (almost) production repository.\n\nCan you elaborate about any performance differences, especially with \ncygwin? Does this make git perform reasonably on Windows, or are the \nperformance problems as bad as with cygwin?\n\n> Junio, you may like to cherry-pick these two non-critical commits from my \n> repository:\n> \n> 8c8bb94f94f1d972c7ffadda4744cf343fac6f34 gitk: Use peek-remote instead of ls-remote.\n\ngitk really shouldn't use either. It should probably use\n\n\tgit-show-ref -h -d\n\ninstead, which has the same output format (modulo a space vs tab issue), \nand is entirely local, with no silly unnecessary remote connext.\n\nSomething like this patch.\n\nDoes that work on mingw too?\n\n\t\tLinus\n----\ndiff --git a/gitk b/gitk\nindex 031c829..6b4a4ac 100755\n--- a/gitk\n+++ b/gitk\n@@ -309,9 +309,9 @@ proc readrefs {} {\n foreach v {tagids idtags headids idheads otherrefids idotherrefs} {\n \tcatch {unset $v}\n }\n- set refd [open [list | git ls-remote [gitdir]] r]\n+ set refd [open [list | git show-ref -h -d] r]\n while {0 <= [set n [gets $refd line]]} {\n-\tif {![regexp {^([0-9a-f]{40})\trefs/([^^]*)$} $line \\\n+\tif {![regexp {^([0-9a-f]{40}) refs/([^^]*)$} $line \\\n \t match id path]} {\n \t continue\n \t}\n"},{"id":"32991","messageId":"46d6db660701291508m4362eedchd4050e61f4989a92@mail.gmail.com","threadId":"6574","inReplyTo":"Pine.LNX.4.64.0701291438580.3611@woody.linux-foundation.org","subject":"Re: MinGW port usable","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-29T23:08:59Z","receivedAt":"2007-01-29T23:08:59Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/29/07, Linus Torvalds wrote:\n> Can you elaborate about any performance differences, especially with\n> cygwin? Does this make git perform reasonably on Windows, or are the\n> performance problems as bad as with cygwin?\n>\n\nI do not know about cygwin recently (else than it was slow), but I\ncloned my packed git repository of all 117 2.6 linux kernels and\nthe \"git diff\" rocks on it.\n\ngit-unpack and git-repack was slow as hell, though. Maybe this\nis the part to be improved. Mostly bad I/Os...\n\n> gitk really shouldn't use either. It should probably use\n>\n> git-show-ref -h -d\n>\n> instead, which has the same output format (modulo a space vs tab issue),\n> and is entirely local, with no silly unnecessary remote connext.\n>\n> Something like this patch.\n>\n> Does that work on mingw too?\n>\n\nI'll try that tomorrow, but you'll have other reporting about it, for sure.\n\n-- \nChristian\n"},{"id":"32992","messageId":"46d6db660701291511v700bfcf7l4851dd6be4fc6e03@mail.gmail.com","threadId":"6574","inReplyTo":"20070129223513.GA31372@spearce.org","subject":"Re: MinGW port usable","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-29T23:11:48Z","receivedAt":"2007-01-29T23:11:48Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/29/07, Shawn O. Pearce wrote:\n> Johannes Sixt wrote:\n> > I'd like to point interested parties to the MinGW port at\n> >\n> > git://repo.or.cz/git/mingw.git\n> >\n> > which is now in a usable state, methinks. I'm using it with git-gui and gitk\n> > on a (almost) production repository.\n>\n> Well, that's pretty sweet that git-gui is working in a MinGW case.\n>\n> Last night I pushed out a number of changes to avoid cygpath when\n> we don't have it in PATH (commit 20ddfcaa). Were you testing with\n> that version, or something earlier?\n>\n\nmy last compilation is less than 8 hours old, and I do not have cygwin\ninstalled. What is it you want to test actually ?\n\ngit-gui and gitk have been working for a bit more than a week, if I\nrecall well. I'd like to see git-blame latest patch work with git-gui.\n\n:)\n\n-- \nChristian\n"},{"id":"32993","messageId":"20070129232425.GB31372@spearce.org","threadId":"6574","inReplyTo":"46d6db660701291511v700bfcf7l4851dd6be4fc6e03@mail.gmail.com","subject":"Re: MinGW port usable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-29T23:24:25Z","receivedAt":"2007-01-29T23:24:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christian MICHON wrote:\n> my last compilation is less than 8 hours old, and I do not have cygwin\n> installed. What is it you want to test actually ?\n\nTry creating a desktop icon (Repository->Create Desktop Icon) and\nstart git-gui from the resulting .bat file. It *should* come up\nright on MinGW, but I'm only guessing here.\n\nThe other one that I'm curious about is if fetch/push/merge work.\nmerge requires git-merge right now, which is a shell script.\nfetch is the same, but push is pure C so it should work. But I\ndon't think the Tcl environment will make it into the child, which\nmeans things like SSH_AUTH_SOCK don't get used.\n\nBut I really should just install the git-mingw port on one of\nmy windows systems and play with it. If its faster than Cygwin\nthen it's worthwhile.\n \n> git-gui and gitk have been working for a bit more than a week, if I\n> recall well. I'd like to see git-blame latest patch work with git-gui.\n\nThe blame feature is in git-gui (went in last night). It requires\nthe --incremental patches from Linus&Junio, which are now in git.git\nmaster. It also needs a big display, as the interface is horrid. :)\n\n-- \nShawn.\n"},{"id":"32996","messageId":"46d6db660701291548j454d7d70w9302640e28b0e70e@mail.gmail.com","threadId":"6574","inReplyTo":"20070129232425.GB31372@spearce.org","subject":"Re: MinGW port usable","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-29T23:48:38Z","receivedAt":"2007-01-29T23:48:38Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/30/07, Shawn O. Pearce wrote:\n> Try creating a desktop icon (Repository->Create Desktop Icon) and\n> start git-gui from the resulting .bat file. It *should* come up\n> right on MinGW, but I'm only guessing here.\n\nok noted for tomorrow's tests :)\n\n> The other one that I'm curious about is if fetch/push/merge work.\n> merge requires git-merge right now, which is a shell script.\n> fetch is the same, but push is pure C so it should work. But I\n> don't think the Tcl environment will make it into the child, which\n> means things like SSH_AUTH_SOCK don't get used.\n\nI'll see what I can do.\n\n> But I really should just install the git-mingw port on one of\n> my windows systems and play with it. If its faster than Cygwin\n> then it's worthwhile.\n\none of the hassles with this mingw thingy is that you need to\ninstall it, and whatever you compile gets inside it, like libs,\nincludes, etc... Whenever I come out with a stable product\nthat can be sfx'ed inside a 7zip executable, I do it, to avoid\ninstalling/uninstalling or even modifying it.\n\nit works like a charm with msys/mingw, and I guess git/gitk/git-gui\nwill all work in this way too. Once this port is ready for mass\ntesting, I guess we can either show how to compile it (actually\nsome patches are still needed, like no symlinks exist on\nmsys/mingw, so we should replace those links by bash scripts),\nor provide a 7z sfx binary that can help <> git\nto the mass. On this last possibility I can help out...\n\nyour call, guys. :)\n\n> The blame feature is in git-gui (went in last night). It requires\n> the --incremental patches from Linus&Junio, which are now in git.git\n> master. It also needs a big display, as the interface is horrid. :)\n\nI'll find a big one then.\n\n-- \nChristian\n"},{"id":"32999","messageId":"Pine.LNX.4.64.0701291944290.20138@iabervon.org","threadId":"6574","inReplyTo":"200701292320.43888.johannes.sixt@telecom.at","subject":"Re: MinGW port usable","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-30T00:50:36Z","receivedAt":"2007-01-30T00:50:36Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 29 Jan 2007, Johannes Sixt wrote:\n\n> (*) The reason is that on Windows read() and write() cannot operate on \n> descriptors created by socket(). A work-around is to implement a (threaded) \n> proxy, but that's almost the same as if netcat were used as \n> GIT_PROXY_COMMAND.\n\nCan you do\n\n#define read(fd, buffer, len) recv(fd, buffer, len, 0)\n#define write(fd, buffer, len) send(fd, buffer, len, 0)\n\nin the appropriate file?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"33004","messageId":"7vveip5acn.fsf@assigned-by-dhcp.cox.net","threadId":"6574","inReplyTo":"200701292320.43888.johannes.sixt@telecom.at","subject":"Re: MinGW port usable","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-30T05:53:28Z","receivedAt":"2007-01-30T05:53:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Junio, you may like to cherry-pick these two non-critical commits from my \n> repository:\n>\n> 8c8bb94f94f1d972c7ffadda4744cf343fac6f34 gitk: Use peek-remote instead of \n> ls-remote.\n> 46580d2192d79a469f8b40fc1081db9116ad5517 Add a missing fork() error check.\n\nThanks; cherry-picked the fork() one.\n\nRegarding gitk, I think the following patch would be better\nregardless of the platform.\n\n-- >8 --\n[PATCH] gitk: Use show-ref instead of ls-remote\n\nIt used to be ls-remote on self was the only easy way to grab\nthe ref information. Now we have show-ref which does not\ninvolve fork and IPC, so use it.\n\nSigned-off-by: Junio C Hamano \n---\ndiff --git a/gitk b/gitk\nindex 31d0aad..67e6a64 100755\n--- a/gitk\n+++ b/gitk\n@@ -309,9 +309,9 @@ proc readrefs {} {\n foreach v {tagids idtags headids idheads otherrefids idotherrefs} {\n \tcatch {unset $v}\n }\n- set refd [open [list | git ls-remote [gitdir]] r]\n+ set refd [open [list | git show-ref] r]\n while {0 <= [set n [gets $refd line]]} {\n-\tif {![regexp {^([0-9a-f]{40})\trefs/([^^]*)$} $line \\\n+\tif {![regexp {^([0-9a-f]{40}) refs/([^^]*)$} $line \\\n \t match id path]} {\n \t continue\n \t}\n"},{"id":"33014","messageId":"46d6db660701292359v7647306fla30c9a10e5989dcc@mail.gmail.com","threadId":"6574","inReplyTo":"20070129232425.GB31372@spearce.org","subject":"Re: MinGW port usable","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-30T07:59:46Z","receivedAt":"2007-01-30T07:59:46Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/30/07, Shawn O. Pearce wrote:\n> Try creating a desktop icon (Repository->Create Desktop Icon) and\n> start git-gui from the resulting .bat file. It *should* come up\n> right on MinGW, but I'm only guessing here.\n\nok, yes it's working. :)\nbut call gitk from inside it fail :(\n\n\"error in startup script\"\n( git-peek-remote is not working from git-gui, could be path related.\nIt's hard to tell why yet)\n\n-- \nChristian\n"},{"id":"33015","messageId":"46d6db660701300007v573832b5pc7ac41059dc4490e@mail.gmail.com","threadId":"6574","inReplyTo":"46d6db660701292359v7647306fla30c9a10e5989dcc@mail.gmail.com","subject":"Re: MinGW port usable","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-30T08:07:15Z","receivedAt":"2007-01-30T08:07:15Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/30/07, Christian MICHON wrote:\n> On 1/30/07, Shawn O. Pearce wrote:\n> > Try creating a desktop icon (Repository->Create Desktop Icon) and\n> > start git-gui from the resulting .bat file. It *should* come up\n> > right on MinGW, but I'm only guessing here.\n>\n> ok, yes it's working. :)\n> but call gitk from inside it fail :(\n>\n> \"error in startup script\"\n> ( git-peek-remote is not working from git-gui, could be path related.\n> It's hard to tell why yet)\n>\n> --\n> Christian\n>\n\njust to be more clear: when using the .bat shortcut, calling gitk\nfrom within git-gui fails.\n\nBut if I call git-gui from a msys rxvt+bash, I can invoke all tools,\nand calling gitk from within git-gui works.\n\nI think this shortcut stuff may not be the best approach yet.\n\n-- \nChristian\n"},{"id":"33016","messageId":"45BF0098.8FF978CE@eudaptics.com","threadId":"6574","inReplyTo":"Pine.LNX.4.64.0701291944290.20138@iabervon.org","subject":"Re: MinGW port usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-01-30T08:23:52Z","receivedAt":"2007-01-30T08:23:52Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Daniel Barkalow wrote:\n> \n> On Mon, 29 Jan 2007, Johannes Sixt wrote:\n> \n> > (*) The reason is that on Windows read() and write() cannot operate on\n> > descriptors created by socket(). A work-around is to implement a (threaded)\n> > proxy, but that's almost the same as if netcat were used as\n> > GIT_PROXY_COMMAND.\n> \n> Can you do\n> \n> #define read(fd, buffer, len) recv(fd, buffer, len, 0)\n> #define write(fd, buffer, len) send(fd, buffer, len, 0)\n> \n> in the appropriate file?\n\nI doubt that recv and send can operate on regular file descriptors, as\nopened by _pipe(), open(), can they?\n\n-- Hannes\n"},{"id":"33019","messageId":"45BF04BA.3020606@op5.se","threadId":"6574","inReplyTo":"45BF0098.8FF978CE@eudaptics.com","subject":"Re: MinGW port usable","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-30T08:41:30Z","receivedAt":"2007-01-30T08:41:30Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Sixt wrote:\n> Daniel Barkalow wrote:\n>> On Mon, 29 Jan 2007, Johannes Sixt wrote:\n>>\n>>> (*) The reason is that on Windows read() and write() cannot operate on\n>>> descriptors created by socket(). A work-around is to implement a (threaded)\n>>> proxy, but that's almost the same as if netcat were used as\n>>> GIT_PROXY_COMMAND.\n>> Can you do\n>>\n>> #define read(fd, buffer, len) recv(fd, buffer, len, 0)\n>> #define write(fd, buffer, len) send(fd, buffer, len, 0)\n>>\n>> in the appropriate file?\n> \n> I doubt that recv and send can operate on regular file descriptors, as\n> opened by _pipe(), open(), can they?\n> \n\nHence \"in the appropriate file\", I guess.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"33020","messageId":"45BF05BA.4B356B37@eudaptics.com","threadId":"6574","inReplyTo":"Pine.LNX.4.64.0701291438580.3611@woody.linux-foundation.org","subject":"Re: MinGW port usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-01-30T08:45:46Z","receivedAt":"2007-01-30T08:45:46Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Linus Torvalds wrote:\n> Can you elaborate about any performance differences, especially with\n> cygwin? Does this make git perform reasonably on Windows, or are the\n> performance problems as bad as with cygwin?\n\nPerformance is horrid, although better than I initially expected. I\ndon't (want to) have cygwin installed to compare it (that's why I did\nthe MinGW port in the first place ;) Maybe others can comment on this?\n\nThe test suite takes ~15min to complete on my box, which is an oooold\n800MHz with a slow HD. (And it's still Win2K, if that matters.)\n\nQuite frankly, the \"performance boost\" that I expect from this port is\nthat it allows me the workflow that I want, instead of constantly\nbanging my head against the walls of CVS/SVN/you-name-it.\n\n> gitk really shouldn't use either. It should probably use\n> \n> git-show-ref -h -d\n> \n> instead, which has the same output format (modulo a space vs tab issue),\n> and is entirely local, with no silly unnecessary remote connext.\n\nThanks, this works (I tested Junio's version). The problem with\nls-remote was that it is a shell script, and for some reason it dumps\nits output into a cmd.exe that opens and closes right away instead of to\nthe pipe.\n\n-- Hannes\n"},{"id":"33021","messageId":"45BF062E.37A4327A@eudaptics.com","threadId":"6574","inReplyTo":"20070129223513.GA31372@spearce.org","subject":"Re: MinGW port usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-01-30T08:47:42Z","receivedAt":"2007-01-30T08:47:42Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> Last night I pushed out a number of changes to avoid cygpath when\n> we don't have it in PATH (commit 20ddfcaa). Were you testing with\n> that version, or something earlier?\n\nyes, I tested that version. The new incremental blame works, too.\n\n-- Hannes\n"},{"id":"33026","messageId":"Pine.LNX.4.63.0701301105540.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"45BF0098.8FF978CE@eudaptics.com","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T10:07:22Z","receivedAt":"2007-01-30T10:07:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Jan 2007, Johannes Sixt wrote:\n\n> Daniel Barkalow wrote:\n> > \n> > On Mon, 29 Jan 2007, Johannes Sixt wrote:\n> > \n> > > (*) The reason is that on Windows read() and write() cannot operate on\n> > > descriptors created by socket(). A work-around is to implement a (threaded)\n> > > proxy, but that's almost the same as if netcat were used as\n> > > GIT_PROXY_COMMAND.\n> > \n> > Can you do\n> > \n> > #define read(fd, buffer, len) recv(fd, buffer, len, 0)\n> > #define write(fd, buffer, len) send(fd, buffer, len, 0)\n> > \n> > in the appropriate file?\n> \n> I doubt that recv and send can operate on regular file descriptors, as\n> opened by _pipe(), open(), can they?\n\nThey can't. Thus, you'd break at least inetd mode.\n\nOf course, you really could start a thread which gets two pipe()d fds, and \nthe proper socket, and just shuffles things back & forth. Not that hard.\n\nCiao,\nDscho\n"},{"id":"33027","messageId":"Pine.LNX.4.63.0701301107470.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"46d6db660701291508m4362eedchd4050e61f4989a92@mail.gmail.com","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T10:08:24Z","receivedAt":"2007-01-30T10:08:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Jan 2007, Christian MICHON wrote:\n\n> git-unpack and git-repack was slow as hell, though. Maybe this is the \n> part to be improved. Mostly bad I/Os...\n\nHow do you want to improve bad I/O on Windows?\n\nCiao,\nDscho\n"},{"id":"33028","messageId":"46d6db660701300214i30e31deem8c589a8d2faf99c0@mail.gmail.com","threadId":"6574","inReplyTo":"Pine.LNX.4.63.0701301107470.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port usable","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-30T10:14:14Z","receivedAt":"2007-01-30T10:14:14Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/30/07, Johannes Schindelin wrote:\n> How do you want to improve bad I/O on Windows?\n>\n\nupgrade to Vista ? :lol:\n\nseriously, no clue here. I want first to fairly compare mingw-git with\ngit inside colinux inside a shared cofs directory.\n\n-- \nChristian\n"},{"id":"33029","messageId":"Pine.LNX.4.63.0701301114590.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"46d6db660701300007v573832b5pc7ac41059dc4490e@mail.gmail.com","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T10:16:44Z","receivedAt":"2007-01-30T10:16:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Jan 2007, Christian MICHON wrote:\n\n> On 1/30/07, Christian MICHON wrote:\n> > On 1/30/07, Shawn O. Pearce wrote:\n> > > Try creating a desktop icon (Repository->Create Desktop Icon) and\n> > > start git-gui from the resulting .bat file. It *should* come up\n> > > right on MinGW, but I'm only guessing here.\n> > \n> > ok, yes it's working. :)\n> > but call gitk from inside it fail :(\n> > \n> > \"error in startup script\"\n> > ( git-peek-remote is not working from git-gui, could be path related.\n> > It's hard to tell why yet)\n> > \n> > --\n> > Christian\n> > \n> \n> just to be more clear: when using the .bat shortcut, calling gitk\n> > from within git-gui fails.\n\nI guess you need to change the .bat shortcut, so that the tcl script is \ncalled via bash instead of directly from cmd.\n\nOtherwise git-gui does not have a chance to find the MSYS environment.\n\nCiao,\nDscho\n"},{"id":"33037","messageId":"Pine.LNX.4.63.0701301524360.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"Pine.LNX.4.64.0701291438580.3611@woody.linux-foundation.org","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T14:35:45Z","receivedAt":"2007-01-30T14:35:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 29 Jan 2007, Linus Torvalds wrote:\n\n> Can you elaborate about any performance differences, especially with \n> cygwin? Does this make git perform reasonably on Windows, or are the \n> performance problems as bad as with cygwin?\n\nOn the git repository, using MinGW:\n\n\t$ time git-rev-list next > /dev/null\n\n\treal 0m0.320s\n\tuser 0m0.031s\n\tsys 0m0.000s\n\n\t$ time git-rev-list next > /dev/null\n\n\treal 0m0.320s\n\tuser 0m0.015s\n\tsys 0m0.015s\n\n\t$ time git-rev-list next > /dev/null\n\n\treal 0m0.352s\n\tuser 0m0.015s\n\tsys 0m0.000s\n\nUsing cygwin:\n\n\t$ time git-rev-list next > /dev/null\n\n\treal 0m0.750s\n\tuser 0m0.421s\n\tsys 0m0.140s\n\n\t$ time git-rev-list next > /dev/null\n\n\treal 0m0.750s\n\tuser 0m0.374s\n\tsys 0m0.233s\n\n\t$ time git-rev-list next > /dev/null\n\n\treal 0m0.750s\n\tuser 0m0.374s\n\tsys 0m0.218s\n\nIOW MinGW wins hands down with an average 0.33s vs cygwin with an average \n0.75s. (I am fairly certain that you must not trust sys times.)\n\nI have no idea why, as the big show-stopper fork() is not even involved.\n\nNow, for something different: git-log. On MinGW:\n\n\t$ time git-log next > /dev/null\n\n\treal 0m1.594s\n\tuser 0m0.015s\n\tsys 0m0.015s\n\n\t$ time git-log next > /dev/null\n\n\treal 0m1.562s\n\tuser 0m0.031s\n\tsys 0m0.000s\n\n\t$ time git-log next > /dev/null\n\n\treal 0m1.610s\n\tuser 0m0.015s\n\tsys 0m0.015s\n\nOn Cygwin:\n\n\t$ time git-log next > /dev/null\n\n\treal 0m2.063s\n\tuser 0m0.827s\n\tsys 0m1.031s\n\n\t$ time git-log next > /dev/null\n\n\treal 0m2.085s\n\tuser 0m0.780s\n\tsys 0m1.061s\n\n\t$ time git-log next > /dev/null\n\n\treal 0m2.047s\n\tuser 0m0.686s\n\tsys 0m1.171s\n\nThat's a bit less obvious: 1.589s for MinGW vs. 2.065s for Cygwin.\n\nThese are all hot-cache numbers, since the cold-cache performance \nof Windows is not easily triggered. (FWIW the first git-log on Cygwin -- \nwhich was cold-cache -- took over 10 seconds.)\n\nCiao,\nDscho\n"},{"id":"33038","messageId":"20070130151803.GA25779@spearce.org","threadId":"6574","inReplyTo":"Pine.LNX.4.63.0701301524360.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port usable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-30T15:18:03Z","receivedAt":"2007-01-30T15:18:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On the git repository, using MinGW:\n> Using cygwin:\n> \n> IOW MinGW wins hands down with an average 0.33s vs cygwin with an average \n> 0.75s. (I am fairly certain that you must not trust sys times.)\n\nJust curious, but were these tests run with mmap(), or NO_MMAP?\n\nClearly, for a packed repository most of the overhead should be\nin getting to the pack data itself (as everything else is pure\nuserspace).\n\n-- \nShawn.\n"},{"id":"33039","messageId":"20070130152721.GB25779@spearce.org","threadId":"6574","inReplyTo":"Pine.LNX.4.63.0701301114590.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port usable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-30T15:27:21Z","receivedAt":"2007-01-30T15:27:21Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Tue, 30 Jan 2007, Christian MICHON wrote:\n> > just to be more clear: when using the .bat shortcut, calling gitk\n> > > from within git-gui fails.\n> \n> I guess you need to change the .bat shortcut, so that the tcl script is \n> called via bash instead of directly from cmd.\n> \n> Otherwise git-gui does not have a chance to find the MSYS environment.\n\nHmmph. The [is_Cygwin] test within git-gui causes it to setup the\n.bat shortcut using:\n\n $(cygpath --windows /bin/sh) --login -c 'git git-gui'\n\nfor exactly that reason. I didn't think that with MSYS there was\nenvironment to hand down through a shell's init scripts. I thought\nit was all coming from Windows itself. Oops.\n\nWhen starting gitk, git-gui assumes (rightly or wrongly) that gitk\nis a Tcl/Tk script and launches it with the same Tcl interpreter\nthat is running git-gui. I did that to bypass the unnecessary\nfork/exec of a shell just to enter a wish process. I had assumed\nthat would also work well on the MSYS case. Apparently not.\n\nPatches to git-gui would be welcome. It will probably be a few weeks\nbefore I can get an MSYS+Git configuration working that I can test\ngit-gui against. I'm just swamped with too many tasks right now,\nand this, although interesting enough to fix, is likely to take a\nback seat.\n\n-- \nShawn.\n"},{"id":"33041","messageId":"Pine.LNX.4.63.0701301635050.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"20070130151803.GA25779@spearce.org","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T15:38:11Z","receivedAt":"2007-01-30T15:38:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Jan 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > On the git repository, using MinGW:\n> > Using cygwin:\n> > \n> > IOW MinGW wins hands down with an average 0.33s vs cygwin with an average \n> > 0.75s. (I am fairly certain that you must not trust sys times.)\n> \n> Just curious, but were these tests run with mmap(), or NO_MMAP?\n\nBoth with NO_MMAP=YesPlease.\n\n> Clearly, for a packed repository most of the overhead should be in \n> getting to the pack data itself (as everything else is pure userspace).\n\nRight. That's why I did the test on the _same_ repository. (Not just both \ngit repositories, but in the same path on the same machine.)\n\nThat said, I find the numbers quite convincing. On a (much weaker \nequipped) Linux bux, it takes 0.65s and 1.2s, respectively.\n\nCiao,\nDscho\n"},{"id":"33043","messageId":"20070130155653.GB25950@spearce.org","threadId":"6574","inReplyTo":"Pine.LNX.4.63.0701301635050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port usable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-30T15:56:53Z","receivedAt":"2007-01-30T15:56:53Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Tue, 30 Jan 2007, Shawn O. Pearce wrote:\n> > Just curious, but were these tests run with mmap(), or NO_MMAP?\n> \n> Both with NO_MMAP=YesPlease.\n\nI wonder what the difference is between NO_MMAP=Yes and NO_MMAP=\non Windows. This is something I've never tried, but probably should\ndo. I run about ~25 developers on NO_MMAP= on Windows (all NTFS)\nwithout issue, but now I'm curious if there's an actual performance\ndifference for some operations. There's no real rationale behind\nmy NO_MMAP= setting, other than that's how we've always used it...\n \n> That said, I find the numbers quite convincing. On a (much weaker \n> equipped) Linux bux, it takes 0.65s and 1.2s, respectively.\n\nThe time difference between the MinGW and Cygwin ports of Git\nis certainly an interesting one, and says good things about the\nMinGW work.\n\nWe're paying a price for POSIX compatibility on Windows, and its a\npretty high one it seems. I can't blame the Cygwin folks, they've\ndone a great job at trying to make the most of VMS. But sometimes\nyou just need Linux (or *BSD, or Solaris). :-)\n\n-- \nShawn.\n"},{"id":"33044","messageId":"Pine.LNX.4.63.0701301708160.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"20070130155653.GB25950@spearce.org","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T16:12:25Z","receivedAt":"2007-01-30T16:12:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Jan 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > On Tue, 30 Jan 2007, Shawn O. Pearce wrote:\n> > > Just curious, but were these tests run with mmap(), or NO_MMAP?\n> > \n> > Both with NO_MMAP=YesPlease.\n> \n> I wonder what the difference is between NO_MMAP=Yes and NO_MMAP=\n> on Windows.\n\nCygwin:\n\n\t$ time git-rev-list next >/dev/null\n\n\treal 0m0.812s\n\tuser 0m0.358s\n\tsys 0m0.203s\n\n\t$ time git-rev-list next >/dev/null\n\n\treal 0m0.797s\n\tuser 0m0.358s\n\tsys 0m0.234s\n\n\t$ time git-rev-list next >/dev/null\n\n\treal 0m0.845s\n\tuser 0m0.390s\n\tsys 0m0.265s\n\nand\n\n\t$ time git-log next >/dev/null\n\n\treal 0m2.094s\n\tuser 0m0.718s\n\tsys 0m1.077s\n\n\t$ time git-log next >/dev/null\n\n\treal 0m2.078s\n\tuser 0m0.718s\n\tsys 0m1.062s\n\n\t$ time git-log next >/dev/null\n\n\treal 0m2.124s\n\tuser 0m0.796s\n\tsys 0m1.046s\n\nIOW, the numbers are slightly worse (!) than with mmap().\n\nMinGW does not even have mmap().\n\nCiao,\nDscho\n"},{"id":"33046","messageId":"20070130162835.GD25950@spearce.org","threadId":"6574","inReplyTo":"Pine.LNX.4.63.0701301708160.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port usable","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-30T16:28:35Z","receivedAt":"2007-01-30T16:28:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> > I wonder what the difference is between NO_MMAP=Yes and NO_MMAP=\n> > on Windows.\n> Cygwin:\n> \treal 0m0.812s\n> and\n> \treal 0m2.094s\n> \n> IOW, the numbers are slightly worse (!) than with mmap().\n\nSlightly? That's double the time!\n \n> MinGW does not even have mmap().\n\nBut Windows has something almost there. I just read a flame war\nthread about implementing mmap in libiberty for MinGW by stealing\nsource from Cygwin, and how the FSF might feel about someone's\ndirty feet after playing rugby. Yea... Google is good. :)\n\n-- \nShawn.\n"},{"id":"33047","messageId":"45BF72DA.B83017CF@eudaptics.com","threadId":"6574","inReplyTo":"46d6db660701300007v573832b5pc7ac41059dc4490e@mail.gmail.com","subject":"Re: MinGW port usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-01-30T16:31:22Z","receivedAt":"2007-01-30T16:31:22Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Christian MICHON wrote:\n> \n> On 1/30/07, Christian MICHON wrote:\n> > but call gitk from inside it fail :(\n> >\n> > \"error in startup script\"\n> > ( git-peek-remote is not working from git-gui, could be path related.\n> > It's hard to tell why yet)\n> \n> just to be more clear: when using the .bat shortcut, calling gitk\n> from within git-gui fails.\n\nCalling gitk from git-gui works here, even if git-gui was invoked from\nthe .bat file. But maybe just because I have all git tools in my $PATH.\nAnd I have this CMD script in my $PATH as well:\n\nD:\\>cat D:\\MSYS\\1.0\\git\\bin\\gitk.cmd\n@echo off\nstart wish84 D:/MSYS/1.0/git/bin/gitk %1 %2 %3 %4 %5 %6 %7 %8 %9\n\n(and, btw, a similar script for git-gui).\n\n-- Hannes\n"},{"id":"33050","messageId":"Pine.LNX.4.63.0701301746310.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"20070130162835.GD25950@spearce.org","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T16:49:22Z","receivedAt":"2007-01-30T16:49:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Jan 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > > I wonder what the difference is between NO_MMAP=Yes and NO_MMAP=\n> > > on Windows.\n> > Cygwin:\n> > \treal 0m0.812s\n> > and\n> > \treal 0m2.094s\n> > \n> > IOW, the numbers are slightly worse (!) than with mmap().\n> \n> Slightly? That's double the time!\n\nNope. What I meant is this: rev-list takes 0.8s without NO_MMAP, while it \ntakes 0.75s with NO_MMAP, and similarly log takes 2.09s without NO_MMAP, \nwhile it takes 2.065 with NO_MMAP.\n\n> > MinGW does not even have mmap().\n> \n> But Windows has something almost there.\n\nYeah, CreateFile(). Very intuitive name.\n\n> I just read a flame war thread about implementing mmap in libiberty for \n> MinGW by stealing source from Cygwin, and how the FSF might feel about \n> someone's dirty feet after playing rugby.\n\n;-)\n\n> Yea... Google is good. :)\n\nWell, I had _horrible_ results in the last two weeks, slowly getting \nbetter.\n\nCiao,\nDscho\n"},{"id":"33053","messageId":"Pine.LNX.4.64.0701301204400.20138@iabervon.org","threadId":"6574","inReplyTo":"45BF0098.8FF978CE@eudaptics.com","subject":"Re: MinGW port usable","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-30T17:09:22Z","receivedAt":"2007-01-30T17:09:22Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 30 Jan 2007, Johannes Sixt wrote:\n\n> Daniel Barkalow wrote:\n> > \n> > On Mon, 29 Jan 2007, Johannes Sixt wrote:\n> > \n> > > (*) The reason is that on Windows read() and write() cannot operate on\n> > > descriptors created by socket(). A work-around is to implement a (threaded)\n> > > proxy, but that's almost the same as if netcat were used as\n> > > GIT_PROXY_COMMAND.\n> > \n> > Can you do\n> > \n> > #define read(fd, buffer, len) recv(fd, buffer, len, 0)\n> > #define write(fd, buffer, len) send(fd, buffer, len, 0)\n> > \n> > in the appropriate file?\n> \n> I doubt that recv and send can operate on regular file descriptors, as\n> opened by _pipe(), open(), can they?\n\nI don't think so, but I think it should be possible to make \npacket_write/packet_read always get a socket, by calling receive-pack and \nupload-pack with a socket pair instead of a pair of pipes. Actually, IIRC, \nthis would be beneficial for making programs not leak file descriptors or \ndouble-close them, because there's already the issue on *nix that it isn't \nconsistant whether both directions are the same file descriptor.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"33054","messageId":"Pine.LNX.4.63.0701301835340.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6574","inReplyTo":"Pine.LNX.4.64.0701301204400.20138@iabervon.org","subject":"Re: MinGW port usable","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-30T17:36:23Z","receivedAt":"2007-01-30T17:36:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 30 Jan 2007, Daniel Barkalow wrote:\n\n> On Tue, 30 Jan 2007, Johannes Sixt wrote:\n> \n> > Daniel Barkalow wrote:\n> > > \n> > > On Mon, 29 Jan 2007, Johannes Sixt wrote:\n> > > \n> > > > (*) The reason is that on Windows read() and write() cannot operate on\n> > > > descriptors created by socket(). A work-around is to implement a (threaded)\n> > > > proxy, but that's almost the same as if netcat were used as\n> > > > GIT_PROXY_COMMAND.\n> > > \n> > > Can you do\n> > > \n> > > #define read(fd, buffer, len) recv(fd, buffer, len, 0)\n> > > #define write(fd, buffer, len) send(fd, buffer, len, 0)\n> > > \n> > > in the appropriate file?\n> > \n> > I doubt that recv and send can operate on regular file descriptors, as\n> > opened by _pipe(), open(), can they?\n> \n> I don't think so, but I think it should be possible to make \n> packet_write/packet_read always get a socket, by calling receive-pack and \n> upload-pack with a socket pair instead of a pair of pipes.\n\nAs I already mentioned in this thread, that would break inetd support.\n\nCiao,\nDscho\n"},{"id":"33058","messageId":"Pine.LNX.4.64.0701301300490.20138@iabervon.org","threadId":"6574","inReplyTo":"Pine.LNX.4.63.0701301835340.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port usable","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-30T18:09:17Z","receivedAt":"2007-01-30T18:09:17Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 30 Jan 2007, Johannes Schindelin wrote:\n\n> Hi,\n> \n> On Tue, 30 Jan 2007, Daniel Barkalow wrote:\n> \n> > On Tue, 30 Jan 2007, Johannes Sixt wrote:\n> > \n> > > Daniel Barkalow wrote:\n> > > > \n> > > > On Mon, 29 Jan 2007, Johannes Sixt wrote:\n> > > > \n> > > > > (*) The reason is that on Windows read() and write() cannot operate on\n> > > > > descriptors created by socket(). A work-around is to implement a (threaded)\n> > > > > proxy, but that's almost the same as if netcat were used as\n> > > > > GIT_PROXY_COMMAND.\n> > > > \n> > > > Can you do\n> > > > \n> > > > #define read(fd, buffer, len) recv(fd, buffer, len, 0)\n> > > > #define write(fd, buffer, len) send(fd, buffer, len, 0)\n> > > > \n> > > > in the appropriate file?\n> > > \n> > > I doubt that recv and send can operate on regular file descriptors, as\n> > > opened by _pipe(), open(), can they?\n> > \n> > I don't think so, but I think it should be possible to make \n> > packet_write/packet_read always get a socket, by calling receive-pack and \n> > upload-pack with a socket pair instead of a pair of pipes.\n> \n> As I already mentioned in this thread, that would break inetd support.\n\nI was actually thinking of only using recv/send on mingw. So the rule \ncould be: if git sets up the connection to a pkt_line-user itself, the \nconnection is a socket; otherwise it might be a pair of pipes; if you're \non mingw, pkt_line uses recv/send. Then everything should work except for \ninetd on mingw, and I don't think that's a plausible combination anyway.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"33083","messageId":"epo9at$94o$1@sea.gmane.org","threadId":"6574","inReplyTo":"Pine.LNX.4.64.0701301300490.20138@iabervon.org","subject":"Re: MinGW port usable","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-01-30T20:20:45Z","receivedAt":"2007-01-30T20:20:45Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Daniel Barkalow wrote:\n> I was actually thinking of only using recv/send on mingw. So the rule\n> could be: if git sets up the connection to a pkt_line-user itself, the\n> connection is a socket; otherwise it might be a pair of pipes; if you're\n> on mingw, pkt_line uses recv/send. Then everything should work except for\n> inetd on mingw, and I don't think that's a plausible combination anyway.\n\nExcept that it won't work. Because in the same program, say git-fetch-pack,\nthe packet_*() functions, where you intend to replace read/write by\nrecv/send, are sometimes called with pipes, and sometimes with sockets,\neven on MinGW.\n\nCall it object oriented programming with polymorphic behavior if you like ;)\n\n-- Hannes\n"},{"id":"33210","messageId":"45C18A3B.2070004@zytor.com","threadId":"6574","inReplyTo":"200701292320.43888.johannes.sixt@telecom.at","subject":"Re: MinGW port usable","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-02-01T06:35:39Z","receivedAt":"2007-02-01T06:35:39Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Johannes Sixt wrote:\n> \n> The README.MinGW at \n> http://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master gives \n> an overview on the state. The transfer via native git protocol does not work \n> and cannot be made working without major surgery(*). Theoretically, using \n> netcat (nc) as GIT_PROXY_COMMAND should work, but not in my setup for some \n> reason that I still do not know.\n> \n> (*) The reason is that on Windows read() and write() cannot operate on \n> descriptors created by socket(). A work-around is to implement a (threaded) \n> proxy, but that's almost the same as if netcat were used as \n> GIT_PROXY_COMMAND.\n> \n\nActually, I believe it can for the NT series kernels (at least 2000 or \nlater, not sure about the earlier ones), but not for the DOS-based ones.\n\nThe trick is to use _open_osfhandle() to convert the file handle (a \nWinAPI construct) to a file descriptor (which in Windows is a construct \nof the C library.)\n\nIn 9x/ME, a socket isn't represented by a file handle, so \n_open_osfhandle() doesn't work on a socket object.\n\nhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__open_osfhandle.asp\n\n\t-hpa\n"},{"id":"33222","messageId":"45C1C24A.471F40AD@eudaptics.com","threadId":"6574","inReplyTo":"45C18A3B.2070004@zytor.com","subject":"Re: MinGW port usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-02-01T10:34:50Z","receivedAt":"2007-02-01T10:34:50Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"\"H. Peter Anvin\" wrote:\n> \n> Johannes Sixt wrote:\n> > (*) The reason is that on Windows read() and write() cannot operate on\n> > descriptors created by socket(). A work-around is to implement a (threaded)\n> > proxy, but that's almost the same as if netcat were used as\n> > GIT_PROXY_COMMAND.\n> >\n> \n> Actually, I believe it can for the NT series kernels (at least 2000 or\n> later, not sure about the earlier ones), but not for the DOS-based ones.\n> \n> The trick is to use _open_osfhandle() to convert the file handle (a\n> WinAPI construct) to a file descriptor (which in Windows is a construct\n> of the C library.)\n\nI tried this, but it doesn't seem to work. I get an EINVAL at the first\nwrite() to the socket. I conclude that the things returned by socket()\nare not WinAPI file handles that are valid for WriteFile(). :(\n\n-- Hannes\n"},{"id":"33284","messageId":"45C2560E.6090504@zytor.com","threadId":"6574","inReplyTo":"45C1C24A.471F40AD@eudaptics.com","subject":"Re: MinGW port usable","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-02-01T21:05:18Z","receivedAt":"2007-02-01T21:05:18Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Johannes Sixt wrote:\n> \"H. Peter Anvin\" wrote:\n>> Johannes Sixt wrote:\n>>> (*) The reason is that on Windows read() and write() cannot operate on\n>>> descriptors created by socket(). A work-around is to implement a (threaded)\n>>> proxy, but that's almost the same as if netcat were used as\n>>> GIT_PROXY_COMMAND.\n>>>\n>> Actually, I believe it can for the NT series kernels (at least 2000 or\n>> later, not sure about the earlier ones), but not for the DOS-based ones.\n>>\n>> The trick is to use _open_osfhandle() to convert the file handle (a\n>> WinAPI construct) to a file descriptor (which in Windows is a construct\n>> of the C library.)\n> \n> I tried this, but it doesn't seem to work. I get an EINVAL at the first\n> write() to the socket. I conclude that the things returned by socket()\n> are not WinAPI file handles that are valid for WriteFile(). :(\n> \n\nExcept they are (for NT-based Windows), so you're doing something goofy. \n This is a widely used construct, so it can't be that broken.\n\n\t-hpa\n"},{"id":"33355","messageId":"45C2F648.9030105@zytor.com","threadId":"6574","inReplyTo":"45C2560E.6090504@zytor.com","subject":"Re: MinGW port usable","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-02-02T08:28:56Z","receivedAt":"2007-02-02T08:28:56Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"H. Peter Anvin wrote:\n> \n> Except they are (for NT-based Windows), so you're doing something goofy. \n> This is a widely used construct, so it can't be that broken.\n> \n\nErf... I dug through this, and it seems that WriteFile only works on a \nsocket if it has an OVERLAPPED argument now, because the socket is \nopened for overlapping I/O. This must be new behaviour in XP-SP2, \nbecause this definitely wasn't the case when I last played with this \nstuff back in 2003. The Internet is full of people using this \ntechnique, but I haven't found a way to get a socket which is *not* \nopened for overlapping I/O.\n\nHow typical of Microsoft to break an incredibly powerful unified \nparadigm, sort-of repair it, and then break it again. There doesn't \nseem to be an obvious way to repair this, either, since MS DLLs won't \nlet you override for example the write() function as called from inside \nthe C runtime DLL.\n\n\"Some people are just a total waste of carbon...\"\n\n\t-hpa\n"},{"id":"33362","messageId":"Pine.LNX.4.64.0702020044460.3673@alien.or.mcafeemobile.com","threadId":"6574","inReplyTo":"45C2F648.9030105@zytor.com","subject":"Re: MinGW port usable","fromName":"Davide Libenzi","fromEmail":"davidel@xmailserver.org","sentAt":"2007-02-02T08:49:43Z","receivedAt":"2007-02-02T08:49:43Z","isPatch":false,"sender":{"key":"davidel@xmailserver.org","avatar":null},"body":"On Fri, 2 Feb 2007, H. Peter Anvin wrote:\n\n> The Internet is full of people using this technique, but I haven't found a way\n> to get a socket which is *not* opened for overlapping I/O.\n\nDoesn't WSASocket() w/out WSA_FLAG_OVERLAPPED work for you? I use that and \nit works just fine with ReadFile/WriteFile (example, I use to to feed std \nhandles to CreateProcess - and those are always accessed with ReadFile/WriteFile \nby childs).\n\n\n- Davide\n"},{"id":"33359","messageId":"45C2FC68.47A7F966@eudaptics.com","threadId":"6574","inReplyTo":"45C2F648.9030105@zytor.com","subject":"Re: MinGW port usable","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-02-02T08:55:04Z","receivedAt":"2007-02-02T08:55:04Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"\"H. Peter Anvin\" wrote:\n> Erf... I dug through this, and it seems that WriteFile only works on a\n> socket if it has an OVERLAPPED argument now, because the socket is\n> opened for overlapping I/O.\n\nGuess, what? When I use WSASocket() instead of socket() to explicitly\ncreate a non-overlapped socket, plus _open_osfhandle(), it works!\n\nThis does not seem to be that new a behavior, since I observed all the\nfailures on Windows 2000.\n\nThanks a lot for your tip!\n\n-- Hannes\n"},{"id":"33361","messageId":"45C2FC8A.4060206@zytor.com","threadId":"6574","inReplyTo":"45C2F648.9030105@zytor.com","subject":"Re: MinGW port usable","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-02-02T08:55:38Z","receivedAt":"2007-02-02T08:55:38Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"H. Peter Anvin wrote:\n> H. Peter Anvin wrote:\n>>\n>> Except they are (for NT-based Windows), so you're doing something \n>> goofy. This is a widely used construct, so it can't be that broken.\n>>\n> \n> Erf... I dug through this, and it seems that WriteFile only works on a \n> socket if it has an OVERLAPPED argument now, because the socket is \n> opened for overlapping I/O. This must be new behaviour in XP-SP2, \n> because this definitely wasn't the case when I last played with this \n> stuff back in 2003. The Internet is full of people using this \n> technique, but I haven't found a way to get a socket which is *not* \n> opened for overlapping I/O.\n> \n> How typical of Microsoft to break an incredibly powerful unified \n> paradigm, sort-of repair it, and then break it again. There doesn't \n> seem to be an obvious way to repair this, either, since MS DLLs won't \n> let you override for example the write() function as called from inside \n> the C runtime DLL.\n> \n> \"Some people are just a total waste of carbon...\"\n> \n\n**HAH***\n\nI found a workaround after all. The trick is to use WSASocket() with a \nlast argument 0 instead of socket().\n\nI feel dirty now...\n\n\n#include \n#include \n#include \n\n#define socket(a,b,c) sane_socket(a,b,c)\n\nint sane_socket(int domain, int type, int protocol)\n{\n\tSOCKET s;\n\tint fd;\n\n\ts = WSASocket(domain, type, protocol, NULL, 0, 0);\n\tif (s == INVALID_SOCKET) {\n\t\t/*\n\t\t * WSAGetLastError() values seem to be mostly\n\t\t * errno+10000; verify this or replace this with\n\t\t * a switch statement...\n\t\t */\n\t\terrno = WSAGetLastError() - 10000;\n\t\treturn -1;\n\t}\n\t\n\tfd = _open_osfhandle(s, 0);\n\tif (fd < 0)\n\t\tclosesocket(s);\n\n\treturn fd;\n}\n"}]}