Possibility of a MinGW version?

Possibility of a MinGW version?

[Rob McDonald]

1.0 is out the door, with support (to some degree or another) for Cygwin,
BSD, MacOS X, Solaris, and who knows what else, good job all.

What possibility is there of getting git (& assorted tools) to run natively
on Windows (sacrilege I know) using MinGW?  What truly Unixy-only things
does the code do?  Unfortunately, Windows is a reality for many of us.

I'd like to begin experimenting using git to track all of my data files
acting as a synchronization mechanism.  Have all your files up-to-date
everywhere, revision tracking, & redundancy too...  Dedicated Linux
repository at home, dual boot laptop on the road, Windows machine at work,
etc...

Thoughts?  Suggestions?

            Rob

Please CC me, I track the archive closely, but am not subscribed.

Re: Possibility of a MinGW version?

[Andreas Ericsson]

Rob McDonald wrote:
> 1.0 is out the door, with support (to some degree or another) for Cygwin,
> BSD, MacOS X, Solaris, and who knows what else, good job all.
> 
> What possibility is there of getting git (& assorted tools) to run natively
> on Windows (sacrilege I know) using MinGW?  What truly Unixy-only things
> does the code do?  Unfortunately, Windows is a reality for many of us.
> 
> I'd like to begin experimenting using git to track all of my data files
> acting as a synchronization mechanism.  Have all your files up-to-date
> everywhere, revision tracking, & redundancy too...  Dedicated Linux
> repository at home, dual boot laptop on the road, Windows machine at work,
> etc...
> 
> Thoughts?  Suggestions?
> 

The worst trouble you're likely to run into is all the hardcoded paths. 
They are everywhere and ofcourse use the / for path entity separation.

The fact that there are 39 bash'ish shell-scripts does little to help a 
native port, and although they can be fairly easily replaced by "real" 
programs it still means quite a bit of work with little real value for 
the unix-version, so I'm guessing you'll have to write those up for 
yourself.

Is there some reason you can't install Cygwin, which effectively 
overcomes both those problems?

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Possibility of a MinGW version?

[Sven Verdoolaege]

On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
> The worst trouble you're likely to run into is all the hardcoded paths. 
> They are everywhere and ofcourse use the / for path entity separation.

AFAIR, '/' is a valid path separator on Windows.
It's just command.com (does that still exist?) that insisted on '\\'
separators.

> The fact that there are 39 bash'ish shell-scripts does little to help a 
> native port, and although they can be fairly easily replaced by "real" 
> programs it still means quite a bit of work with little real value for 
> the unix-version, so I'm guessing you'll have to write those up for 
> yourself.

Or just use MinGW's bash.

skimo

Re: Possibility of a MinGW version?

[Andreas Ericsson]

Sven Verdoolaege wrote:
> On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
> 
>>The worst trouble you're likely to run into is all the hardcoded paths. 
>>They are everywhere and ofcourse use the / for path entity separation.
> 
> 
> AFAIR, '/' is a valid path separator on Windows.
> It's just command.com (does that still exist?) that insisted on '\\'
> separators.
> 

Are you sure? I've seen lots of porting patches that transliterate those 
to '\\'. Perhaps those who wrote those patches just took for granted 
that it was needed, the same as I did.

> 
>>The fact that there are 39 bash'ish shell-scripts does little to help a 
>>native port, and although they can be fairly easily replaced by "real" 
>>programs it still means quite a bit of work with little real value for 
>>the unix-version, so I'm guessing you'll have to write those up for 
>>yourself.
> 
> 
> Or just use MinGW's bash.
> 

Didn't know it had one. Live and learn, I suppose. Good to know though.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Possibility of a MinGW version?

[Johannes Schindelin]

Hi,

On Sat, 24 Dec 2005, Andreas Ericsson wrote:

> Sven Verdoolaege wrote:
> > On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
> > 
> > > The worst trouble you're likely to run into is all the hardcoded paths.
> > > They are everywhere and ofcourse use the / for path entity separation.
> > 
> > 
> > AFAIR, '/' is a valid path separator on Windows.
> > It's just command.com (does that still exist?) that insisted on '\\'
> > separators.
>
> Are you sure? I've seen lots of porting patches that transliterate those to
> '\\'. Perhaps those who wrote those patches just took for granted that it was
> needed, the same as I did.

