On Sun, 13 Sep 2009 22:20:31 +0200 "Carlos R. Mafra" <[email protected]> wrote:
> Thanks Tamas, I've pushed it to 'next'. > > On Sun 13.Sep'09 at 21:05:57 +0200, Tamas TEVESZ wrote: > > apparently my git-fu went on holidays, so the attached needs some > > manual intervention: after having applied (or before, as you see fit), > > manually remove the following files: > > > > wrlib/CmapAlloc.c wrlib/CrCmap.c wrlib/DelCmap.c > > wrlib/LookupCmap.c wrlib/StdCmap.c wrlib/StdCmap.h > > You could have used 'git rm' for that. On the other hand it > would have created a much bigger patch, with more than one > thousand lines being deleted. I tried to search for an > option in 'git format-patch' which would not list the whole > file being deleted, and just say "this file was deleted". > Git already does that when detecting renames... > > > it would be incredibly useful if people having access to commercial > > unixes could check this on things released in the past, say, 15 years. > > i believe back then i had solaris 8+and sco openserver 5+ covered. > > I have a secret to tell. Currently my git repo is not expected to > compile in a non-linux system because of the 'inotify' patch. > That patch btw requires more work to be more 'correct' in the way > it handles signals, but that is beyond my energy ATM and it > has worked fine for me in the last year. > > A while ago when my repo was "just mine" I wasn't worried > about the linux-only issue (and I guess it is gcc-only too, > due to a cleanup which I used a gcc extension for 'case' > ranges). Carlos, which patch was the above change in? > > But I would rather wait for people who care about old or > non-linux systems to get involved and send patches to fix > their compilation problem then do it myself now. Perhaps > they can even report/fix new issues which we don't even > dream of :-) > Gilbert -- To unsubscribe, send mail to [email protected].
