From mboxrd@z Thu Jan 1 00:00:00 1970 From: Davide Libenzi Subject: Re: git 0.99.7b doesn't build on Cygwin Date: Fri, 23 Sep 2005 22:11:22 -0700 (PDT) Message-ID: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Johannes Schindelin , Peter TB Brett , Git Mailing List X-From: git-owner@vger.kernel.org Sat Sep 24 07:09:28 2005 Return-path: Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EJ2Hc-000692-0e for gcvg-git@gmane.org; Sat, 24 Sep 2005 07:09:08 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751415AbVIXFIp (ORCPT ); Sat, 24 Sep 2005 01:08:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751425AbVIXFIo (ORCPT ); Sat, 24 Sep 2005 01:08:44 -0400 Received: from x35.xmailserver.org ([69.30.125.51]:54914 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S1751415AbVIXFIn (ORCPT ); Sat, 24 Sep 2005 01:08:43 -0400 X-AuthUser: davidel@xmailserver.org Received: from debstar.dev.mdolabs.com by xmailserver.org with [XMail 1.22 ESMTP Server] id for from ; Fri, 23 Sep 2005 22:09:44 -0700 X-X-Sender: davide@localhost.localdomain To: Linus Torvalds In-Reply-To: X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, 23 Sep 2005, Linus Torvalds wrote: > > > 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. Stay away from Cygwin if you use extensively fork(), since it becomes dog slow (the fork() implementation on Cygwin involves creating a new suspended task, *copy* - not COW - the *whole* VM space to the child, and resuming it). Actually, the whole Cygwin in general is dog slow, especially on FS operations (and git likes them). If you really like to have Windows support (uuu hoo WinTorvalds) you might be better using a small compat layer (should be fairly small for git). > 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.. Hehe, the same library from where Nicolas lifted the code for the binary diff, has a totally portable diff/patch APIs (on top of xdiff/xpach): http://www.xmailserver.org/xdiff.html Generating text diffs, unfortunately is quite more complex than binary ones. Libxdiff uses the same algorithm of GNU diff (Eugene W. Myers). The library has zero dependency other than ANSI C. Another alternative, IIRC someone made a library by wrapping the diffutil stuff, but I do not remeber where it was. - Davide