MinGW port - initial work uploaded

MinGW port - initial work uploaded

[Johannes Sixt]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Michael]

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.

Re: MinGW port - initial work uploaded

[Shawn O. Pearce]

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.

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Sixt]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Linus Torvalds]

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

Re: MinGW port - initial work uploaded

[Johannes Sixt]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Jakub Narebski]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

> 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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Andy Parkins]

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

Re: MinGW port - initial work uploaded

[Nguyen Thai Ngoc Duy]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Andy Parkins]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Shawn O. Pearce]

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.

Re: MinGW port - initial work uploaded

[Linus Torvalds]

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

Re: MinGW port - initial work uploaded

[Alex Riesen]

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?

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Shawn O. Pearce]

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.

Re: MinGW port - initial work uploaded

[Alex Riesen]

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?

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Andy Parkins]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Linus Torvalds]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Junio C Hamano]

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).

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Junio C Hamano]

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.

Re: MinGW port - initial work uploaded

[Nguyen Thai Ngoc Duy]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Johannes Schindelin]

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

Re: MinGW port - initial work uploaded

[Linus Torvalds]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[H. Peter Anvin]

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

Re: MinGW port - initial work uploaded

[Christian MICHON]

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

Re: MinGW port - initial work uploaded

[H. Peter Anvin]

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

Re: MinGW port - initial work uploaded

[H. Peter Anvin]

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