Possibility of a MinGW version?

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.

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

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

Sven Verdoolaege wrote:

On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:

quoted

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.

quoted

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

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

On Sat, Dec 24, 2005 at 11:24:23AM +0100, Andreas Ericsson wrote:

Sven Verdoolaege wrote:

quoted

On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:

quoted

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

Hi,

On Sat, 24 Dec 2005, Rob McDonald wrote:

quoted

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

Hi,

On Sat, 24 Dec 2005, Andreas Ericsson wrote:

Sven Verdoolaege wrote:

quoted

On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:

quoted

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.

quoted

quoted

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

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

On Sun, Dec 25, 2005 at 12:16:29PM -0500, Rob McDonald wrote:

quoted

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.

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

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

On Sat, Dec 31, 2005 at 01:53:09PM -0800, H. Peter Anvin wrote:

Christopher Faylor wrote:

quoted

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