Re: git 0.99.7b doesn't build on Cygwin

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

> As far as I can tell, we can solve that two ways:
>
> - make Windows always use the external diff program. That may be the
>   right thing to do, since then the fork() just turns into a regular
>   fork+exec, which is how windows works anyway.
>
> - look at doing the diff internally.
>
> 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.
>
> Davide, maybe I'm being stupid, but I'm thinking that it might be possible
> to generate a -u3 diff by basically walking the xdiff file in a linear
> fashion: if the edits are in strictly ascending order, we could walk the
> original file one line at a time, and keeping a buffer of the three last
> lines. Then, when the file offset hits the next "edit" in the xdiff, we
> start generating a line-based diff (and use the previous three lines as
> the context).
>
> Does that sound possible? Maybe somebody has even done it? Is it a stupid
> idea?
>
> I realize that it might not generate the same diff as GNU diff would do,
> and maybe it's really nasty, but it sounds like it _could_ be a "cheap"
> way of generating diffs, considering that we have something that already
> generates xdiffs..