I tried it (IIRC even on Win98) and it worked with '/'. If not, it is 
relatively easy to introduce compat_mkdir and compat_open.

(We need compat_mkdir anyway, because the good MinGW people thought it a 
good idea to change the signature from standard mkdir(path, mode) to 
mkdir(path); a major annoyance when porting things to MinGW).

A bigger obstacle is the ubiquitous "c:/blabla". While you can make sure 
that git internally never uses such a rubbish (would be "/c/blabla" in 
MinGW), there are always the users.

> > > The fact that there are 39 bash'ish shell-scripts does little to help a
> > > native port, and although they can be fairly easily replaced by "real"
> > > programs it still means quite a bit of work with little real value for the
> > > unix-version, so I'm guessing you'll have to write those up for yourself.
> > 
> > 
> > Or just use MinGW's bash.

That is correct. MinGW comes with a current bash.

The biggest stoppers, however, are the absence of fork() and of ssh.

I don't know how many times fork() is used just to call another program, 
and then return the the original program. I believe there are some other 
cases, where there is bidirectional communication between the two. This is 
not so easy.

Without ssh, you have only http-push left to do the push, which in turn 
needs a WebServer set up with DAV. Furthermore, you can only fetch via 
HTTP or the git protocol, which both means setting up a server, i.e. you 
have no way to move your data directly between two private repositories.

Yes, there are other SSH's out there. But in order to communicate with the 
other side, MinGW would have to fork() with bidirectional communication. 
Bummer.

I can understand that people would prefer a MinGW version to a cygwin one, 
because of the performance hit, but unfortunately it is probably not worth 
the trouble. I, for one, would not do the work without getting paid very 
well for the job.

Ciao,
Dscho

Re: Possibility of a MinGW version?

[Rob McDonald]

> The worst trouble you're likely to run into is all the hardcoded paths.
> They are everywhere and ofcourse use the / for path entity separation.
>
> The fact that there are 39 bash'ish shell-scripts does little to help a
> native port, and although they can be fairly easily replaced by "real"
> programs it still means quite a bit of work with little real value for
> the unix-version, so I'm guessing you'll have to write those up for
> yourself.

MSYS is a minimal system that includes ports of all build-chain tools you
need to get Makefiles to work.  I would envision using it along with native
ports of Perl, Tk/Tcl, etc.

> Is there some reason you can't install Cygwin, which effectively
> overcomes both those problems?

I've had consistently lousy luck with Cygwin which has left a bad taste in
my mouth.  Cygwin is generally a lot slower than Mingw, although that is
most noticeable when you're making extensive use of math.h.  Also, it seems
that every time I install some package in Cygwin, something else I've
installed gets messed up.  It just seems to me that there isn't any reason
for an efficient command-line tool like git to depend on a large
unmaintained project like Cygwin.

Of course, one could use -mno-cygwin (or whatever it is) to use the MinGW
headers when compiling in Cygwin as an intermediate step.  That would give
any speed advantages.

However, I've had great luck porting Linux apps using the gcc toolchain to
Windows using MinGW.  All these programs 'just worked'.  However, none of
them really did things outside the realm of simple, portable C and Fortran.
Most of them have been old engineering analysis codes which have been ported
a dozen times in their life anyway.

Thanks for the comments.  The best idea may be to just try it....

            Rob

Re: Possibility of a MinGW version?

[Johannes Schindelin]

Hi,

On Sat, 24 Dec 2005, Rob McDonald wrote:

> > Is there some reason you can't install Cygwin, which effectively
> > overcomes both those problems?
> 
> I've had consistently lousy luck with Cygwin which has left a bad taste in
> my mouth.  Cygwin is generally a lot slower than Mingw, although that is
> most noticeable when you're making extensive use of math.h.  Also, it seems
> that every time I install some package in Cygwin, something else I've
> installed gets messed up.  It just seems to me that there isn't any reason
> for an efficient command-line tool like git to depend on a large
> unmaintained project like Cygwin.

