Re: git 0.99.7b doesn't build on Cygwin

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 24, 2005, 01:13 UTC
Message-ID: <Pine.LNX.4.63.0509240305450.26220@wgmdd8.biozentrum.uni-wuerzburg.de>
In-Reply-To: <Pine.LNX.4.58.0509231647300.3308@g5.osdl.org>

Hi,

On Fri, 23 Sep 2005, Linus Torvalds wrote:

Show 11 quoted lines

> On Fri, 23 Sep 2005, Johannes Schindelin wrote:
> > 
> > It seems that the fixup of the mmap()ed regions after a fork() does not 
> > work properly in cygwin. Remember that cygwin just wraps the non-POSIX 
> > Win32API and tries to make it sort of POSIX compliant. The problem is that 
> > Win32API lacks a proper fork(). This is therefore emulated, and after 
> > that, all the mmap()ed regions have to be mapped again. That fails.
> 
> Now, I'm not a big fan of windows ("No, really? Tell us more!") but I'd 
> actually like it if the _core_ git stuff worked in as wide a variety of 
> situations as possible.

It is sure worth to try to be as portable as possible. Just look at the bugs found by running git on x86_64 (for example by HPA), which were not apparent from x86 or PowerPC.

> Screw the shell scripts and the daemon or secondary things like that 
> which windows users might as well generate their own stuff for, but I'd 
> hope the really core stuff would work.

Whoa, slow! The shell scripts and the networking are important parts even of the core git suite. Without them, work is next to impossible.

> If I understood correctly, you said that "git-diff-tree" doesn't work due
> to the fork/mmap issue. Now, I assume that means that it's the builtin
> diff that has problems.

No. It means that there is something weird going on inside cygwin1.dll. This library works perfectly when the program is run inside gdb. Which could well mean some timing issue. Unfortunately, I have problems rebuilding cygwin1.dll, and therefore cannot debug in detail.

BTW I am fairly convinced that the same issues would trouble a git-pull, once the networking is running, since the pack transfer relies on fork()ing.

> I'm wondering if there is some stupid way to turn a diff generated by 
> diff_delta() into a line-based one? If you have the original file and the 
> xdiff, I think we should be able to just walk the original file and output 
> a unified diff.

It sure would be nice to have a unified diff generator included, but I doubt that a reliable (=simple) one is easy to come by.

Ciao, Dscho