{"thread":{"id":"6440","subject":"MinGW port - initial work uploaded","startedAt":"2007-01-19T20:48:20Z","lastAt":"2007-02-08T17:22:58Z","messageCount":53,"participants":["Johannes Sixt","Christian MICHON","Michael","Shawn O. Pearce","Johannes Schindelin","Linus Torvalds","Jakub Narebski","Andy Parkins","Nguyen Thai Ngoc Duy","Alex Riesen","Junio C Hamano","H. Peter Anvin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"32084","messageId":"200701192148.20206.johannes.sixt@telecom.at","threadId":"6440","inReplyTo":null,"subject":"MinGW port - initial work uploaded","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-01-19T20:48:20Z","receivedAt":"2007-01-19T20:48:20Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"I've been working on a MinGW port for some time now. I've pushed out what I \nhave so far to a git.git fork at repo.or.cz. For details on how and what to \nclone, please look at the top of\n\nhttp://repo.or.cz/w/git/mingw.git\n\nThanks go to Johannes Schindelin for his initial work, which gave me quite a \nquick-start.\n\nStatus\n------\nSo far I've used the tools only to run the test suite. According to that, all \ntools that are needed to manipulate a repository locally work.\n\nclone, fetch, push does not work yet.\n\nContributions\n-------------\nIf you want to contribute, please consider using the mob branch in this \nrepository. That branch is publically writable. Since I assume that \ncontributions will not be too frequent, it should be ok that you push your \npatches there (without pulling it first), then notify me, and I download them \nbefore someone else overwrites them.\n\n-- Hannes\n"},{"id":"32098","messageId":"46d6db660701191447w3011908btce140a7bbdeab37b@mail.gmail.com","threadId":"6440","inReplyTo":"200701192148.20206.johannes.sixt@telecom.at","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-19T22:47:07Z","receivedAt":"2007-01-19T22:47:07Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"good to know some progress has been done in this direction.\nthanks in advance!\n\nquick question: how do I download it from windows, if I do not\nhave git already installed ? (chicken and egg)\n\nOn 1/19/07, Johannes Sixt wrote:\n> I've been working on a MinGW port for some time now. I've pushed out what I\n> have so far to a git.git fork at repo.or.cz. For details on how and what to\n> clone, please look at the top of\n>\n> http://repo.or.cz/w/git/mingw.git\n>\n> Thanks go to Johannes Schindelin for his initial work, which gave me quite a\n> quick-start.\n>\n> Status\n> ------\n> So far I've used the tools only to run the test suite. According to that, all\n> tools that are needed to manipulate a repository locally work.\n>\n> clone, fetch, push does not work yet.\n>\n> Contributions\n> -------------\n> If you want to contribute, please consider using the mob branch in this\n> repository. That branch is publically writable. Since I assume that\n> contributions will not be too frequent, it should be ok that you push your\n> patches there (without pulling it first), then notify me, and I download them\n> before someone else overwrites them.\n>\n> -- Hannes\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-- \nChristian\n--\n << There's a symlink from awk to gawk, if you're using gawk!\nIf you're not using gawk, there's no symlink from gawk to awk!\nUse the standard names, _please_! >> - Rob Landley\n"},{"id":"32112","messageId":"200701200053.17190.barra_cuda@katamail.com","threadId":"6440","inReplyTo":"46d6db660701191447w3011908btce140a7bbdeab37b@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Michael","fromEmail":"barra_cuda@katamail.com","sentAt":"2007-01-19T23:53:17Z","receivedAt":"2007-01-19T23:53:17Z","isPatch":false,"sender":{"key":"barra_cuda@katamail.com","avatar":"https://avatars.githubusercontent.com/u/16371673?v=4"},"body":"Christian MICHON:\n> quick question: how do I download it from windows, if I do not\n> have git already installed ? (chicken and egg)\n\nYou can click on the \"snapshot\" link of the tree you're interested in. You'll \ndownload a tar.gz file containing that tree.\n"},{"id":"32138","messageId":"20070120033149.GB11200@spearce.org","threadId":"6440","inReplyTo":"200701192148.20206.johannes.sixt@telecom.at","subject":"Re: MinGW port - initial work uploaded","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-20T03:31:49Z","receivedAt":"2007-01-20T03:31:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Sixt wrote:\n> I've been working on a MinGW port for some time now. I've pushed out what I \n> have so far to a git.git fork at repo.or.cz. For details on how and what to \n> clone, please look at the top of\n\nCan I make a few suggestions?\n\nBase your branch on Junio's 'master', not 'next'. This looks like\nits going to be a fairly long-running topic with a large number\nof commits. It will be easier to convince Junio to pull the topic\nin if its based solely on 'master' than if its based on 'next'.\n\nI made the mistake of building my git-fast-import topic on top of\n'next' back in Aug. 2006. Its still going and has not yet merged\ninto git.git. I finally went through the pain of rebasing it onto\n'master' to make the merge easier for Junio post 1.5.0. Of course\ngfi is also less intrusive than this topic will be.\n\n\nThe other is maybe try to avoid:\n\n\t#ifndef __MINGW32__\n\t...\n\t#endif\n\ninstead try to use something like:\n\n\tgit-compat-util:\n\t#ifdef __MINGW32__\n\t#define is_mingw32 1\n\t#else\n\t#define is_mingw32 0\n\t#endif\n\n\teverywhere else:\n\tif (is_mingw32) {\n\t}\n\nThis way the code within the block can be syntax checked, etc. on\nnon-MinGW platforms but will be removed by the compiler on those\nnon-MinGW systems. I just went through trying to do a #ifndef thing\nfor Windows (1510fea7 in git.git, aka the NO_FAST_WORKING_DIRECTORY\nflag) and Junio rightly rejected my first attempt which used #ifndef,\nand instead used something like the above.\n \n-- \nShawn.\n"},{"id":"32141","messageId":"Pine.LNX.4.63.0701201023460.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"20070120033149.GB11200@spearce.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-20T09:24:49Z","receivedAt":"2007-01-20T09:24:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Shawn O. Pearce wrote:\n\n> Johannes Sixt wrote:\n> > I've been working on a MinGW port for some time now. I've pushed out what I \n> > have so far to a git.git fork at repo.or.cz. For details on how and what to \n> > clone, please look at the top of\n> \n> Can I make a few suggestions?\n> \n> Base your branch on Junio's 'master', not 'next'.\n\nBlame me, not Johannes ;-)\n\nAs for the #ifdef stuff, I'd rather have a look if it can't be done \ncleanly by conditional compiling, like we do for NO_MMAP, for example.\n\nCiao,\nDscho\n"},{"id":"32167","messageId":"200701202105.23861.johannes.sixt@telecom.at","threadId":"6440","inReplyTo":"20070120033149.GB11200@spearce.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-01-20T20:05:23Z","receivedAt":"2007-01-20T20:05:23Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Saturday 20 January 2007 04:31, Shawn O. Pearce wrote:\n> Base your branch on Junio's 'master', not 'next'. This looks like\n> its going to be a fairly long-running topic with a large number\n> of commits. It will be easier to convince Junio to pull the topic\n> in if its based solely on 'master' than if its based on 'next'.\n\nI consider this branch only the sandbox for the MinGW port.\n\nAlthough I've tried to make the branch as clean as possible, it is still a bit \nmessy, and not everything is #ifdef'd that should be. For this reason I will \nnot try to convince Junio to pull this topic directly. The goal is rather to \nwork towards a complete port, then later factor out patches that \nbring 'master' or 'next' closer to this branch so that finally only at most a \nsmall patch series is needed that contains this topic.\n\n> \tgit-compat-util:\n> \t#ifdef __MINGW32__\n> \t#define is_mingw32 1\n> \t#else\n> \t#define is_mingw32 0\n> \t#endif\n>\n> \teverywhere else:\n> \tif (is_mingw32) {\n> \t}\n\nI like this idea.\n\n-- Hannes\n"},{"id":"32171","messageId":"46d6db660701201221t786b0918o6b218108a8cb1545@mail.gmail.com","threadId":"6440","inReplyTo":"200701202105.23861.johannes.sixt@telecom.at","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-20T20:21:25Z","receivedAt":"2007-01-20T20:21:25Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"Hi Johannes(s) and list,\n\nI managed a compilation, and some commands work, some don't.\nUp to the first git commit, all is find.\n\nI need to invoke the commit through the git-commit actually,\n\"git commit\" says it's not a valid git command. so bash is a\ntrue need in this case, might not even work in pure win32\ncmd.exe approach.\n\nFurthermore, once the commit is in, \"git log\" and git-log\ndo not work. Same for git-whatchanged and git-diff.\n\nI need to try with the specific versions you mentionned, but\nit's a pretty good start :)\n\n--\nChristian\n"},{"id":"32290","messageId":"46d6db660701220506t20214d3bi4d0e1e93abd01aad@mail.gmail.com","threadId":"6440","inReplyTo":"200701192148.20206.johannes.sixt@telecom.at","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-22T13:06:48Z","receivedAt":"2007-01-22T13:06:48Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"ok,\n\nI upgraded some msys and mingw components, and took today's\nsnapshot of mingw.git.\n\nI can now do many local tasks :)\n\nOne problem I haven't found a solution for though: the date\nof commit is wrong, always back to epoch (1970???).\n\nSee attached:\n\n$ git init-db\nInitialized empty Git repository in .git/\n$ git add .\n$ git commit -a -m ok\nCreated initial commit d52832ca5120626bfcc35360d7fd3914ccb6d11f\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 a\n$ git log\ncommit d52832ca5120626bfcc35360d7fd3914ccb6d11f\nAuthor: Christian MICHON \nDate: Thu Jan 1 00:00:00 1970 +0000\n\n ok\n\n--\nChristian\n"},{"id":"32308","messageId":"Pine.LNX.4.64.0701220823260.32200@woody.linux-foundation.org","threadId":"6440","inReplyTo":"46d6db660701220506t20214d3bi4d0e1e93abd01aad@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-22T16:39:38Z","receivedAt":"2007-01-22T16:39:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 22 Jan 2007, Christian MICHON wrote:\n> \n> One problem I haven't found a solution for though: the date\n> of commit is wrong, always back to epoch (1970???).\n\nWithout knowing MinGW, I'd assume it's one of two issues:\n\n - parse_date will probably do this when the date is empty. The way git \n works, is it takes the date from the GIT_COMMITTER|AUTHOR_DATE \n environment variables, and it depends on getenv() returning NULL if \n that environment variable isn't set.\n\n Maybe getenv() under MinGW always returns a real string, and it's just \n empty? If so, get_ident() should probably be changed from doing\n\n\tif (date_str)\n\t\tparse_date(...)\n\n to\n\n\tif (date_str && *date_str)\n\t\tparse_date(...)\n\n or something like that.\n\n - datestamp() uses \"time()\" to get the number of seconds since the epoch. \n HOWEVER, it does it by actually doing\n\n\ttime_t now;\n\n\ttime(&now);\n\n which is proper, but maybe a bit unusual. Try changing that to\n\n\tnow = time(NULL);\n\n and see if that changes behaviour (it's datestamp() in date.c).\n\n Alternatively, if \"time()\" just doesn't work in MinGW, just use \n gettimeofday() instead, something like\n\n\ttime_t now;\n\tint offset;\n\tstruct timeval tv;\n\tstruct timezone tz;\n\n\t/* Just in case not everybody necessarily fills in TZ correctly.. */\n\tmemset(&tz, 0, sizeof(tz));\n\tgettimeofday(&tv, &tz);\n\tnow = tv.tv_sec;\n\toffset = tz.tz_minuteswest;\n\n instead of the current mess with localtime() and company.\n\n [ NOTE NOTE NOTE! The above gettimeofday() thing has NOT been tested. \n Using the \"tz\" value to gettimeofday() is generally considered a bug, \n and shouldn't really be done. It's very traditional (read: \n old-fashioned) and very incorrect (it will ignore the TZ variable, \n and ask the kernel, which generally has no clue at all about \n timezones). But maybe it works on MinGW, so it might be worth \n testing. ]\n\nAnyway. I have no idea of Windows or MinGW, or what you did to make it all \ncompile, so..\n\n\t\tLinus\n"},{"id":"32327","messageId":"200701222127.09601.johannes.sixt@telecom.at","threadId":"6440","inReplyTo":"46d6db660701220506t20214d3bi4d0e1e93abd01aad@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2007-01-22T20:27:09Z","receivedAt":"2007-01-22T20:27:09Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Monday 22 January 2007 14:06, Christian MICHON wrote:\n> One problem I haven't found a solution for though: the date\n> of commit is wrong, always back to epoch (1970???).\n\nI've pushed out a fix for this.\n\nAlso, t/t5500-fetch-pack.sh passes now all tests.\n\nOTOH, git log, git diff, etc, which run the pager by default, are broken. It \nseems that the pipe is not correctly flushed by the writer, which the MinGW \nport closes in an atexit() routine, so that the last part of the piped data \nis missing. I have no clue how to fix this except by disabling the pager.\n\n-- Hannes\n"},{"id":"32345","messageId":"46d6db660701221420i6f439972h2c6c6146fed78097@mail.gmail.com","threadId":"6440","inReplyTo":"200701222127.09601.johannes.sixt@telecom.at","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-22T22:20:22Z","receivedAt":"2007-01-22T22:20:22Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/22/07, Johannes Sixt wrote:\n> On Monday 22 January 2007 14:06, Christian MICHON wrote:\n> > One problem I haven't found a solution for though: the date\n> > of commit is wrong, always back to epoch (1970???).\n>\n> I've pushed out a fix for this.\n>\n\nit seems to be in the snapshot I just evaluated:\nmingw.git-d576539c9255d22425efcc55f7e9720fbb8a42d1\n\nindeed, it's fixed!\n\nI'll run more regressions tomorrow (like the one I posted,\nusing 117 versions of linux-2.6 kernels).\n\n--\nChristian\n"},{"id":"32346","messageId":"46d6db660701221425i672e826coc9eef4bd8d22ae9d@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701220823260.32200@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-22T22:25:57Z","receivedAt":"2007-01-22T22:25:57Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/22/07, Linus Torvalds wrote:\n> Anyway. I have no idea of Windows or MinGW, or what you did to make it all\n> compile, so..\n>\n> Linus\n>\n\nthanks Linus for your suggestions. the kudos for making it work go to\nJohannes Sixt and Johannes Schindelin!\n\nthe only recent alternative on Windows I came with was to run git\nthrough coLinux and share directories using cofs.\n\nnow I can use the \"content tracker from Hell\" on Windows. :)\n\n--\nChristian\n"},{"id":"32372","messageId":"46d6db660701230031w606b1c91qd93d19a1c00aff19@mail.gmail.com","threadId":"6440","inReplyTo":"200701222127.09601.johannes.sixt@telecom.at","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-23T08:31:14Z","receivedAt":"2007-01-23T08:31:14Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/22/07, Johannes Sixt wrote:\n> Also, t/t5500-fetch-pack.sh passes now all tests.\n>\n> OTOH, git log, git diff, etc, which run the pager by default, are broken. It\n> seems that the pipe is not correctly flushed by the writer, which the MinGW\n> port closes in an atexit() routine, so that the last part of the piped data\n> is missing. I have no clue how to fix this except by disabling the pager.\n>\n\nanother good news: gitk is working too on windoze :)\ngood work! thanks!\n\n--\nChristian\n"},{"id":"32382","messageId":"Pine.LNX.4.63.0701231220470.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701220823260.32200@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T11:25:36Z","receivedAt":"2007-01-23T11:25:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Jan 2007, Linus Torvalds wrote:\n\n> Maybe getenv() under MinGW always returns a real string, and it's just \n> empty?\n\nNo. It is not Oracle: it _does_ return NULL if it is not set, and an empty \nstring iff it is set to an empty string.\n\n> - datestamp() uses \"time()\" to get the number of seconds since the epoch. \n> HOWEVER, it does it by actually doing\n> \n> \ttime_t now;\n> \n> \ttime(&now);\n> \n> which is proper, but maybe a bit unusual.\n\nMinGW does that quite fine (actually, it just calls the MS C Runtime \nlibrary; maybe they still had a clue bat back when they wrote that?).\n\n> Alternatively, if \"time()\" just doesn't work in MinGW, just use \n> gettimeofday() instead, [...]\n\nFunnily enough, MinGW does not have gettimeofday(). Actually, for purposes \nof getting git to compile, I had to\n\n\tint gettimeofday(struct timeval *tv, void *tz)\n\t{\n\t return -1;\n\t}\n\n;-)\n\n> Anyway. I have no idea of Windows or MinGW, or what you did to make it \n> all compile, so..\n\nLucky you! Fortunately, I don't have any Windows at home (but I still have \nwindows, thank God!). So I cannot even be tempted to work on this thing in \nmy free time.\n\nCiao,\nDscho\n"},{"id":"32384","messageId":"Pine.LNX.4.63.0701231227200.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"200701222127.09601.johannes.sixt@telecom.at","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T11:32:47Z","receivedAt":"2007-01-23T11:32:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 22 Jan 2007, Johannes Sixt wrote:\n\n> OTOH, git log, git diff, etc, which run the pager by default, are \n> broken. It seems that the pipe is not correctly flushed by the writer, \n> which the MinGW port closes in an atexit() routine, so that the last \n> part of the piped data is missing. I have no clue how to fix this except \n> by disabling the pager.\n\nMaybe we have to go the other way round, just as POSIX git does: instead \nof spawning the pager, we should _beginthread() the actual work, and \nexecl() the pager.\n\nOn the third hand, I fully expect git on Windows to be used only by GUI \nwieners who cannot handle the command line, let alone a pager! (\"WTF! How \ndo I go back to that dollar thingie? You know, where I type git-blabla?\")\n\nSince Tcl/Tk is available for MinGW, git-gui seems to be a way to go \nthere.\n\nOr to continue on the TortoiseCVS lookalike...\n\nCiao,\nDscho\n"},{"id":"32385","messageId":"ep4tmd$ut8$1@sea.gmane.org","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231227200.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-23T12:06:24Z","receivedAt":"2007-01-23T12:06:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin wrote:\n\n> Since Tcl/Tk is available for MinGW, git-gui seems to be a way to go \n> there.\n\nSince Qt4 is to work in Windows natively, perhaps QGit is a way to go...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"32391","messageId":"46d6db660701230508g41e7656dwf3f720aa4255b617@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231220470.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-23T13:08:08Z","receivedAt":"2007-01-23T13:08:08Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"> Lucky you! Fortunately, I don't have any Windows at home (but I still have\n> windows, thank God!). So I cannot even be tempted to work on this thing in\n> my free time.\n\nwell, you could cross compile it and run it through Wine ?\n:)\n\n--\nChristian\n"},{"id":"32393","messageId":"46d6db660701230512l571d8c35k24e475c3fe0933cf@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231227200.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-23T13:12:48Z","receivedAt":"2007-01-23T13:12:48Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/23/07, Johannes Schindelin wrote:\n> Maybe we have to go the other way round, just as POSIX git does: instead\n> of spawning the pager, we should _beginthread() the actual work, and\n> execl() the pager.\n\nactually, one other issue is the spawning of vim when doing commits.\nI usually end up in using -m \"my commit message\" because of these\n2 errors (basically terminal not recognized, I tried many different\noptions to no avail)\n\n$ git commit -a\nVim: Warning: Output is not to a terminal\nVim: Warning: Input is not from a terminal\n\n> On the third hand, I fully expect git on Windows to be used only by GUI\n> wieners who cannot handle the command line, let alone a pager! (\"WTF! How\n> do I go back to that dollar thingie? You know, where I type git-blabla?\")\n\nmaybe I'm stuck with windows at work, but I still use vim inside mingw.\nit would be nice to fix the pager issue...\n\n>\n> Since Tcl/Tk is available for MinGW, git-gui seems to be a way to go\n> there.\n\nI did not know about this... let me try... yes! not bad...\nit's working too, so your assumption was correct.\n\nthanks for the suggestion.\n\n--\nChristian\n"},{"id":"32396","messageId":"200701231322.32987.andyparkins@gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231227200.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-23T13:22:31Z","receivedAt":"2007-01-23T13:22:31Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 January 23 11:32, Johannes Schindelin wrote:\n\n> Maybe we have to go the other way round, just as POSIX git does: instead\n> of spawning the pager, we should _beginthread() the actual work, and\n> execl() the pager.\n\nWhat about just forgetting paged output under Windows? It's been a while, but \nthe only decent one that I ever found was LIST.COM, and that's probably \nvanished now.\n\nI haven't used Windows in a while, are pipes still as awful as they were? \nThat is to say they cheated and redirected output to a temporary file then \nredirected that file to the input of the second process. The upshot of which \nwas you had to have the whole pipe complete before you could view the first \npage of output.\n\nI can well imagine that in Windows I would find the paged output more painful \nthan useful.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"32399","messageId":"fcaeb9bf0701230536p536f3326w36f2b272c869c5cf@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231227200.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-01-23T13:36:01Z","receivedAt":"2007-01-23T13:36:01Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 1/23/07, Johannes Schindelin wrote:\n> On the third hand, I fully expect git on Windows to be used only by GUI\n> wieners who cannot handle the command line, let alone a pager! (\"WTF! How\n> do I go back to that dollar thingie? You know, where I type git-blabla?\")\n\nIf I have to use git on Windows (very likely now that this port seems\nto work), I'd much prefer command line interface. cmd.exe may be not\ngood enough so I think we should include bash in git-win32 package.\nMany git commands are still bash scripts and new commands are often\ncoded as bash scripts. So we need bash in Windows anyway unless\nWindows Git users accept a limited git version. (no-perl git is\nacceptable to me).\n-- \nDuy\n"},{"id":"32402","messageId":"Pine.LNX.4.63.0701231514080.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"fcaeb9bf0701230536p536f3326w36f2b272c869c5cf@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T14:15:28Z","receivedAt":"2007-01-23T14:15:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On 1/23/07, Johannes Schindelin wrote:\n> > On the third hand, I fully expect git on Windows to be used only by GUI\n> > wieners who cannot handle the command line, let alone a pager! (\"WTF! How\n> > do I go back to that dollar thingie? You know, where I type git-blabla?\")\n> \n> If I have to use git on Windows (very likely now that this port seems\n> to work), I'd much prefer command line interface. cmd.exe may be not\n> good enough so I think we should include bash in git-win32 package.\n> Many git commands are still bash scripts and new commands are often\n> coded as bash scripts. So we need bash in Windows anyway unless\n> Windows Git users accept a limited git version. (no-perl git is\n> acceptable to me).\n\nActually, you cannot work _at all_ with git when you don't have a proper \nshell.\n\nCiao,\nDscho\n"},{"id":"32403","messageId":"Pine.LNX.4.63.0701231516100.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"46d6db660701230508g41e7656dwf3f720aa4255b617@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T14:17:12Z","receivedAt":"2007-01-23T14:17:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Christian MICHON wrote:\n\n> > Lucky you! Fortunately, I don't have any Windows at home (but I still have\n> > windows, thank God!). So I cannot even be tempted to work on this thing in\n> > my free time.\n> \n> well, you could cross compile it and run it through Wine ?\n> :)\n\nYou could. But it would probably only uncover a few bugs in obscure use \ncases. But hey, it's Open Source, so go wild.\n\nCiao,\nDscho\n"},{"id":"32404","messageId":"Pine.LNX.4.63.0701231517290.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"46d6db660701230512l571d8c35k24e475c3fe0933cf@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T14:18:25Z","receivedAt":"2007-01-23T14:18:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Christian MICHON wrote:\n\n> On 1/23/07, Johannes Schindelin wrote:\n> > Maybe we have to go the other way round, just as POSIX git does: instead\n> > of spawning the pager, we should _beginthread() the actual work, and\n> > execl() the pager.\n> \n> actually, one other issue is the spawning of vim when doing commits.\n> I usually end up in using -m \"my commit message\" because of these\n> 2 errors (basically terminal not recognized, I tried many different\n> options to no avail)\n> \n> $ git commit -a\n> Vim: Warning: Output is not to a terminal\n> Vim: Warning: Input is not from a terminal\n> \n> > On the third hand, I fully expect git on Windows to be used only by GUI\n> > wieners who cannot handle the command line, let alone a pager! (\"WTF! How\n> > do I go back to that dollar thingie? You know, where I type git-blabla?\")\n> \n> maybe I'm stuck with windows at work, but I still use vim inside mingw.\n\nI don't:\n\n$ vi\nm.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000, \nm.State 0x10000\nC:\\msys1\\bin\\vim.exe: *** Couldn't reserve space for cygwin's heap \n(0x715B0000 <0xB10000>) in child, Win32 error 487\n\n> it would be nice to fix the pager issue...\n\nGo ahead!\n\nCiao,\nDscho\n"},{"id":"32405","messageId":"Pine.LNX.4.63.0701231518310.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"200701231322.32987.andyparkins@gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T14:21:55Z","receivedAt":"2007-01-23T14:21:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Andy Parkins wrote:\n\n> On Tuesday 2007 January 23 11:32, Johannes Schindelin wrote:\n> \n> > Maybe we have to go the other way round, just as POSIX git does: instead\n> > of spawning the pager, we should _beginthread() the actual work, and\n> > execl() the pager.\n> \n> What about just forgetting paged output under Windows? It's been a \n> while, but the only decent one that I ever found was LIST.COM, and \n> that's probably vanished now.\n\nUhm. You do understand that we use MinGW to port to, not _plain_ Windows? \nSo we do have a \"less\".\n\n> I haven't used Windows in a while, are pipes still as awful as they \n> were? That is to say they cheated and redirected output to a temporary \n> file then redirected that file to the input of the second process.\n\nThat was not Windows. That was DOS.\n\n> I can well imagine that in Windows I would find the paged output more \n> painful than useful.\n\nNot if you are used to it.\n\nIf you have to open a window to write into, with scrollbars and all, you \neither have to wait for the revision walker to finish, or you update it \nconstantly, which is a huge performance hit on Windows (and you have to \njump through hoops to avoid flicker).\n\nWith less, on the other hand, you just exit the pager, or let it search \nthrough stdin. It is so much more convenient.\n\nCiao,\nDscho\n"},{"id":"32412","messageId":"200701231506.32396.andyparkins@gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231518310.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-23T15:06:31Z","receivedAt":"2007-01-23T15:06:31Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 January 23 14:21, Johannes Schindelin wrote:\n\n> Uhm. You do understand that we use MinGW to port to, not _plain_ Windows?\n> So we do have a \"less\".\n\nNope; I didn't. Oh dear. I've obviously misunderstood. I thought MinGW was \nfor compiling to native Windows? Do you use MinGW to compile to cygwin as \nwell?\n\n> That was not Windows. That was DOS.\n\nI'm sure pipes were still awful in Win98. I accept though, that it is \npossible Windows has changed in the last 9 years :-)\n\n> With less, on the other hand, you just exit the pager, or let it search\n> through stdin. It is so much more convenient.\n\nThat sounds better than I remember. You'll have talked me into migrating to \nWindows soon :-)\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"32413","messageId":"Pine.LNX.4.63.0701231614490.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"200701231506.32396.andyparkins@gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T15:20:31Z","receivedAt":"2007-01-23T15:20:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Andy Parkins wrote:\n\n> On Tuesday 2007 January 23 14:21, Johannes Schindelin wrote:\n> \n> > Uhm. You do understand that we use MinGW to port to, not _plain_ \n> > Windows? So we do have a \"less\".\n> \n> Nope; I didn't. Oh dear. I've obviously misunderstood. I thought \n> MinGW was for compiling to native Windows? Do you use MinGW to compile \n> to cygwin as well?\n\nMinGW and cygwin differ in one very important point: cygwin needs an extra \ndll, MinGW does not.\n\nHowever, the development environment is still console-based, with a bash \nso you can run configure and simple bash scripts. It is definitely more \ncatering to Unix types than Windows types.\n\nSo yes, there is a bash, and there is a less, and there is perl.\n\n> > That was not Windows. That was DOS.\n> \n> I'm sure pipes were still awful in Win98. I accept though, that it is \n> possible Windows has changed in the last 9 years :-)\n\nWin98 was based on DOS. Windows XP is based on VMS.\n\n\nYes, I know. They left everything behind, and started Windows NT anew. \nYeah, right.\n\n\n> > With less, on the other hand, you just exit the pager, or let it \n> > search through stdin. It is so much more convenient.\n> \n> That sounds better than I remember. You'll have talked me into \n> migrating to Windows soon :-)\n\nI don't understand. The command \"less\" is the default pager of git, so you \nare prone to have used it already.\n\nCiao,\nDscho\n"},{"id":"32414","messageId":"20070123152904.GA23549@spearce.org","threadId":"6440","inReplyTo":"ep4tmd$ut8$1@sea.gmane.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-23T15:29:04Z","receivedAt":"2007-01-23T15:29:04Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Johannes Schindelin wrote:\n> \n> > Since Tcl/Tk is available for MinGW, git-gui seems to be a way to go \n> > there.\n> \n> Since Qt4 is to work in Windows natively, perhaps QGit is a way to go...\n\nChoice is good. ;-)\n\ngit-gui has slightly different goals/focus than QGit. I think\nits a better commit creation tool.\n\n-- \nShawn.\n"},{"id":"32416","messageId":"Pine.LNX.4.64.0701230736180.32200@woody.linux-foundation.org","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231220470.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-23T15:37:15Z","receivedAt":"2007-01-23T15:37:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 Jan 2007, Johannes Schindelin wrote:\n> \n> Lucky you! Fortunately, I don't have any Windows at home (but I still have \n> windows, thank God!). So I cannot even be tempted to work on this thing in \n> my free time.\n\nActually, I have been seriously wondering if there is some setup under \nWine that I could run, just so that I'd see the Windows development \nenvironment for git.\n\nHas anybody tried anything like that? \n\n\t\tLinus\n"},{"id":"32417","messageId":"81b0412b0701230745g4b18747ep73d37674a969c1aa@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701230736180.32200@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-23T15:45:58Z","receivedAt":"2007-01-23T15:45:58Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/23/07, Linus Torvalds wrote:\n> >\n> > Lucky you! Fortunately, I don't have any Windows at home (but I still have\n> > windows, thank God!). So I cannot even be tempted to work on this thing in\n> > my free time.\n>\n> Actually, I have been seriously wondering if there is some setup under\n> Wine that I could run, just so that I'd see the Windows development\n> environment for git.\n\nYou have to stea... purchase large parts of windows to get enough\nof it to be able to develop on it. I tried to run installers under\nWine: nothing worked until the not-to-be-mentioned parts\n(ok, the whole \"Windows\" and \"Program Files\" directories from an\nexisting installation) were provided. I didn't tried cygwin, though.\n\n> Has anybody tried anything like that?\n\nWhy would anyone want to try anything like that?\n"},{"id":"32418","messageId":"Pine.LNX.4.63.0701231647390.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701230736180.32200@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T15:49:59Z","receivedAt":"2007-01-23T15:49:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Linus Torvalds wrote:\n\n> On Tue, 23 Jan 2007, Johannes Schindelin wrote:\n> > \n> > Lucky you! Fortunately, I don't have any Windows at home (but I still \n> > have windows, thank God!). So I cannot even be tempted to work on this \n> > thing in my free time.\n> \n> Actually, I have been seriously wondering if there is some setup under \n> Wine that I could run, just so that I'd see the Windows development \n> environment for git.\n\nIMHO the best way to go ahead is to download ReactOS, and run it inside \nQEmu. That way you'll get a better idea of the speed and integration.\n\nCiao,\nDscho\n"},{"id":"32419","messageId":"Pine.LNX.4.63.0701231650560.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"81b0412b0701230745g4b18747ep73d37674a969c1aa@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T15:52:12Z","receivedAt":"2007-01-23T15:52:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Alex Riesen wrote:\n\n> I tried to run installers under Wine: nothing worked until the \n> not-to-be-mentioned parts (ok, the whole \"Windows\" and \"Program Files\" \n> directories from an existing installation) were provided. I didn't tried \n> cygwin, though.\n\nSince when did you not check? According to Wine's git commit messages \n(yeah!) they worked really hard to get installers going.\n\n> > Has anybody tried anything like that?\n> \n> Why would anyone want to try anything like that?\n\nCuriosity.\n\nCiao,\nDscho\n"},{"id":"32420","messageId":"20070123155311.GB23549@spearce.org","threadId":"6440","inReplyTo":"81b0412b0701230745g4b18747ep73d37674a969c1aa@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-23T15:53:11Z","receivedAt":"2007-01-23T15:53:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On 1/23/07, Linus Torvalds wrote:\n>Actually, I have been seriously wondering if there is some setup under\n>Wine that I could run, just so that I'd see the Windows development\n>environment for git.\n\nModify Linux VFS layer to:\n\n - make open take about 10x longer\n - make lstat take about 20x longer\n\nand finally remove any useful programs, except Git. Use the worst\nxterm available. You are left with a close approximation.\n\n-- \nShawn.\n"},{"id":"32422","messageId":"81b0412b0701230756l72066207o920b008554a70f12@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231650560.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-01-23T15:56:38Z","receivedAt":"2007-01-23T15:56:38Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 1/23/07, Johannes Schindelin wrote:\n>\n> > I tried to run installers under Wine: nothing worked until the\n> > not-to-be-mentioned parts (ok, the whole \"Windows\" and \"Program Files\"\n> > directories from an existing installation) were provided. I didn't tried\n> > cygwin, though.\n>\n> Since when did you not check? According to Wine's git commit messages\n> (yeah!) they worked really hard to get installers going.\n>\n\nSince quite a while (some months), I must admit. Have you tried it?\n"},{"id":"32423","messageId":"Pine.LNX.4.63.0701231700110.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"81b0412b0701230756l72066207o920b008554a70f12@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T16:00:37Z","receivedAt":"2007-01-23T16:00:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Alex Riesen wrote:\n\n> On 1/23/07, Johannes Schindelin wrote:\n> > \n> > > I tried to run installers under Wine: nothing worked until the\n> > > not-to-be-mentioned parts (ok, the whole \"Windows\" and \"Program Files\"\n> > > directories from an existing installation) were provided. I didn't tried\n> > > cygwin, though.\n> > \n> > Since when did you not check? According to Wine's git commit messages\n> > (yeah!) they worked really hard to get installers going.\n> > \n> \n> Since quite a while (some months), I must admit. Have you tried it?\n\nNope. Didn't have to. A friend did. Said it worked amazingly well.\n\nCiao,\nDscho\n"},{"id":"32427","messageId":"200701231624.41716.andyparkins@gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231614490.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-23T16:24:40Z","receivedAt":"2007-01-23T16:24:40Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 January 23 15:20, Johannes Schindelin wrote:\n\n> MinGW and cygwin differ in one very important point: cygwin needs an extra\n> dll, MinGW does not.\n>\n> However, the development environment is still console-based, with a bash\n> so you can run configure and simple bash scripts. It is definitely more\n> catering to Unix types than Windows types.\n>\n> So yes, there is a bash, and there is a less, and there is perl.\n\nThose are just tools for MinGW though aren't they? They aren't needed to run \nthe final executable object? MinGW just spits out a native windows .exe - \ni.e. plain windows. There is no reason to suppose that joe-random-developer \nwill have bash, less and perl, even if they do have git. Which was kind of \nthe point I was making - there is no pager to rely on in Windows, so why not \njust drop it. Okay, so MinGW comes with some nice UNIXy tools, but MinGW is \nthe compiler, not the environment.\n\nAm I still misunderstanding? I'm looking out for the time when\n\nC:\\SomePath> git commit -a\n\nwill work (I know - it's a long way off yet). Not for me; I don't care about \nWindows in the slightest; but some of my colleagues use it, and I'd like to \nspread the git-religion as far as I can.\n\n> > That sounds better than I remember. You'll have talked me into\n> > migrating to Windows soon :-)\n>\n> I don't understand. The command \"less\" is the default pager of git, so you\n> are prone to have used it already.\n\nOf course I have; I was trying (failing) to be amusing. :-)\n\nWhenever I'm forced to use Windows, it's lack of the most basic of command \nline tools drives me insane, so you saying that less is easily available with \ngood pipe support would ease my insanity slightly if were ever to go back to \nthe dark place.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"32430","messageId":"Pine.LNX.4.63.0701231732120.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"200701231624.41716.andyparkins@gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T16:37:17Z","receivedAt":"2007-01-23T16:37:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Andy Parkins wrote:\n\n> On Tuesday 2007 January 23 15:20, Johannes Schindelin wrote:\n> \n> > MinGW and cygwin differ in one very important point: cygwin needs an extra\n> > dll, MinGW does not.\n> >\n> > However, the development environment is still console-based, with a bash\n> > so you can run configure and simple bash scripts. It is definitely more\n> > catering to Unix types than Windows types.\n> >\n> > So yes, there is a bash, and there is a less, and there is perl.\n> \n> Those are just tools for MinGW though aren't they? They aren't needed to run \n> the final executable object? MinGW just spits out a native windows .exe - \n> i.e. plain windows.\n\nYes. But it _does_ have a dependency on perl and bash. For example, when \nyou merge git-merge-one-file is spawned -- a bash script.\n\n> There is no reason to suppose that joe-random-developer will have bash, \n> less and perl, even if they do have git. Which was kind of the point I \n> was making - there is no pager to rely on in Windows, so why not just \n> drop it. Okay, so MinGW comes with some nice UNIXy tools, but MinGW is \n> the compiler, not the environment.\n\nYou reminded me that I was not precise enough: MSYS provides the UNIXy \ntools, and the compiler, MinGW is just the headers and import libraries.\n\nAnd while we already depend on bash and friends -- which we put into \nGIT_EXEC_PATH -- we can ship more: \"less\".\n\n> Am I still misunderstanding? I'm looking out for the time when\n> \n> C:\\SomePath> git commit -a\n> \n> will work (I know - it's a long way off yet).\n\nYou need an editor, that is for sure, but it is not _that_ far off. Thanks \nto Johannes Sixt, committing works already (if you don't encounter the \nsame problem starting vi as I do).\n\nCiao,\nDscho\n"},{"id":"32432","messageId":"Pine.LNX.4.64.0701230852270.32200@woody.linux-foundation.org","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231732120.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-23T17:02:12Z","receivedAt":"2007-01-23T17:02:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 23 Jan 2007, Johannes Schindelin wrote:\n> \n> Yes. But it _does_ have a dependency on perl and bash. For example, when \n> you merge git-merge-one-file is spawned -- a bash script.\n\nThat's just disgusting. I thought we fixed it, but apparently we only did \nso for git-merge-recursive. Hmm?\n\nAll the other uses seem to be just a case of\n\n\tgit-merge-index -o git-merge-one-file -a\n\nand wouldn't it be beautiful if the default action for git-merge-index (if \nyou do _not_ specify a merger program) was to do the simple one-file \nthree-way merge that we can already do for real merges?\n\nWouldn't it be nice if we could just do\n\n\tgit-merge-index -o -a\n\nand be done with it? \n\nJohannes, this should be right up your alley.. Hint hint..\n\n\t\tLinus\n"},{"id":"32434","messageId":"Pine.LNX.4.63.0701231805100.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701230852270.32200@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T17:07:50Z","receivedAt":"2007-01-23T17:07:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Linus Torvalds wrote:\n\n> On Tue, 23 Jan 2007, Johannes Schindelin wrote:\n> > \n> > Yes. But it _does_ have a dependency on perl and bash. For example, when \n> > you merge git-merge-one-file is spawned -- a bash script.\n> \n> That's just disgusting. I thought we fixed it, but apparently we only did \n> so for git-merge-recursive. Hmm?\n> \n> All the other uses seem to be just a case of\n> \n> \tgit-merge-index -o git-merge-one-file -a\n> \n> and wouldn't it be beautiful if the default action for git-merge-index (if \n> you do _not_ specify a merger program) was to do the simple one-file \n> three-way merge that we can already do for real merges?\n\nIf you think that's a new dream:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/32046/match=git-merge-one-file\n\nCiao,\nDscho\n"},{"id":"32438","messageId":"46d6db660701231055u63259fave0f33e9b52fc9bff@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231517290.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-23T18:55:39Z","receivedAt":"2007-01-23T18:55:39Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/23/07, Johannes Schindelin wrote:\n> > maybe I'm stuck with windows at work, but I still use vim inside mingw.\n>\n> I don't:\n>\n> $ vi\n> m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000,\n> m.State 0x10000\n> C:\\msys1\\bin\\vim.exe: *** Couldn't reserve space for cygwin's heap\n> (0x715B0000 <0xB10000>) in child, Win32 error 487\n\ninteresting. which version of msys are you using ?\nI'm using this snapshot successfully:\nmsysCORE-1.0.11-2007.01.19-1\n\n> > it would be nice to fix the pager issue...\n>\n> Go ahead!\n\nwell:\n\ngit log | less\n\n:)\n\nseriously enough, I do not know where to start. I guess we're\nclose to mingw limitations of fork() ??\n\n--\nChristian\n"},{"id":"32440","messageId":"Pine.LNX.4.63.0701232012440.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"46d6db660701231055u63259fave0f33e9b52fc9bff@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T19:18:58Z","receivedAt":"2007-01-23T19:18:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Christian MICHON wrote:\n\n> On 1/23/07, Johannes Schindelin wrote:\n> > > maybe I'm stuck with windows at work, but I still use vim inside mingw.\n> > \n> > I don't:\n> > \n> > $ vi\n> > m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000,\n> > m.State 0x10000\n> > C:\\msys1\\bin\\vim.exe: *** Couldn't reserve space for cygwin's heap\n> > (0x715B0000 <0xB10000>) in child, Win32 error 487\n> \n> interesting. which version of msys are you using ?\n> I'm using this snapshot successfully:\n> msysCORE-1.0.11-2007.01.19-1\n\nI cannot find that file.\n\n> > > it would be nice to fix the pager issue...\n> > \n> > Go ahead!\n> \n> well:\n> \n> git log | less\n> \n> :)\n> \n> seriously enough, I do not know where to start. I guess we're\n> close to mingw limitations of fork() ??\n\nThe problem seems to be more the console attachment. I think that the \npager cannot run properly when fork()ed. Rather, the main process has to \ncontinue with the execl(pager), while the _child_ should continue to run.\n\nSee upload-pack.c for an example how to use _beginthread() to achieve \nsomething along those lines.\n\nHth,\nDscho\n"},{"id":"32441","messageId":"Pine.LNX.4.63.0701232025160.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701232012440.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-23T19:28:51Z","receivedAt":"2007-01-23T19:28:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Johannes Schindelin wrote:\n\n> On Tue, 23 Jan 2007, Christian MICHON wrote:\n> \n> > On 1/23/07, Johannes Schindelin wrote:\n> > > > maybe I'm stuck with windows at work, but I still use vim inside mingw.\n> > > \n> > > I don't:\n> > > \n> > > $ vi\n> > > m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000,\n> > > m.State 0x10000\n> > > C:\\msys1\\bin\\vim.exe: *** Couldn't reserve space for cygwin's heap\n> > > (0x715B0000 <0xB10000>) in child, Win32 error 487\n> > \n> > interesting. which version of msys are you using ?\n> > I'm using this snapshot successfully:\n> > msysCORE-1.0.11-2007.01.19-1\n> \n> I cannot find that file.\n\nI finally found it. I did not look in \"Snapshots\", but in \"Current\" and \n\"Candidate\".\n\nAnd I found the bug: I always extracted with MSYS' own tar in MSYS' own \nrxvt. Windows is very challenged from time to time, for example when \nreplacing files which are in use, and this led to my bash never being \nreplaced.\n\nNow, Windows executables are not so easily relocated, it seems, and the \nold bash kept on nicely clashing with the new vim. It sounds horrible, \nthat one program can take away a memory range from another program, just \nby being not relocatable. And it is.\n\nCiao,\nDscho\n"},{"id":"32472","messageId":"7vlkjtkxlm.fsf@assigned-by-dhcp.cox.net","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701231805100.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-24T01:44:05Z","receivedAt":"2007-01-24T01:44:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> All the other uses seem to be just a case of\n>> \n>> \tgit-merge-index -o git-merge-one-file -a\n>> \n>> and wouldn't it be beautiful if the default action for git-merge-index (if \n>> you do _not_ specify a merger program) was to do the simple one-file \n>> three-way merge that we can already do for real merges?\n>\n> If you think that's a new dream:\n>\n> http://article.gmane.org/gmane.comp.version-control.git/32046/match=git-merge-one-file\n\n(OT: heh, I did not notice Linus's mailing address when I saw\nhis message for the first time).\n\nI've thought about it when I was really bored, but noticed that\nwe have no serious users of git-merge-index/git-merge-one-file\ncombinations anymore in-tree (octopus does not count, and it is\ntrivial to make it use merge-recursive if somebody is twisted\nenough).\n"},{"id":"32477","messageId":"Pine.LNX.4.63.0701240251230.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"7vlkjtkxlm.fsf@assigned-by-dhcp.cox.net","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-24T01:57:28Z","receivedAt":"2007-01-24T01:57:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n>\n> > Linus wrote:\n> >\n> >> All the other uses seem to be just a case of\n> >> \n> >> \tgit-merge-index -o git-merge-one-file -a\n> >> \n> >> and wouldn't it be beautiful if the default action for git-merge-index (if \n> >> you do _not_ specify a merger program) was to do the simple one-file \n> >> three-way merge that we can already do for real merges?\n> >\n> > If you think that's a new dream:\n> >\n> > http://article.gmane.org/gmane.comp.version-control.git/32046/match=git-merge-one-file\n> \n> I've thought about it when I was really bored, but noticed that we have \n> no serious users of git-merge-index/git-merge-one-file combinations \n> anymore in-tree (octopus does not count, and it is trivial to make it \n> use merge-recursive if somebody is twisted enough).\n\nHah! You just pulled the last serious user! That's cheating.\n\nSeriously again, the users of merge-index are\n\n(git-checkout, which you pulled)\ngit-merge, which I do not really understand\ngit-merge-octopus, which you already discussed\ngit-merge-resolve, which is (hopefully) superseded by -recursive\ngit-merge-stupid, which is stupid\ngit-resolve, which is deprecated.\n\nWhat I am nervous about is git-merge. I do not even fully understand in \nwhich circumstances it calls merge-index at all. (Too tired to read that \nnow, anyway.)\n\nCiao,\nDscho\n"},{"id":"32485","messageId":"7vk5zdhv5r.fsf@assigned-by-dhcp.cox.net","threadId":"6440","inReplyTo":"Pine.LNX.4.63.0701240251230.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: MinGW port - initial work uploaded","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-24T05:05:04Z","receivedAt":"2007-01-24T05:05:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Seriously again, the users of merge-index are\n>\n> git-merge, which I do not really understand\n>\n> What I am nervous about is git-merge.\n\nI think you are referring to the \"carry forward local change\"\nlogic in 'next'.\n\nFirst of all, BAD DSCHO. You should be looking at 'master', not\n'next' during -rc period ;-).\n\nSeriously again, the codepath is taken when the merge is a fast\nforward to another commit (iow, our HEAD is an ancestor of the\nother branch, so we will end up updating the branch tip with the\ntip of the other branch). The use of merge-index there can be\nreplaced when we use merge-recursive instead of the 3-way\n\"read-tree -m\" the same way as how \"checkout -m\" implements the\nbranch switching with local changes.\n"},{"id":"32492","messageId":"fcaeb9bf0701232312t5889efa6w58bb3abfa2f53ebd@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701230736180.32200@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-01-24T07:12:28Z","receivedAt":"2007-01-24T07:12:28Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 1/23/07, Linus Torvalds wrote:\n> Actually, I have been seriously wondering if there is some setup under\n> Wine that I could run, just so that I'd see the Windows development\n> environment for git.\n>\n> Has anybody tried anything like that?\n\nAt least I can say that wine 0.9.27 can run git.exe, git-log.exe,\ngit-diff.exe. I have not tested others yet. git binaries were cross\ncompiled from Linux.\n-- \nDuy\n"},{"id":"32502","messageId":"Pine.LNX.4.63.0701241117040.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"fcaeb9bf0701232312t5889efa6w58bb3abfa2f53ebd@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-24T10:17:40Z","receivedAt":"2007-01-24T10:17:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 24 Jan 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On 1/23/07, Linus Torvalds wrote:\n> > Actually, I have been seriously wondering if there is some setup under\n> > Wine that I could run, just so that I'd see the Windows development\n> > environment for git.\n> > \n> > Has anybody tried anything like that?\n> \n> At least I can say that wine 0.9.27 can run git.exe, git-log.exe,\n> git-diff.exe. I have not tested others yet. git binaries were cross\n> compiled from Linux.\n\nIt would make more sense to run the MinGW/MSYS combo in wine, but I guess \nthat works, too.\n\nCiao,\nDscho\n"},{"id":"32503","messageId":"Pine.LNX.4.63.0701241121380.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6440","inReplyTo":"7vk5zdhv5r.fsf@assigned-by-dhcp.cox.net","subject":"Re: MinGW port - initial work uploaded","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-24T10:24:38Z","receivedAt":"2007-01-24T10:24:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Seriously again, the users of merge-index are\n> >\n> > git-merge, which I do not really understand\n> >\n> > What I am nervous about is git-merge.\n> \n> I think you are referring to the \"carry forward local change\"\n> logic in 'next'.\n> \n> First of all, BAD DSCHO. You should be looking at 'master', not\n> 'next' during -rc period ;-).\n\nGuilty on all accounts. Actually, I am not looking at 'next', but on 'my', \nwhich is my long-running sidebranch of next, which contains all the \nscripts I like to run manually, or in cron.\n\n> Seriously again, the codepath is taken when the merge is a fast\n> forward to another commit (iow, our HEAD is an ancestor of the\n> other branch, so we will end up updating the branch tip with the\n> tip of the other branch). The use of merge-index there can be\n> replaced when we use merge-recursive instead of the 3-way\n> \"read-tree -m\" the same way as how \"checkout -m\" implements the\n> branch switching with local changes.\n\nAha. The use of merge-recursive would be really easy, if we did not write \n$GIT_DIR/LOCAL_DIFF, but $GIT_DIR/TEMP_BRANCH or $GIT_DIR/LOCAL_TREE...\nJust teasing you...\n\nCiao,\nDscho\n"},{"id":"32534","messageId":"Pine.LNX.4.64.0701240834190.3606@woody.linux-foundation.org","threadId":"6440","inReplyTo":"fcaeb9bf0701232312t5889efa6w58bb3abfa2f53ebd@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-01-24T16:42:29Z","receivedAt":"2007-01-24T16:42:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 24 Jan 2007, Nguyen Thai Ngoc Duy wrote:\n> \n> At least I can say that wine 0.9.27 can run git.exe, git-log.exe,\n> git-diff.exe. I have not tested others yet. git binaries were cross\n> compiled from Linux.\n\nAhh, that's perfect. There are even RPM's for mingw around, since that \nseems to be what some Wine people use for testing.\n\nAnd I don't really want to _work_ inside some wine setup anyway, so being \nable to try to cross-compile from a sane development environment was \nexactly what I was hoping for.\n\nNo promises, but if I get any free time, I'll look at it a bit. \n\n\t\tLinus\n"},{"id":"32562","messageId":"46d6db660701241308l36d6c80ai4437996b67a76c32@mail.gmail.com","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701240834190.3606@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-01-24T21:08:42Z","receivedAt":"2007-01-24T21:08:42Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On 1/24/07, Linus Torvalds wrote:\n> Ahh, that's perfect. There are even RPM's for mingw around, since that\n> seems to be what some Wine people use for testing.\n>\n> And I don't really want to _work_ inside some wine setup anyway, so being\n> able to try to cross-compile from a sane development environment was\n> exactly what I was hoping for.\n>\n> No promises, but if I get any free time, I'll look at it a bit.\n>\n\nI'm using both Windows and Linux/Solaris. Since I've used\ngit on both unixes, I've been waiting for a native/mingw port.\n\nYou may have realized by now that the git community has\ncreated quite an addictive product: with a Windows port,\nthe door is open to many things, gui based or not...\n\nI'll start some c++ projects soon, and for them I'm stuck\non a Windows machine (corporatism...). I'm sure I'm not\nalone in this kind of situation...\n\nWith this recent port, I'm convinced I'll progress faster:\n\"foo\" branches is to my mind _the_ feature of git.\n\nThanks Linus and all for taking into account this suggestion!\n:)\n\n-- \nChristian\n"},{"id":"33925","messageId":"45CADCB7.5050107@zytor.com","threadId":"6440","inReplyTo":"46d6db660701221425i672e826coc9eef4bd8d22ae9d@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-02-08T08:17:59Z","receivedAt":"2007-02-08T08:17:59Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Christian MICHON wrote:\n> \n> the only recent alternative on Windows I came with was to run git\n> through coLinux and share directories using cofs.\n> \n\nActually, git has been working on Cygwin for years.\n\n\t-hpa\n"},{"id":"33939","messageId":"46d6db660702080606u58a6233l61d1f56faf7eac3@mail.gmail.com","threadId":"6440","inReplyTo":"45CADCB7.5050107@zytor.com","subject":"Re: MinGW port - initial work uploaded","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2007-02-08T14:06:30Z","receivedAt":"2007-02-08T14:06:30Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"I know that. I meant efficient alternative...\n\nOn 2/8/07, H. Peter Anvin wrote:\n> Christian MICHON wrote:\n> >\n> > the only recent alternative on Windows I came with was to run git\n> > through coLinux and share directories using cofs.\n> >\n>\n> Actually, git has been working on Cygwin for years.\n>\n> -hpa\n>\n\n\n-- \nChristian\n"},{"id":"33945","messageId":"45CB5B7F.6010707@zytor.com","threadId":"6440","inReplyTo":"Pine.LNX.4.64.0701240834190.3606@woody.linux-foundation.org","subject":"Re: MinGW port - initial work uploaded","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-02-08T17:18:55Z","receivedAt":"2007-02-08T17:18:55Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> Ahh, that's perfect. There are even RPM's for mingw around, since that \n> seems to be what some Wine people use for testing.\n> \n\nI've been using MinGW on Linux since the Transmeta days to build Win32 \nbinaries on Linux. It's *really* handy, and it's how I produce the \nWin32 version of syslinux.\n\n\t-hpa\n"},{"id":"33946","messageId":"45CB5C72.8030002@zytor.com","threadId":"6440","inReplyTo":"46d6db660702080606u58a6233l61d1f56faf7eac3@mail.gmail.com","subject":"Re: MinGW port - initial work uploaded","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2007-02-08T17:22:58Z","receivedAt":"2007-02-08T17:22:58Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Christian MICHON wrote:\n> I know that. I meant efficient alternative...\n\nHeh, no kidding.\n\nI'm delighted to see git ported more competently to lesser operating \nsystems, as it makes it *so* much easier to push it as the SCM of \nchoice. A lot of places go with SVN or even (gack!) CVS because it's \nfamiliar and cross-platform.\n\n\t-hpa\n"}]}