Well, cygwin is everything but unmaintained. It's unfair to blaim the good 
work of the cygwin folks if you can't get it to work. I have *never* had a 
problem I could not solve with cygwin. In particular, *no* package got 
messed up when I installed/upgraded another package. Before you ask: I use 
cygwin extensively.

> Of course, one could use -mno-cygwin (or whatever it is) to use the MinGW
> headers when compiling in Cygwin as an intermediate step.  That would give
> any speed advantages.

As I already stated, there are two *big* showstoppers when it comes to 
port git to MinGW.

> However, I've had great luck porting Linux apps using the gcc toolchain to
> Windows using MinGW.  All these programs 'just worked'.

Okay, I'll bite. Could you please port python to MinGW?

> Thanks for the comments.  The best idea may be to just try it....

You're welcome. Just be sure to tackle the hard problems first, else you 
end up having wasted lots of valuable time for nothing.

Hth,
Dscho

Re: Possibility of a MinGW version?

[David Brown]

On Sat, Dec 24, 2005 at 11:24:23AM +0100, Andreas Ericsson wrote:
> Sven Verdoolaege wrote:
> >On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
> >
> >>The worst trouble you're likely to run into is all the hardcoded paths. 
> >>They are everywhere and ofcourse use the / for path entity separation.
> >
> >
> >AFAIR, '/' is a valid path separator on Windows.
> >It's just command.com (does that still exist?) that insisted on '\\'
> >separators.
> 
> Are you sure? I've seen lots of porting patches that transliterate those 
> to '\\'. Perhaps those who wrote those patches just took for granted 
> that it was needed, the same as I did.

AFAIK all of the Win32 APIs accept either forward or backward slash as a
separator.  It has been this way since when they added directories to DOS.

What doesn't always accept forward slashes are commandline utilities that
are using '/' as an option separator.  Most of them these days will accept
the '/', at least in many circumstances.

Dave

Re: Possibility of a MinGW version?

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> The fact that there are 39 bash'ish shell-scripts does little to help a 
> native port...

Can you defend that "bash'ism" comment for all 39?  The one I
know of and would want to get rid of its bashism by rewriting is
git-grep, but most of them I thought was plain POSIX.

Re: Possibility of a MinGW version?

[Andreas Ericsson]

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> 
>>The fact that there are 39 bash'ish shell-scripts does little to help a 
>>native port...
> 
> 
> Can you defend that "bash'ism" comment for all 39?  The one I
> know of and would want to get rid of its bashism by rewriting is
> git-grep, but most of them I thought was plain POSIX.
> 

Not really, no. I meant "there are 39 shell-scripts known to work with 
bash but not necessarily known to fail with any other shell", which 
usually means "it will break with some shell or other, although the 
shell that breaks is unusual enough for everyone not to have tested it 
yet". I'm probably being a bit super-anal and anti-MS biased.

I wrote the first mail being terribly hung over and this one being 
slightly tipsy. I now get the feeling that everything will work out for 
the best. Happy christmas everyone.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Possibility of a MinGW version?

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>
>>> The fact that there are 39 bash'ish shell-scripts does little to
>>> help a native port...
>> Can you defend that "bash'ism" comment for all 39?  The one I
>> know of and would want to get rid of its bashism by rewriting is
>> git-grep, but most of them I thought was plain POSIX.
>
> Not really, no. I meant "there are 39 shell-scripts known to work with 
> bash but not necessarily known to fail with any other shell",...

I am not a Windows person (once I thought heard one particular
version of NT was POSIX compliant but I did not believe it), but
I suspect bash or not they may have trouble with POSIXism (iow
UNIX heritage), and if the port is done the right way by adding
compatibility layer they would end up reinventing Cygwin or
something close to it...

Re: Possibility of a MinGW version?

[Rob McDonald]

> Well, cygwin is everything but unmaintained. It's unfair to blaim the good
> work of the cygwin folks if you can't get it to work. I have *never* had a
> problem I could not solve with cygwin. In particular, *no* package got
> messed up when I installed/upgraded another package. Before you ask: I use
> cygwin extensively.

