* MinGW port - initial work uploaded @ 2007-01-19 20:48 Johannes Sixt 2007-01-19 22:47 ` Christian MICHON ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: Johannes Sixt @ 2007-01-19 20:48 UTC (permalink / raw) To: git I've been working on a MinGW port for some time now. I've pushed out what I have so far to a git.git fork at repo.or.cz. For details on how and what to clone, please look at the top of http://repo.or.cz/w/git/mingw.git Thanks go to Johannes Schindelin for his initial work, which gave me quite a quick-start. Status ------ So far I've used the tools only to run the test suite. According to that, all tools that are needed to manipulate a repository locally work. clone, fetch, push does not work yet. Contributions ------------- If you want to contribute, please consider using the mob branch in this repository. That branch is publically writable. Since I assume that contributions will not be too frequent, it should be ok that you push your patches there (without pulling it first), then notify me, and I download them before someone else overwrites them. -- Hannes ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-19 20:48 MinGW port - initial work uploaded Johannes Sixt @ 2007-01-19 22:47 ` Christian MICHON 2007-01-19 23:53 ` Michael 2007-01-20 3:31 ` Shawn O. Pearce 2007-01-22 13:06 ` Christian MICHON 2 siblings, 1 reply; 53+ messages in thread From: Christian MICHON @ 2007-01-19 22:47 UTC (permalink / raw) To: git good to know some progress has been done in this direction. thanks in advance! quick question: how do I download it from windows, if I do not have git already installed ? (chicken and egg) On 1/19/07, Johannes Sixt <johannes.sixt@telecom.at> wrote: > I've been working on a MinGW port for some time now. I've pushed out what I > have so far to a git.git fork at repo.or.cz. For details on how and what to > clone, please look at the top of > > http://repo.or.cz/w/git/mingw.git > > Thanks go to Johannes Schindelin for his initial work, which gave me quite a > quick-start. > > Status > ------ > So far I've used the tools only to run the test suite. According to that, all > tools that are needed to manipulate a repository locally work. > > clone, fetch, push does not work yet. > > Contributions > ------------- > If you want to contribute, please consider using the mob branch in this > repository. That branch is publically writable. Since I assume that > contributions will not be too frequent, it should be ok that you push your > patches there (without pulling it first), then notify me, and I download them > before someone else overwrites them. > > -- Hannes > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Christian -- << There's a symlink from awk to gawk, if you're using gawk! If you're not using gawk, there's no symlink from gawk to awk! Use the standard names, _please_! >> - Rob Landley ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded @ 2007-01-19 23:53 ` Michael 0 siblings, 0 replies; 53+ messages in thread From: Michael @ 2007-01-19 23:53 UTC (permalink / raw) To: git; +Cc: Christian MICHON Christian MICHON: > quick question: how do I download it from windows, if I do not > have git already installed ? (chicken and egg) You can click on the "snapshot" link of the tree you're interested in. You'll download a tar.gz file containing that tree. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded @ 2007-01-19 23:53 ` Michael 0 siblings, 0 replies; 53+ messages in thread From: Michael @ 2007-01-19 23:53 UTC (permalink / raw) To: git; +Cc: Christian MICHON Christian MICHON: > quick question: how do I download it from windows, if I do not > have git already installed ? (chicken and egg) You can click on the "snapshot" link of the tree you're interested in. You'll download a tar.gz file containing that tree. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-19 20:48 MinGW port - initial work uploaded Johannes Sixt 2007-01-19 22:47 ` Christian MICHON @ 2007-01-20 3:31 ` Shawn O. Pearce 2007-01-20 9:24 ` Johannes Schindelin 2007-01-20 20:05 ` Johannes Sixt 2007-01-22 13:06 ` Christian MICHON 2 siblings, 2 replies; 53+ messages in thread From: Shawn O. Pearce @ 2007-01-20 3:31 UTC (permalink / raw) To: Johannes Sixt; +Cc: git Johannes Sixt <johannes.sixt@telecom.at> wrote: > I've been working on a MinGW port for some time now. I've pushed out what I > have so far to a git.git fork at repo.or.cz. For details on how and what to > clone, please look at the top of Can I make a few suggestions? Base your branch on Junio's 'master', not 'next'. This looks like its going to be a fairly long-running topic with a large number of commits. It will be easier to convince Junio to pull the topic in if its based solely on 'master' than if its based on 'next'. I made the mistake of building my git-fast-import topic on top of 'next' back in Aug. 2006. Its still going and has not yet merged into git.git. I finally went through the pain of rebasing it onto 'master' to make the merge easier for Junio post 1.5.0. Of course gfi is also less intrusive than this topic will be. The other is maybe try to avoid: #ifndef __MINGW32__ ... #endif instead try to use something like: git-compat-util: #ifdef __MINGW32__ #define is_mingw32 1 #else #define is_mingw32 0 #endif everywhere else: if (is_mingw32) { } This way the code within the block can be syntax checked, etc. on non-MinGW platforms but will be removed by the compiler on those non-MinGW systems. I just went through trying to do a #ifndef thing for Windows (1510fea7 in git.git, aka the NO_FAST_WORKING_DIRECTORY flag) and Junio rightly rejected my first attempt which used #ifndef, and instead used something like the above. -- Shawn. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-20 3:31 ` Shawn O. Pearce @ 2007-01-20 9:24 ` Johannes Schindelin 2007-01-20 20:05 ` Johannes Sixt 1 sibling, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-20 9:24 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Johannes Sixt, git Hi, On Fri, 19 Jan 2007, Shawn O. Pearce wrote: > Johannes Sixt <johannes.sixt@telecom.at> wrote: > > I've been working on a MinGW port for some time now. I've pushed out what I > > have so far to a git.git fork at repo.or.cz. For details on how and what to > > clone, please look at the top of > > Can I make a few suggestions? > > Base your branch on Junio's 'master', not 'next'. Blame me, not Johannes ;-) As for the #ifdef stuff, I'd rather have a look if it can't be done cleanly by conditional compiling, like we do for NO_MMAP, for example. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-20 3:31 ` Shawn O. Pearce 2007-01-20 9:24 ` Johannes Schindelin @ 2007-01-20 20:05 ` Johannes Sixt 2007-01-20 20:21 ` Christian MICHON 1 sibling, 1 reply; 53+ messages in thread From: Johannes Sixt @ 2007-01-20 20:05 UTC (permalink / raw) To: git; +Cc: Shawn O. Pearce On Saturday 20 January 2007 04:31, Shawn O. Pearce wrote: > Base your branch on Junio's 'master', not 'next'. This looks like > its going to be a fairly long-running topic with a large number > of commits. It will be easier to convince Junio to pull the topic > in if its based solely on 'master' than if its based on 'next'. I consider this branch only the sandbox for the MinGW port. Although I've tried to make the branch as clean as possible, it is still a bit messy, and not everything is #ifdef'd that should be. For this reason I will not try to convince Junio to pull this topic directly. The goal is rather to work towards a complete port, then later factor out patches that bring 'master' or 'next' closer to this branch so that finally only at most a small patch series is needed that contains this topic. > git-compat-util: > #ifdef __MINGW32__ > #define is_mingw32 1 > #else > #define is_mingw32 0 > #endif > > everywhere else: > if (is_mingw32) { > } I like this idea. -- Hannes ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-20 20:05 ` Johannes Sixt @ 2007-01-20 20:21 ` Christian MICHON 0 siblings, 0 replies; 53+ messages in thread From: Christian MICHON @ 2007-01-20 20:21 UTC (permalink / raw) To: Johannes Sixt; +Cc: git, Shawn O. Pearce Hi Johannes(s) and list, I managed a compilation, and some commands work, some don't. Up to the first git commit, all is find. I need to invoke the commit through the git-commit actually, "git commit" says it's not a valid git command. so bash is a true need in this case, might not even work in pure win32 cmd.exe approach. Furthermore, once the commit is in, "git log" and git-log do not work. Same for git-whatchanged and git-diff. I need to try with the specific versions you mentionned, but it's a pretty good start :) -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-19 20:48 MinGW port - initial work uploaded Johannes Sixt 2007-01-19 22:47 ` Christian MICHON 2007-01-20 3:31 ` Shawn O. Pearce @ 2007-01-22 13:06 ` Christian MICHON 2007-01-22 16:39 ` Linus Torvalds 2007-01-22 20:27 ` Johannes Sixt 2 siblings, 2 replies; 53+ messages in thread From: Christian MICHON @ 2007-01-22 13:06 UTC (permalink / raw) To: Johannes Sixt; +Cc: git ok, I upgraded some msys and mingw components, and took today's snapshot of mingw.git. I can now do many local tasks :) One problem I haven't found a solution for though: the date of commit is wrong, always back to epoch (1970???). See attached: $ git init-db Initialized empty Git repository in .git/ $ git add . $ git commit -a -m ok Created initial commit d52832ca5120626bfcc35360d7fd3914ccb6d11f 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 a $ git log commit d52832ca5120626bfcc35360d7fd3914ccb6d11f Author: Christian MICHON <christian.michon@gmail.com> Date: Thu Jan 1 00:00:00 1970 +0000 ok -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 13:06 ` Christian MICHON @ 2007-01-22 16:39 ` Linus Torvalds 2007-01-22 22:25 ` Christian MICHON 2007-01-23 11:25 ` Johannes Schindelin 2007-01-22 20:27 ` Johannes Sixt 1 sibling, 2 replies; 53+ messages in thread From: Linus Torvalds @ 2007-01-22 16:39 UTC (permalink / raw) To: Christian MICHON; +Cc: Johannes Sixt, git On Mon, 22 Jan 2007, Christian MICHON wrote: > > One problem I haven't found a solution for though: the date > of commit is wrong, always back to epoch (1970???). Without knowing MinGW, I'd assume it's one of two issues: - parse_date will probably do this when the date is empty. The way git works, is it takes the date from the GIT_COMMITTER|AUTHOR_DATE environment variables, and it depends on getenv() returning NULL if that environment variable isn't set. Maybe getenv() under MinGW always returns a real string, and it's just empty? If so, get_ident() should probably be changed from doing if (date_str) parse_date(...) to if (date_str && *date_str) parse_date(...) or something like that. - datestamp() uses "time()" to get the number of seconds since the epoch. HOWEVER, it does it by actually doing time_t now; time(&now); which is proper, but maybe a bit unusual. Try changing that to now = time(NULL); and see if that changes behaviour (it's datestamp() in date.c). Alternatively, if "time()" just doesn't work in MinGW, just use gettimeofday() instead, something like time_t now; int offset; struct timeval tv; struct timezone tz; /* Just in case not everybody necessarily fills in TZ correctly.. */ memset(&tz, 0, sizeof(tz)); gettimeofday(&tv, &tz); now = tv.tv_sec; offset = tz.tz_minuteswest; instead of the current mess with localtime() and company. [ NOTE NOTE NOTE! The above gettimeofday() thing has NOT been tested. Using the "tz" value to gettimeofday() is generally considered a bug, and shouldn't really be done. It's very traditional (read: old-fashioned) and very incorrect (it will ignore the TZ variable, and ask the kernel, which generally has no clue at all about timezones). But maybe it works on MinGW, so it might be worth testing. ] Anyway. I have no idea of Windows or MinGW, or what you did to make it all compile, so.. Linus ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 16:39 ` Linus Torvalds @ 2007-01-22 22:25 ` Christian MICHON 2007-02-08 8:17 ` H. Peter Anvin 2007-01-23 11:25 ` Johannes Schindelin 1 sibling, 1 reply; 53+ messages in thread From: Christian MICHON @ 2007-01-22 22:25 UTC (permalink / raw) To: Linus Torvalds; +Cc: Johannes Sixt, git On 1/22/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > Anyway. I have no idea of Windows or MinGW, or what you did to make it all > compile, so.. > > Linus > thanks Linus for your suggestions. the kudos for making it work go to Johannes Sixt and Johannes Schindelin! the only recent alternative on Windows I came with was to run git through coLinux and share directories using cofs. now I can use the "content tracker from Hell" on Windows. :) -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 22:25 ` Christian MICHON @ 2007-02-08 8:17 ` H. Peter Anvin 2007-02-08 14:06 ` Christian MICHON 0 siblings, 1 reply; 53+ messages in thread From: H. Peter Anvin @ 2007-02-08 8:17 UTC (permalink / raw) To: Christian MICHON; +Cc: Linus Torvalds, Johannes Sixt, git Christian MICHON wrote: > > the only recent alternative on Windows I came with was to run git > through coLinux and share directories using cofs. > Actually, git has been working on Cygwin for years. -hpa ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-02-08 8:17 ` H. Peter Anvin @ 2007-02-08 14:06 ` Christian MICHON 2007-02-08 17:22 ` H. Peter Anvin 0 siblings, 1 reply; 53+ messages in thread From: Christian MICHON @ 2007-02-08 14:06 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Linus Torvalds, Johannes Sixt, git I know that. I meant efficient alternative... On 2/8/07, H. Peter Anvin <hpa@zytor.com> wrote: > Christian MICHON wrote: > > > > the only recent alternative on Windows I came with was to run git > > through coLinux and share directories using cofs. > > > > Actually, git has been working on Cygwin for years. > > -hpa > -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-02-08 14:06 ` Christian MICHON @ 2007-02-08 17:22 ` H. Peter Anvin 0 siblings, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2007-02-08 17:22 UTC (permalink / raw) To: Christian MICHON; +Cc: Linus Torvalds, Johannes Sixt, git Christian MICHON wrote: > I know that. I meant efficient alternative... Heh, no kidding. I'm delighted to see git ported more competently to lesser operating systems, as it makes it *so* much easier to push it as the SCM of choice. A lot of places go with SVN or even (gack!) CVS because it's familiar and cross-platform. -hpa ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 16:39 ` Linus Torvalds 2007-01-22 22:25 ` Christian MICHON @ 2007-01-23 11:25 ` Johannes Schindelin 2007-01-23 13:08 ` Christian MICHON 2007-01-23 15:37 ` Linus Torvalds 1 sibling, 2 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 11:25 UTC (permalink / raw) To: Linus Torvalds; +Cc: Christian MICHON, Johannes Sixt, git Hi, On Mon, 22 Jan 2007, Linus Torvalds wrote: > Maybe getenv() under MinGW always returns a real string, and it's just > empty? No. It is not Oracle: it _does_ return NULL if it is not set, and an empty string iff it is set to an empty string. > - datestamp() uses "time()" to get the number of seconds since the epoch. > HOWEVER, it does it by actually doing > > time_t now; > > time(&now); > > which is proper, but maybe a bit unusual. MinGW does that quite fine (actually, it just calls the MS C Runtime library; maybe they still had a clue bat back when they wrote that?). > Alternatively, if "time()" just doesn't work in MinGW, just use > gettimeofday() instead, [...] Funnily enough, MinGW does not have gettimeofday(). Actually, for purposes of getting git to compile, I had to int gettimeofday(struct timeval *tv, void *tz) { return -1; } ;-) > Anyway. I have no idea of Windows or MinGW, or what you did to make it > all compile, so.. Lucky you! Fortunately, I don't have any Windows at home (but I still have windows, thank God!). So I cannot even be tempted to work on this thing in my free time. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 11:25 ` Johannes Schindelin @ 2007-01-23 13:08 ` Christian MICHON 2007-01-23 14:17 ` Johannes Schindelin 2007-01-23 15:37 ` Linus Torvalds 1 sibling, 1 reply; 53+ messages in thread From: Christian MICHON @ 2007-01-23 13:08 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git > Lucky you! Fortunately, I don't have any Windows at home (but I still have > windows, thank God!). So I cannot even be tempted to work on this thing in > my free time. well, you could cross compile it and run it through Wine ? :) -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 13:08 ` Christian MICHON @ 2007-01-23 14:17 ` Johannes Schindelin 0 siblings, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 14:17 UTC (permalink / raw) To: Christian MICHON; +Cc: git Hi, On Tue, 23 Jan 2007, Christian MICHON wrote: > > Lucky you! Fortunately, I don't have any Windows at home (but I still have > > windows, thank God!). So I cannot even be tempted to work on this thing in > > my free time. > > well, you could cross compile it and run it through Wine ? > :) You could. But it would probably only uncover a few bugs in obscure use cases. But hey, it's Open Source, so go wild. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 11:25 ` Johannes Schindelin 2007-01-23 13:08 ` Christian MICHON @ 2007-01-23 15:37 ` Linus Torvalds 2007-01-23 15:45 ` Alex Riesen ` (2 more replies) 1 sibling, 3 replies; 53+ messages in thread From: Linus Torvalds @ 2007-01-23 15:37 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Christian MICHON, Johannes Sixt, git On Tue, 23 Jan 2007, Johannes Schindelin wrote: > > Lucky you! Fortunately, I don't have any Windows at home (but I still have > windows, thank God!). So I cannot even be tempted to work on this thing in > my free time. Actually, I have been seriously wondering if there is some setup under Wine that I could run, just so that I'd see the Windows development environment for git. Has anybody tried anything like that? Linus ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:37 ` Linus Torvalds @ 2007-01-23 15:45 ` Alex Riesen 2007-01-23 15:52 ` Johannes Schindelin 2007-01-23 15:53 ` Shawn O. Pearce 2007-01-23 15:49 ` Johannes Schindelin 2007-01-24 7:12 ` Nguyen Thai Ngoc Duy 2 siblings, 2 replies; 53+ messages in thread From: Alex Riesen @ 2007-01-23 15:45 UTC (permalink / raw) To: Linus Torvalds; +Cc: Johannes Schindelin, Christian MICHON, Johannes Sixt, git On 1/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > > Lucky you! Fortunately, I don't have any Windows at home (but I still have > > windows, thank God!). So I cannot even be tempted to work on this thing in > > my free time. > > Actually, I have been seriously wondering if there is some setup under > Wine that I could run, just so that I'd see the Windows development > environment for git. You have to stea... purchase large parts of windows to get enough of it to be able to develop on it. I tried to run installers under Wine: nothing worked until the not-to-be-mentioned parts (ok, the whole "Windows" and "Program Files" directories from an existing installation) were provided. I didn't tried cygwin, though. > Has anybody tried anything like that? Why would anyone want to try anything like that? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:45 ` Alex Riesen @ 2007-01-23 15:52 ` Johannes Schindelin 2007-01-23 15:56 ` Alex Riesen 2007-01-23 15:53 ` Shawn O. Pearce 1 sibling, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 15:52 UTC (permalink / raw) To: Alex Riesen; +Cc: Linus Torvalds, git Hi, On Tue, 23 Jan 2007, Alex Riesen wrote: > I tried to run installers under Wine: nothing worked until the > not-to-be-mentioned parts (ok, the whole "Windows" and "Program Files" > directories from an existing installation) were provided. I didn't tried > cygwin, though. Since when did you not check? According to Wine's git commit messages (yeah!) they worked really hard to get installers going. > > Has anybody tried anything like that? > > Why would anyone want to try anything like that? Curiosity. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:52 ` Johannes Schindelin @ 2007-01-23 15:56 ` Alex Riesen 2007-01-23 16:00 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Alex Riesen @ 2007-01-23 15:56 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Linus Torvalds, git On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > I tried to run installers under Wine: nothing worked until the > > not-to-be-mentioned parts (ok, the whole "Windows" and "Program Files" > > directories from an existing installation) were provided. I didn't tried > > cygwin, though. > > Since when did you not check? According to Wine's git commit messages > (yeah!) they worked really hard to get installers going. > Since quite a while (some months), I must admit. Have you tried it? ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:56 ` Alex Riesen @ 2007-01-23 16:00 ` Johannes Schindelin 0 siblings, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 16:00 UTC (permalink / raw) To: Alex Riesen; +Cc: Linus Torvalds, git Hi, On Tue, 23 Jan 2007, Alex Riesen wrote: > On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > > I tried to run installers under Wine: nothing worked until the > > > not-to-be-mentioned parts (ok, the whole "Windows" and "Program Files" > > > directories from an existing installation) were provided. I didn't tried > > > cygwin, though. > > > > Since when did you not check? According to Wine's git commit messages > > (yeah!) they worked really hard to get installers going. > > > > Since quite a while (some months), I must admit. Have you tried it? Nope. Didn't have to. A friend did. Said it worked amazingly well. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:45 ` Alex Riesen 2007-01-23 15:52 ` Johannes Schindelin @ 2007-01-23 15:53 ` Shawn O. Pearce 1 sibling, 0 replies; 53+ messages in thread From: Shawn O. Pearce @ 2007-01-23 15:53 UTC (permalink / raw) To: Linus Torvalds; +Cc: Johannes Schindelin, Christian MICHON, Johannes Sixt, git On 1/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: >Actually, I have been seriously wondering if there is some setup under >Wine that I could run, just so that I'd see the Windows development >environment for git. Modify Linux VFS layer to: - make open take about 10x longer - make lstat take about 20x longer and finally remove any useful programs, except Git. Use the worst xterm available. You are left with a close approximation. -- Shawn. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:37 ` Linus Torvalds 2007-01-23 15:45 ` Alex Riesen @ 2007-01-23 15:49 ` Johannes Schindelin 2007-01-24 7:12 ` Nguyen Thai Ngoc Duy 2 siblings, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 15:49 UTC (permalink / raw) To: Linus Torvalds; +Cc: git Hi, On Tue, 23 Jan 2007, Linus Torvalds wrote: > On Tue, 23 Jan 2007, Johannes Schindelin wrote: > > > > Lucky you! Fortunately, I don't have any Windows at home (but I still > > have windows, thank God!). So I cannot even be tempted to work on this > > thing in my free time. > > Actually, I have been seriously wondering if there is some setup under > Wine that I could run, just so that I'd see the Windows development > environment for git. IMHO the best way to go ahead is to download ReactOS, and run it inside QEmu. That way you'll get a better idea of the speed and integration. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:37 ` Linus Torvalds 2007-01-23 15:45 ` Alex Riesen 2007-01-23 15:49 ` Johannes Schindelin @ 2007-01-24 7:12 ` Nguyen Thai Ngoc Duy 2007-01-24 10:17 ` Johannes Schindelin 2007-01-24 16:42 ` Linus Torvalds 2 siblings, 2 replies; 53+ messages in thread From: Nguyen Thai Ngoc Duy @ 2007-01-24 7:12 UTC (permalink / raw) To: Linus Torvalds; +Cc: Johannes Schindelin, Christian MICHON, Johannes Sixt, git On 1/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > Actually, I have been seriously wondering if there is some setup under > Wine that I could run, just so that I'd see the Windows development > environment for git. > > Has anybody tried anything like that? At least I can say that wine 0.9.27 can run git.exe, git-log.exe, git-diff.exe. I have not tested others yet. git binaries were cross compiled from Linux. -- Duy ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-24 7:12 ` Nguyen Thai Ngoc Duy @ 2007-01-24 10:17 ` Johannes Schindelin 2007-01-24 16:42 ` Linus Torvalds 1 sibling, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-24 10:17 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Linus Torvalds, git Hi, On Wed, 24 Jan 2007, Nguyen Thai Ngoc Duy wrote: > On 1/23/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Actually, I have been seriously wondering if there is some setup under > > Wine that I could run, just so that I'd see the Windows development > > environment for git. > > > > Has anybody tried anything like that? > > At least I can say that wine 0.9.27 can run git.exe, git-log.exe, > git-diff.exe. I have not tested others yet. git binaries were cross > compiled from Linux. It would make more sense to run the MinGW/MSYS combo in wine, but I guess that works, too. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-24 7:12 ` Nguyen Thai Ngoc Duy 2007-01-24 10:17 ` Johannes Schindelin @ 2007-01-24 16:42 ` Linus Torvalds 2007-01-24 21:08 ` Christian MICHON 2007-02-08 17:18 ` H. Peter Anvin 1 sibling, 2 replies; 53+ messages in thread From: Linus Torvalds @ 2007-01-24 16:42 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy Cc: Johannes Schindelin, Christian MICHON, Johannes Sixt, git On Wed, 24 Jan 2007, Nguyen Thai Ngoc Duy wrote: > > At least I can say that wine 0.9.27 can run git.exe, git-log.exe, > git-diff.exe. I have not tested others yet. git binaries were cross > compiled from Linux. Ahh, that's perfect. There are even RPM's for mingw around, since that seems to be what some Wine people use for testing. And I don't really want to _work_ inside some wine setup anyway, so being able to try to cross-compile from a sane development environment was exactly what I was hoping for. No promises, but if I get any free time, I'll look at it a bit. Linus ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-24 16:42 ` Linus Torvalds @ 2007-01-24 21:08 ` Christian MICHON 2007-02-08 17:18 ` H. Peter Anvin 1 sibling, 0 replies; 53+ messages in thread From: Christian MICHON @ 2007-01-24 21:08 UTC (permalink / raw) To: Linus Torvalds, Git List On 1/24/07, Linus Torvalds <torvalds@linux-foundation.org> wrote: > Ahh, that's perfect. There are even RPM's for mingw around, since that > seems to be what some Wine people use for testing. > > And I don't really want to _work_ inside some wine setup anyway, so being > able to try to cross-compile from a sane development environment was > exactly what I was hoping for. > > No promises, but if I get any free time, I'll look at it a bit. > I'm using both Windows and Linux/Solaris. Since I've used git on both unixes, I've been waiting for a native/mingw port. You may have realized by now that the git community has created quite an addictive product: with a Windows port, the door is open to many things, gui based or not... I'll start some c++ projects soon, and for them I'm stuck on a Windows machine (corporatism...). I'm sure I'm not alone in this kind of situation... With this recent port, I'm convinced I'll progress faster: "foo" branches is to my mind _the_ feature of git. Thanks Linus and all for taking into account this suggestion! :) -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-24 16:42 ` Linus Torvalds 2007-01-24 21:08 ` Christian MICHON @ 2007-02-08 17:18 ` H. Peter Anvin 1 sibling, 0 replies; 53+ messages in thread From: H. Peter Anvin @ 2007-02-08 17:18 UTC (permalink / raw) To: Linus Torvalds Cc: Nguyen Thai Ngoc Duy, Johannes Schindelin, Christian MICHON, Johannes Sixt, git Linus Torvalds wrote: > > Ahh, that's perfect. There are even RPM's for mingw around, since that > seems to be what some Wine people use for testing. > I've been using MinGW on Linux since the Transmeta days to build Win32 binaries on Linux. It's *really* handy, and it's how I produce the Win32 version of syslinux. -hpa ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 13:06 ` Christian MICHON 2007-01-22 16:39 ` Linus Torvalds @ 2007-01-22 20:27 ` Johannes Sixt 2007-01-22 22:20 ` Christian MICHON ` (2 more replies) 1 sibling, 3 replies; 53+ messages in thread From: Johannes Sixt @ 2007-01-22 20:27 UTC (permalink / raw) To: git; +Cc: Christian MICHON On Monday 22 January 2007 14:06, Christian MICHON wrote: > One problem I haven't found a solution for though: the date > of commit is wrong, always back to epoch (1970???). I've pushed out a fix for this. Also, t/t5500-fetch-pack.sh passes now all tests. OTOH, git log, git diff, etc, which run the pager by default, are broken. It seems that the pipe is not correctly flushed by the writer, which the MinGW port closes in an atexit() routine, so that the last part of the piped data is missing. I have no clue how to fix this except by disabling the pager. -- Hannes ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 20:27 ` Johannes Sixt @ 2007-01-22 22:20 ` Christian MICHON 2007-01-23 8:31 ` Christian MICHON 2007-01-23 11:32 ` Johannes Schindelin 2 siblings, 0 replies; 53+ messages in thread From: Christian MICHON @ 2007-01-22 22:20 UTC (permalink / raw) To: Johannes Sixt; +Cc: git On 1/22/07, Johannes Sixt <johannes.sixt@telecom.at> wrote: > On Monday 22 January 2007 14:06, Christian MICHON wrote: > > One problem I haven't found a solution for though: the date > > of commit is wrong, always back to epoch (1970???). > > I've pushed out a fix for this. > it seems to be in the snapshot I just evaluated: mingw.git-d576539c9255d22425efcc55f7e9720fbb8a42d1 indeed, it's fixed! I'll run more regressions tomorrow (like the one I posted, using 117 versions of linux-2.6 kernels). -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 20:27 ` Johannes Sixt 2007-01-22 22:20 ` Christian MICHON @ 2007-01-23 8:31 ` Christian MICHON 2007-01-23 11:32 ` Johannes Schindelin 2 siblings, 0 replies; 53+ messages in thread From: Christian MICHON @ 2007-01-23 8:31 UTC (permalink / raw) To: Johannes Sixt; +Cc: git On 1/22/07, Johannes Sixt <johannes.sixt@telecom.at> wrote: > Also, t/t5500-fetch-pack.sh passes now all tests. > > OTOH, git log, git diff, etc, which run the pager by default, are broken. It > seems that the pipe is not correctly flushed by the writer, which the MinGW > port closes in an atexit() routine, so that the last part of the piped data > is missing. I have no clue how to fix this except by disabling the pager. > another good news: gitk is working too on windoze :) good work! thanks! -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-22 20:27 ` Johannes Sixt 2007-01-22 22:20 ` Christian MICHON 2007-01-23 8:31 ` Christian MICHON @ 2007-01-23 11:32 ` Johannes Schindelin 2007-01-23 12:06 ` Jakub Narebski ` (3 more replies) 2 siblings, 4 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 11:32 UTC (permalink / raw) To: Johannes Sixt; +Cc: git Hi, On Mon, 22 Jan 2007, Johannes Sixt wrote: > OTOH, git log, git diff, etc, which run the pager by default, are > broken. It seems that the pipe is not correctly flushed by the writer, > which the MinGW port closes in an atexit() routine, so that the last > part of the piped data is missing. I have no clue how to fix this except > by disabling the pager. Maybe we have to go the other way round, just as POSIX git does: instead of spawning the pager, we should _beginthread() the actual work, and execl() the pager. On the third hand, I fully expect git on Windows to be used only by GUI wieners who cannot handle the command line, let alone a pager! ("WTF! How do I go back to that dollar thingie? You know, where I type git-blabla?") Since Tcl/Tk is available for MinGW, git-gui seems to be a way to go there. Or to continue on the TortoiseCVS lookalike... Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 11:32 ` Johannes Schindelin @ 2007-01-23 12:06 ` Jakub Narebski 2007-01-23 15:29 ` Shawn O. Pearce 2007-01-23 13:12 ` Christian MICHON ` (2 subsequent siblings) 3 siblings, 1 reply; 53+ messages in thread From: Jakub Narebski @ 2007-01-23 12:06 UTC (permalink / raw) To: git Johannes Schindelin wrote: > Since Tcl/Tk is available for MinGW, git-gui seems to be a way to go > there. Since Qt4 is to work in Windows natively, perhaps QGit is a way to go... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 12:06 ` Jakub Narebski @ 2007-01-23 15:29 ` Shawn O. Pearce 0 siblings, 0 replies; 53+ messages in thread From: Shawn O. Pearce @ 2007-01-23 15:29 UTC (permalink / raw) To: Jakub Narebski; +Cc: git Jakub Narebski <jnareb@gmail.com> wrote: > Johannes Schindelin wrote: > > > Since Tcl/Tk is available for MinGW, git-gui seems to be a way to go > > there. > > Since Qt4 is to work in Windows natively, perhaps QGit is a way to go... Choice is good. ;-) git-gui has slightly different goals/focus than QGit. I think its a better commit creation tool. -- Shawn. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 11:32 ` Johannes Schindelin 2007-01-23 12:06 ` Jakub Narebski @ 2007-01-23 13:12 ` Christian MICHON 2007-01-23 14:18 ` Johannes Schindelin 2007-01-23 13:22 ` Andy Parkins 2007-01-23 13:36 ` Nguyen Thai Ngoc Duy 3 siblings, 1 reply; 53+ messages in thread From: Christian MICHON @ 2007-01-23 13:12 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > Maybe we have to go the other way round, just as POSIX git does: instead > of spawning the pager, we should _beginthread() the actual work, and > execl() the pager. actually, one other issue is the spawning of vim when doing commits. I usually end up in using -m "my commit message" because of these 2 errors (basically terminal not recognized, I tried many different options to no avail) $ git commit -a Vim: Warning: Output is not to a terminal Vim: Warning: Input is not from a terminal > On the third hand, I fully expect git on Windows to be used only by GUI > wieners who cannot handle the command line, let alone a pager! ("WTF! How > do I go back to that dollar thingie? You know, where I type git-blabla?") maybe I'm stuck with windows at work, but I still use vim inside mingw. it would be nice to fix the pager issue... > > Since Tcl/Tk is available for MinGW, git-gui seems to be a way to go > there. I did not know about this... let me try... yes! not bad... it's working too, so your assumption was correct. thanks for the suggestion. -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 13:12 ` Christian MICHON @ 2007-01-23 14:18 ` Johannes Schindelin 2007-01-23 18:55 ` Christian MICHON 0 siblings, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 14:18 UTC (permalink / raw) To: Christian MICHON; +Cc: git Hi, On Tue, 23 Jan 2007, Christian MICHON wrote: > On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > Maybe we have to go the other way round, just as POSIX git does: instead > > of spawning the pager, we should _beginthread() the actual work, and > > execl() the pager. > > actually, one other issue is the spawning of vim when doing commits. > I usually end up in using -m "my commit message" because of these > 2 errors (basically terminal not recognized, I tried many different > options to no avail) > > $ git commit -a > Vim: Warning: Output is not to a terminal > Vim: Warning: Input is not from a terminal > > > On the third hand, I fully expect git on Windows to be used only by GUI > > wieners who cannot handle the command line, let alone a pager! ("WTF! How > > do I go back to that dollar thingie? You know, where I type git-blabla?") > > maybe I'm stuck with windows at work, but I still use vim inside mingw. I don't: $ vi m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000, m.State 0x10000 C:\msys1\bin\vim.exe: *** Couldn't reserve space for cygwin's heap (0x715B0000 <0xB10000>) in child, Win32 error 487 > it would be nice to fix the pager issue... Go ahead! Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 14:18 ` Johannes Schindelin @ 2007-01-23 18:55 ` Christian MICHON 2007-01-23 19:18 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Christian MICHON @ 2007-01-23 18:55 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > maybe I'm stuck with windows at work, but I still use vim inside mingw. > > I don't: > > $ vi > m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000, > m.State 0x10000 > C:\msys1\bin\vim.exe: *** Couldn't reserve space for cygwin's heap > (0x715B0000 <0xB10000>) in child, Win32 error 487 interesting. which version of msys are you using ? I'm using this snapshot successfully: msysCORE-1.0.11-2007.01.19-1 > > it would be nice to fix the pager issue... > > Go ahead! well: git log | less :) seriously enough, I do not know where to start. I guess we're close to mingw limitations of fork() ?? -- Christian ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 18:55 ` Christian MICHON @ 2007-01-23 19:18 ` Johannes Schindelin 2007-01-23 19:28 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 19:18 UTC (permalink / raw) To: Christian MICHON; +Cc: git Hi, On Tue, 23 Jan 2007, Christian MICHON wrote: > On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > maybe I'm stuck with windows at work, but I still use vim inside mingw. > > > > I don't: > > > > $ vi > > m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000, > > m.State 0x10000 > > C:\msys1\bin\vim.exe: *** Couldn't reserve space for cygwin's heap > > (0x715B0000 <0xB10000>) in child, Win32 error 487 > > interesting. which version of msys are you using ? > I'm using this snapshot successfully: > msysCORE-1.0.11-2007.01.19-1 I cannot find that file. > > > it would be nice to fix the pager issue... > > > > Go ahead! > > well: > > git log | less > > :) > > seriously enough, I do not know where to start. I guess we're > close to mingw limitations of fork() ?? The problem seems to be more the console attachment. I think that the pager cannot run properly when fork()ed. Rather, the main process has to continue with the execl(pager), while the _child_ should continue to run. See upload-pack.c for an example how to use _beginthread() to achieve something along those lines. Hth, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 19:18 ` Johannes Schindelin @ 2007-01-23 19:28 ` Johannes Schindelin 0 siblings, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 19:28 UTC (permalink / raw) To: Christian MICHON; +Cc: git Hi, On Tue, 23 Jan 2007, Johannes Schindelin wrote: > On Tue, 23 Jan 2007, Christian MICHON wrote: > > > On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > > > maybe I'm stuck with windows at work, but I still use vim inside mingw. > > > > > > I don't: > > > > > > $ vi > > > m.AllocationBase 0x0, m.BaseAddress 0x715B0000, m.RegionSize 0x4D0000, > > > m.State 0x10000 > > > C:\msys1\bin\vim.exe: *** Couldn't reserve space for cygwin's heap > > > (0x715B0000 <0xB10000>) in child, Win32 error 487 > > > > interesting. which version of msys are you using ? > > I'm using this snapshot successfully: > > msysCORE-1.0.11-2007.01.19-1 > > I cannot find that file. I finally found it. I did not look in "Snapshots", but in "Current" and "Candidate". And I found the bug: I always extracted with MSYS' own tar in MSYS' own rxvt. Windows is very challenged from time to time, for example when replacing files which are in use, and this led to my bash never being replaced. Now, Windows executables are not so easily relocated, it seems, and the old bash kept on nicely clashing with the new vim. It sounds horrible, that one program can take away a memory range from another program, just by being not relocatable. And it is. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 11:32 ` Johannes Schindelin 2007-01-23 12:06 ` Jakub Narebski 2007-01-23 13:12 ` Christian MICHON @ 2007-01-23 13:22 ` Andy Parkins 2007-01-23 14:21 ` Johannes Schindelin 2007-01-23 13:36 ` Nguyen Thai Ngoc Duy 3 siblings, 1 reply; 53+ messages in thread From: Andy Parkins @ 2007-01-23 13:22 UTC (permalink / raw) To: git; +Cc: Johannes Schindelin, Johannes Sixt On Tuesday 2007 January 23 11:32, Johannes Schindelin wrote: > Maybe we have to go the other way round, just as POSIX git does: instead > of spawning the pager, we should _beginthread() the actual work, and > execl() the pager. What about just forgetting paged output under Windows? It's been a while, but the only decent one that I ever found was LIST.COM, and that's probably vanished now. I haven't used Windows in a while, are pipes still as awful as they were? That is to say they cheated and redirected output to a temporary file then redirected that file to the input of the second process. The upshot of which was you had to have the whole pipe complete before you could view the first page of output. I can well imagine that in Windows I would find the paged output more painful than useful. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 13:22 ` Andy Parkins @ 2007-01-23 14:21 ` Johannes Schindelin 2007-01-23 15:06 ` Andy Parkins 0 siblings, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 14:21 UTC (permalink / raw) To: Andy Parkins; +Cc: git, Johannes Sixt Hi, On Tue, 23 Jan 2007, Andy Parkins wrote: > On Tuesday 2007 January 23 11:32, Johannes Schindelin wrote: > > > Maybe we have to go the other way round, just as POSIX git does: instead > > of spawning the pager, we should _beginthread() the actual work, and > > execl() the pager. > > What about just forgetting paged output under Windows? It's been a > while, but the only decent one that I ever found was LIST.COM, and > that's probably vanished now. Uhm. You do understand that we use MinGW to port to, not _plain_ Windows? So we do have a "less". > I haven't used Windows in a while, are pipes still as awful as they > were? That is to say they cheated and redirected output to a temporary > file then redirected that file to the input of the second process. That was not Windows. That was DOS. > I can well imagine that in Windows I would find the paged output more > painful than useful. Not if you are used to it. If you have to open a window to write into, with scrollbars and all, you either have to wait for the revision walker to finish, or you update it constantly, which is a huge performance hit on Windows (and you have to jump through hoops to avoid flicker). With less, on the other hand, you just exit the pager, or let it search through stdin. It is so much more convenient. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 14:21 ` Johannes Schindelin @ 2007-01-23 15:06 ` Andy Parkins 2007-01-23 15:20 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Andy Parkins @ 2007-01-23 15:06 UTC (permalink / raw) To: git; +Cc: Johannes Schindelin On Tuesday 2007 January 23 14:21, Johannes Schindelin wrote: > Uhm. You do understand that we use MinGW to port to, not _plain_ Windows? > So we do have a "less". Nope; I didn't. Oh dear. I've obviously misunderstood. I thought MinGW was for compiling to native Windows? Do you use MinGW to compile to cygwin as well? > That was not Windows. That was DOS. I'm sure pipes were still awful in Win98. I accept though, that it is possible Windows has changed in the last 9 years :-) > With less, on the other hand, you just exit the pager, or let it search > through stdin. It is so much more convenient. That sounds better than I remember. You'll have talked me into migrating to Windows soon :-) Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:06 ` Andy Parkins @ 2007-01-23 15:20 ` Johannes Schindelin 2007-01-23 16:24 ` Andy Parkins 0 siblings, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 15:20 UTC (permalink / raw) To: Andy Parkins; +Cc: git Hi, On Tue, 23 Jan 2007, Andy Parkins wrote: > On Tuesday 2007 January 23 14:21, Johannes Schindelin wrote: > > > Uhm. You do understand that we use MinGW to port to, not _plain_ > > Windows? So we do have a "less". > > Nope; I didn't. Oh dear. I've obviously misunderstood. I thought > MinGW was for compiling to native Windows? Do you use MinGW to compile > to cygwin as well? MinGW and cygwin differ in one very important point: cygwin needs an extra dll, MinGW does not. However, the development environment is still console-based, with a bash so you can run configure and simple bash scripts. It is definitely more catering to Unix types than Windows types. So yes, there is a bash, and there is a less, and there is perl. > > That was not Windows. That was DOS. > > I'm sure pipes were still awful in Win98. I accept though, that it is > possible Windows has changed in the last 9 years :-) Win98 was based on DOS. Windows XP is based on VMS. <tongue-in-cheek> Yes, I know. They left everything behind, and started Windows NT anew. Yeah, right. </tongue-in-cheek> > > With less, on the other hand, you just exit the pager, or let it > > search through stdin. It is so much more convenient. > > That sounds better than I remember. You'll have talked me into > migrating to Windows soon :-) I don't understand. The command "less" is the default pager of git, so you are prone to have used it already. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 15:20 ` Johannes Schindelin @ 2007-01-23 16:24 ` Andy Parkins 2007-01-23 16:37 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Andy Parkins @ 2007-01-23 16:24 UTC (permalink / raw) To: git; +Cc: Johannes Schindelin On Tuesday 2007 January 23 15:20, Johannes Schindelin wrote: > MinGW and cygwin differ in one very important point: cygwin needs an extra > dll, MinGW does not. > > However, the development environment is still console-based, with a bash > so you can run configure and simple bash scripts. It is definitely more > catering to Unix types than Windows types. > > So yes, there is a bash, and there is a less, and there is perl. Those are just tools for MinGW though aren't they? They aren't needed to run the final executable object? MinGW just spits out a native windows .exe - i.e. plain windows. There is no reason to suppose that joe-random-developer will have bash, less and perl, even if they do have git. Which was kind of the point I was making - there is no pager to rely on in Windows, so why not just drop it. Okay, so MinGW comes with some nice UNIXy tools, but MinGW is the compiler, not the environment. Am I still misunderstanding? I'm looking out for the time when C:\SomePath> git commit -a will work (I know - it's a long way off yet). Not for me; I don't care about Windows in the slightest; but some of my colleagues use it, and I'd like to spread the git-religion as far as I can. > > That sounds better than I remember. You'll have talked me into > > migrating to Windows soon :-) > > I don't understand. The command "less" is the default pager of git, so you > are prone to have used it already. Of course I have; I was trying (failing) to be amusing. :-) Whenever I'm forced to use Windows, it's lack of the most basic of command line tools drives me insane, so you saying that less is easily available with good pipe support would ease my insanity slightly if were ever to go back to the dark place. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 16:24 ` Andy Parkins @ 2007-01-23 16:37 ` Johannes Schindelin 2007-01-23 17:02 ` Linus Torvalds 0 siblings, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 16:37 UTC (permalink / raw) To: Andy Parkins; +Cc: git Hi, On Tue, 23 Jan 2007, Andy Parkins wrote: > On Tuesday 2007 January 23 15:20, Johannes Schindelin wrote: > > > MinGW and cygwin differ in one very important point: cygwin needs an extra > > dll, MinGW does not. > > > > However, the development environment is still console-based, with a bash > > so you can run configure and simple bash scripts. It is definitely more > > catering to Unix types than Windows types. > > > > So yes, there is a bash, and there is a less, and there is perl. > > Those are just tools for MinGW though aren't they? They aren't needed to run > the final executable object? MinGW just spits out a native windows .exe - > i.e. plain windows. Yes. But it _does_ have a dependency on perl and bash. For example, when you merge git-merge-one-file is spawned -- a bash script. > There is no reason to suppose that joe-random-developer will have bash, > less and perl, even if they do have git. Which was kind of the point I > was making - there is no pager to rely on in Windows, so why not just > drop it. Okay, so MinGW comes with some nice UNIXy tools, but MinGW is > the compiler, not the environment. You reminded me that I was not precise enough: MSYS provides the UNIXy tools, and the compiler, MinGW is just the headers and import libraries. And while we already depend on bash and friends -- which we put into GIT_EXEC_PATH -- we can ship more: "less". > Am I still misunderstanding? I'm looking out for the time when > > C:\SomePath> git commit -a > > will work (I know - it's a long way off yet). You need an editor, that is for sure, but it is not _that_ far off. Thanks to Johannes Sixt, committing works already (if you don't encounter the same problem starting vi as I do). Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 16:37 ` Johannes Schindelin @ 2007-01-23 17:02 ` Linus Torvalds 2007-01-23 17:07 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Linus Torvalds @ 2007-01-23 17:02 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Andy Parkins, git On Tue, 23 Jan 2007, Johannes Schindelin wrote: > > Yes. But it _does_ have a dependency on perl and bash. For example, when > you merge git-merge-one-file is spawned -- a bash script. That's just disgusting. I thought we fixed it, but apparently we only did so for git-merge-recursive. Hmm? All the other uses seem to be just a case of git-merge-index -o git-merge-one-file -a and wouldn't it be beautiful if the default action for git-merge-index (if you do _not_ specify a merger program) was to do the simple one-file three-way merge that we can already do for real merges? Wouldn't it be nice if we could just do git-merge-index -o -a and be done with it? Johannes, this should be right up your alley.. Hint hint.. Linus ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 17:02 ` Linus Torvalds @ 2007-01-23 17:07 ` Johannes Schindelin 2007-01-24 1:44 ` Junio C Hamano 0 siblings, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 17:07 UTC (permalink / raw) To: Linus Torvalds; +Cc: git Hi, On Tue, 23 Jan 2007, Linus Torvalds wrote: > On Tue, 23 Jan 2007, Johannes Schindelin wrote: > > > > Yes. But it _does_ have a dependency on perl and bash. For example, when > > you merge git-merge-one-file is spawned -- a bash script. > > That's just disgusting. I thought we fixed it, but apparently we only did > so for git-merge-recursive. Hmm? > > All the other uses seem to be just a case of > > git-merge-index -o git-merge-one-file -a > > and wouldn't it be beautiful if the default action for git-merge-index (if > you do _not_ specify a merger program) was to do the simple one-file > three-way merge that we can already do for real merges? If you think that's a new dream: http://article.gmane.org/gmane.comp.version-control.git/32046/match=git-merge-one-file Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 17:07 ` Johannes Schindelin @ 2007-01-24 1:44 ` Junio C Hamano 2007-01-24 1:57 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2007-01-24 1:44 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git, Linus Torvalds Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> All the other uses seem to be just a case of >> >> git-merge-index -o git-merge-one-file -a >> >> and wouldn't it be beautiful if the default action for git-merge-index (if >> you do _not_ specify a merger program) was to do the simple one-file >> three-way merge that we can already do for real merges? > > If you think that's a new dream: > > http://article.gmane.org/gmane.comp.version-control.git/32046/match=git-merge-one-file (OT: heh, I did not notice Linus's mailing address when I saw his message for the first time). I've thought about it when I was really bored, but noticed that we have no serious users of git-merge-index/git-merge-one-file combinations anymore in-tree (octopus does not count, and it is trivial to make it use merge-recursive if somebody is twisted enough). ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-24 1:44 ` Junio C Hamano @ 2007-01-24 1:57 ` Johannes Schindelin 2007-01-24 5:05 ` Junio C Hamano 0 siblings, 1 reply; 53+ messages in thread From: Johannes Schindelin @ 2007-01-24 1:57 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Linus Torvalds Hi, On Tue, 23 Jan 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > Linus wrote: > > > >> All the other uses seem to be just a case of > >> > >> git-merge-index -o git-merge-one-file -a > >> > >> and wouldn't it be beautiful if the default action for git-merge-index (if > >> you do _not_ specify a merger program) was to do the simple one-file > >> three-way merge that we can already do for real merges? > > > > If you think that's a new dream: > > > > http://article.gmane.org/gmane.comp.version-control.git/32046/match=git-merge-one-file > > I've thought about it when I was really bored, but noticed that we have > no serious users of git-merge-index/git-merge-one-file combinations > anymore in-tree (octopus does not count, and it is trivial to make it > use merge-recursive if somebody is twisted enough). Hah! You just pulled the last serious user! That's cheating. Seriously again, the users of merge-index are (git-checkout, which you pulled) git-merge, which I do not really understand git-merge-octopus, which you already discussed git-merge-resolve, which is (hopefully) superseded by -recursive git-merge-stupid, which is stupid git-resolve, which is deprecated. What I am nervous about is git-merge. I do not even fully understand in which circumstances it calls merge-index at all. (Too tired to read that now, anyway.) Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-24 1:57 ` Johannes Schindelin @ 2007-01-24 5:05 ` Junio C Hamano 2007-01-24 10:24 ` Johannes Schindelin 0 siblings, 1 reply; 53+ messages in thread From: Junio C Hamano @ 2007-01-24 5:05 UTC (permalink / raw) To: Johannes Schindelin; +Cc: git Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > Seriously again, the users of merge-index are > > git-merge, which I do not really understand > > What I am nervous about is git-merge. I think you are referring to the "carry forward local change" logic in 'next'. First of all, BAD DSCHO. You should be looking at 'master', not 'next' during -rc period ;-). Seriously again, the codepath is taken when the merge is a fast forward to another commit (iow, our HEAD is an ancestor of the other branch, so we will end up updating the branch tip with the tip of the other branch). The use of merge-index there can be replaced when we use merge-recursive instead of the 3-way "read-tree -m" the same way as how "checkout -m" implements the branch switching with local changes. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-24 5:05 ` Junio C Hamano @ 2007-01-24 10:24 ` Johannes Schindelin 0 siblings, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-24 10:24 UTC (permalink / raw) To: Junio C Hamano; +Cc: git Hi, On Tue, 23 Jan 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > Seriously again, the users of merge-index are > > > > git-merge, which I do not really understand > > > > What I am nervous about is git-merge. > > I think you are referring to the "carry forward local change" > logic in 'next'. > > First of all, BAD DSCHO. You should be looking at 'master', not > 'next' during -rc period ;-). Guilty on all accounts. Actually, I am not looking at 'next', but on 'my', which is my long-running sidebranch of next, which contains all the scripts I like to run manually, or in cron. > Seriously again, the codepath is taken when the merge is a fast > forward to another commit (iow, our HEAD is an ancestor of the > other branch, so we will end up updating the branch tip with the > tip of the other branch). The use of merge-index there can be > replaced when we use merge-recursive instead of the 3-way > "read-tree -m" the same way as how "checkout -m" implements the > branch switching with local changes. Aha. The use of merge-recursive would be really easy, if we did not write $GIT_DIR/LOCAL_DIFF, but $GIT_DIR/TEMP_BRANCH or $GIT_DIR/LOCAL_TREE... Just teasing you... Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 11:32 ` Johannes Schindelin ` (2 preceding siblings ...) 2007-01-23 13:22 ` Andy Parkins @ 2007-01-23 13:36 ` Nguyen Thai Ngoc Duy 2007-01-23 14:15 ` Johannes Schindelin 3 siblings, 1 reply; 53+ messages in thread From: Nguyen Thai Ngoc Duy @ 2007-01-23 13:36 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Johannes Sixt, git On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > On the third hand, I fully expect git on Windows to be used only by GUI > wieners who cannot handle the command line, let alone a pager! ("WTF! How > do I go back to that dollar thingie? You know, where I type git-blabla?") If I have to use git on Windows (very likely now that this port seems to work), I'd much prefer command line interface. cmd.exe may be not good enough so I think we should include bash in git-win32 package. Many git commands are still bash scripts and new commands are often coded as bash scripts. So we need bash in Windows anyway unless Windows Git users accept a limited git version. (no-perl git is acceptable to me). -- Duy ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: MinGW port - initial work uploaded 2007-01-23 13:36 ` Nguyen Thai Ngoc Duy @ 2007-01-23 14:15 ` Johannes Schindelin 0 siblings, 0 replies; 53+ messages in thread From: Johannes Schindelin @ 2007-01-23 14:15 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, git Hi, On Tue, 23 Jan 2007, Nguyen Thai Ngoc Duy wrote: > On 1/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > On the third hand, I fully expect git on Windows to be used only by GUI > > wieners who cannot handle the command line, let alone a pager! ("WTF! How > > do I go back to that dollar thingie? You know, where I type git-blabla?") > > If I have to use git on Windows (very likely now that this port seems > to work), I'd much prefer command line interface. cmd.exe may be not > good enough so I think we should include bash in git-win32 package. > Many git commands are still bash scripts and new commands are often > coded as bash scripts. So we need bash in Windows anyway unless > Windows Git users accept a limited git version. (no-perl git is > acceptable to me). Actually, you cannot work _at all_ with git when you don't have a proper shell. Ciao, Dscho ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2007-02-08 17:23 UTC | newest] Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-01-19 20:48 MinGW port - initial work uploaded Johannes Sixt 2007-01-19 22:47 ` Christian MICHON 2007-01-19 23:53 ` Michael 2007-01-19 23:53 ` Michael 2007-01-20 3:31 ` Shawn O. Pearce 2007-01-20 9:24 ` Johannes Schindelin 2007-01-20 20:05 ` Johannes Sixt 2007-01-20 20:21 ` Christian MICHON 2007-01-22 13:06 ` Christian MICHON 2007-01-22 16:39 ` Linus Torvalds 2007-01-22 22:25 ` Christian MICHON 2007-02-08 8:17 ` H. Peter Anvin 2007-02-08 14:06 ` Christian MICHON 2007-02-08 17:22 ` H. Peter Anvin 2007-01-23 11:25 ` Johannes Schindelin 2007-01-23 13:08 ` Christian MICHON 2007-01-23 14:17 ` Johannes Schindelin 2007-01-23 15:37 ` Linus Torvalds 2007-01-23 15:45 ` Alex Riesen 2007-01-23 15:52 ` Johannes Schindelin 2007-01-23 15:56 ` Alex Riesen 2007-01-23 16:00 ` Johannes Schindelin 2007-01-23 15:53 ` Shawn O. Pearce 2007-01-23 15:49 ` Johannes Schindelin 2007-01-24 7:12 ` Nguyen Thai Ngoc Duy 2007-01-24 10:17 ` Johannes Schindelin 2007-01-24 16:42 ` Linus Torvalds 2007-01-24 21:08 ` Christian MICHON 2007-02-08 17:18 ` H. Peter Anvin 2007-01-22 20:27 ` Johannes Sixt 2007-01-22 22:20 ` Christian MICHON 2007-01-23 8:31 ` Christian MICHON 2007-01-23 11:32 ` Johannes Schindelin 2007-01-23 12:06 ` Jakub Narebski 2007-01-23 15:29 ` Shawn O. Pearce 2007-01-23 13:12 ` Christian MICHON 2007-01-23 14:18 ` Johannes Schindelin 2007-01-23 18:55 ` Christian MICHON 2007-01-23 19:18 ` Johannes Schindelin 2007-01-23 19:28 ` Johannes Schindelin 2007-01-23 13:22 ` Andy Parkins 2007-01-23 14:21 ` Johannes Schindelin 2007-01-23 15:06 ` Andy Parkins 2007-01-23 15:20 ` Johannes Schindelin 2007-01-23 16:24 ` Andy Parkins 2007-01-23 16:37 ` Johannes Schindelin 2007-01-23 17:02 ` Linus Torvalds 2007-01-23 17:07 ` Johannes Schindelin 2007-01-24 1:44 ` Junio C Hamano 2007-01-24 1:57 ` Johannes Schindelin 2007-01-24 5:05 ` Junio C Hamano 2007-01-24 10:24 ` Johannes Schindelin 2007-01-23 13:36 ` Nguyen Thai Ngoc Duy 2007-01-23 14:15 ` Johannes Schindelin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.