I'm sorry to have seemed harsh in my criticism.  I have not used Cygwin
seriously in a couple years.  At the time, as a user, I saw no noticable
progress.  The project seemed dead.  I always had trouble with their package
management program.  I'm glad you've never had similar problems.

> As I already stated, there are two *big* showstoppers when it comes to
> port git to MinGW.

Thanks very much for those comments, that is exactly the kind of information
I was hoping to get out of this thread.

> Okay, I'll bite. Could you please port python to MinGW?

As I said, my experience porting apps to MinGW has been very limited in
scope.  Essentially limited to programs that don't use any unixisms.  I see
no need to port Python, they already have a native version.  And, you could
always use Jython if they didn't.

> You're welcome. Just be sure to tackle the hard problems first, else you
> end up having wasted lots of valuable time for nothing.

Thanks for the insight.  I didn't think the shell and / vs \ were going to
be the real issues.

                 Rob

Re: Possibility of a MinGW version?

[Christopher Faylor]

On Sun, Dec 25, 2005 at 12:16:29PM -0500, Rob McDonald wrote:
>>Well, cygwin is everything but unmaintained.  It's unfair to blaim the
>>good work of the cygwin folks if you can't get it to work.  I have
>>*never* had a problem I could not solve with cygwin.  In particular,
>>*no* package got messed up when I installed/upgraded another package.
>>Before you ask: I use cygwin extensively.
>
>I'm sorry to have seemed harsh in my criticism.  I have not used Cygwin
>seriously in a couple years.  At the time, as a user, I saw no
>noticable progress.  The project seemed dead.  I always had trouble
>with their package management program.  I'm glad you've never had
>similar problems.

As was mentioned, the Cygwin project is very far from dead and has
actually never been close to dead.  It is, however, like any open source
project and things like the setup program are always under slow,
sporadic development.

The core cygwin dll is under active development and maintenance and most
of the packages in the distribution are under active maintenance, however.
--
Christopher Faylor			spammer? ->	aaaspam@sourceware.org
Cygwin Co-Project Leader				aaaspam@duffek.com
TimeSys, Inc.

Re: Possibility of a MinGW version?

[Christopher Faylor]

On Sat, Dec 24, 2005 at 08:51:53AM -0500, Rob McDonald wrote:
>MSYS is a minimal system that includes ports of all build-chain tools
>you need to get Makefiles to work.  I would envision using it along
>with native ports of Perl, Tk/Tcl, etc.

MSYS is basically an unmaintained fork of Cygwin.  It uses an old
version of the Cygwin DLL with some hacks to handle path names
differently.  It isn't intended as a platform for porting packages to
MSYS.  It is intended to be used as an environment for porting packages
to MinGW.

cgf

Re: Possibility of a MinGW version?

[H. Peter Anvin]

Christopher Faylor wrote:
> 
> As was mentioned, the Cygwin project is very far from dead and has
> actually never been close to dead.  It is, however, like any open source
> project and things like the setup program are always under slow,
> sporadic development.
> 
> The core cygwin dll is under active development and maintenance and most
> of the packages in the distribution are under active maintenance, however.

Cygwin probably could benefit greatly if they adopted something like 
rpm/yum for packaging, instead of reinventing the wheel.

	-hpa

Re: Possibility of a MinGW version?

[Christopher Faylor]

On Sat, Dec 31, 2005 at 01:53:09PM -0800, H. Peter Anvin wrote:
>Christopher Faylor wrote:
>>As was mentioned, the Cygwin project is very far from dead and has
>>actually never been close to dead.  It is, however, like any open
>>source project and things like the setup program are always under slow,
>>sporadic development.
>>
>>The core cygwin dll is under active development and maintenance and
>>most of the packages in the distribution are under active maintenance,
>>however.
>
>Cygwin probably could benefit greatly if they adopted something like
>rpm/yum for packaging, instead of reinventing the wheel.

Yes, Cygwin isn't a new project so ideas like this have been kicked
around many times over the years.  You can't just port rpm, apt, or yum
and then say "We'll use this for updates now" because there are
chicken/egg problems.  The problems are not unsolvable but, so far, no
one has cared enough to do anything about them.

cgf