Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 16.11.12 19:52, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> My understanding: >> Either use people cygwin 1.5 or they use cygwin 1.7, and in this case >> the installation is updated frequently. >> >> Peff or Junio, please go ahead with the patch. >> >> If it turns out that we want to support cygwin installations like 1.7.7 >> which could be upgraded, but are not upgraded since they are >> "production machines we do not dare to touch" we can still improve >> the autodetection. > > OK. I moved the topic forward but we may still want to rename the > name of the macro to have CYGWIN somewhere in the name. I send a patch some seconds ago. I forgot to mention that this should be applied to next -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Torsten Bögershausen writes: > My understanding: > Either use people cygwin 1.5 or they use cygwin 1.7, and in this case > the installation is updated frequently. > > Peff or Junio, please go ahead with the patch. > > If it turns out that we want to support cygwin installations like 1.7.7 > which could be upgraded, but are not upgraded since they are > "production machines we do not dare to touch" we can still improve > the autodetection. OK. I moved the topic forward but we may still want to rename the name of the macro to have CYGWIN somewhere in the name. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 11/15/2012 02:35 PM, Torsten Bögershausen wrote: On 11/15/2012 08:05 PM, Ramsay Jones wrote: Did the cygwin project not bump an api version number somewhere? ATB, Ramsay Jones Ramsay, you can run uname -r to see the version number. I myself haven't fully understood all the consequences, somewhere between 1.7.7 and 1.7.17 the include files had been changed. If this has consequences for using e.g. winsock2.dll, I want to know myself ;-) /Torsten uname -r gives the version of the dll, not of any particular package, and all of the various components are versioned independently. The win32api is spread across several packages, and the recent update changed the names, There is no api number advertised. You could check the names of currently installed packages if you assume those names won't change, but any such method is going to be fragile (and very unsupported). Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 11/15/2012 08:05 PM, Ramsay Jones wrote: Torsten Bögershausen wrote: * ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on newer cygwin. Will merge to 'next'. (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu) (And thanks for maintaining git) Is everybody using cygwin happy with this? I am still on cygwin 1.5.22 and quite happy that this patch does not (seem) to cause any problems. ;-P I managed to compile on a fresh installed cygwin, but failed to compile under 1.7.7, see below. Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ? Or is this not worth the effort? Did the cygwin project not bump an api version number somewhere? ATB, Ramsay Jones Ramsay, you can run uname -r to see the version number. I myself haven't fully understood all the consequences, somewhere between 1.7.7 and 1.7.17 the include files had been changed. If this has consequences for using e.g. winsock2.dll, I want to know myself ;-) /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Torsten Bögershausen wrote: >> * ml/cygwin-mingw-headers (2012-11-12) 1 commit >> - Update cygwin.c for new mingw-64 win32 api headers >> >> Make git work on newer cygwin. >> >> Will merge to 'next'. > > (Sorry for late answer, I managed to test the original patch minutes before > Peff merged it to pu) > (And thanks for maintaining git) > > Is everybody using cygwin happy with this? I am still on cygwin 1.5.22 and quite happy that this patch does not (seem) to cause any problems. ;-P > I managed to compile on a fresh installed cygwin, > but failed to compile under 1.7.7, see below. > Is there a way we can achieve to compile git both under "old" and "new" > cygwin 1.7 ? > Or is this not worth the effort? Did the cygwin project not bump an api version number somewhere? ATB, Ramsay Jones -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 15.11.12 02:56, Jeff King wrote: > On Wed, Nov 14, 2012 at 08:50:43PM -0500, Mark Levedahl wrote: > >> Cygwin changed the win32api implementation, and the old is not just >> no longer supported for the current release series, but virtually >> impossible to even install (several new packages are now installed, >> the old package is in the "obsolete" category, i.e., not available). >> The older cygwin 1.5 dll + utilities can be installed afresh, so that >> is why I set up to switch based upon dll version - the proposed >> test(s) and configuration would be to have git maintain compatibility >> with an unsupported Cygwin configuration. I just don't think this is >> worth the maintenance burden, but of course I am not the maintainer, >> just expressing my opinion. > > OK. I don't have a strong opinion either, as I don't know what's normal > in the Cygwin world, and that is probably the most important thing to > follow for the default. I got the impression that "normal" is changing > to the new way, but Torsten's message made me wonder if were there quite > yet (if there was some issue with upgrades versus new fresh installs). > > But I have no real cygwin knowledge, so I'll bow out and let you guys > discuss. > My understanding: Either use people cygwin 1.5 or they use cygwin 1.7, and in this case the installation is updated frequently. Peff or Junio, please go ahead with the patch. If it turns out that we want to support cygwin installations like 1.7.7 which could be upgraded, but are not upgraded since they are "production machines we do not dare to touch" we can still improve the autodetection. Thanks for the responses. /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On Wed, Nov 14, 2012 at 08:50:43PM -0500, Mark Levedahl wrote: > Cygwin changed the win32api implementation, and the old is not just > no longer supported for the current release series, but virtually > impossible to even install (several new packages are now installed, > the old package is in the "obsolete" category, i.e., not available). > The older cygwin 1.5 dll + utilities can be installed afresh, so that > is why I set up to switch based upon dll version - the proposed > test(s) and configuration would be to have git maintain compatibility > with an unsupported Cygwin configuration. I just don't think this is > worth the maintenance burden, but of course I am not the maintainer, > just expressing my opinion. OK. I don't have a strong opinion either, as I don't know what's normal in the Cygwin world, and that is probably the most important thing to follow for the default. I got the impression that "normal" is changing to the new way, but Torsten's message made me wonder if were there quite yet (if there was some issue with upgrades versus new fresh installs). But I have no real cygwin knowledge, so I'll bow out and let you guys discuss. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 11/14/2012 07:16 PM, Jeff King wrote: On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote: b) Autodetection: (Just loud thinking), running $grep mingw /usr/include/w32api/winsock2.h * This file is part of the mingw-w64 runtime package. #include <_mingw_unicode.h> on cygwin 1.7.17 indicates that we can use grep in the Makefile to autodetect the "mingw headers" Hmm. Can we rely on the /usr/include bit, though? I assume a test-compile would be sufficient, but currently we do not do anything more magic than "uname" in the Makefile itself to determine defaults. Maybe it would be better to do the detection in the configure script? And then eventually flip the default in the Makefile once sufficient time has passed for most people to want the new format (which would not be necessary for people using autoconf, but would help people who do not). -Peff Cygwin changed the win32api implementation, and the old is not just no longer supported for the current release series, but virtually impossible to even install (several new packages are now installed, the old package is in the "obsolete" category, i.e., not available). The older cygwin 1.5 dll + utilities can be installed afresh, so that is why I set up to switch based upon dll version - the proposed test(s) and configuration would be to have git maintain compatibility with an unsupported Cygwin configuration. I just don't think this is worth the maintenance burden, but of course I am not the maintainer, just expressing my opinion. I have no trouble renaming the macro to whatever seems to clarify things. Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Jeff King writes: > On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote: > >> * ml/cygwin-mingw-headers (2012-11-12) 1 commit >> - Update cygwin.c for new mingw-64 win32 api headers >> >> Make git work on newer cygwin. >> >> Will merge to 'next'. > > I'm cc-ing Junio in case he missed the discussion; my original plan had > been to move this topic right to 'next' to get exposure from other > cygwin people. But it seems we have already got that, and it might need > re-rolling, so it probably makes sense to hold back until the discussion > reaches a conclusion. Thanks for a reminder; that is what I did. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On Wed, Nov 14, 2012 at 10:13:28PM +0100, Torsten Bögershausen wrote: > * ml/cygwin-mingw-headers (2012-11-12) 1 commit > - Update cygwin.c for new mingw-64 win32 api headers > > Make git work on newer cygwin. > > Will merge to 'next'. I'm cc-ing Junio in case he missed the discussion; my original plan had been to move this topic right to 'next' to get exposure from other cygwin people. But it seems we have already got that, and it might need re-rolling, so it probably makes sense to hold back until the discussion reaches a conclusion. > There are a couple of things which we may want consider: > a) the name V15_MINGW_HEADERS: > It indicates that this is true for Version 1.5 (of what?) > If I assume Cygwin version 1.5 , then this name is confusing. > Even cygwin versions like 1.7.7 use the same (or similar) include files as > 1.5 > A better name could be CYGWIN_USE_MINGW_HEADERS (or the like) and to revert > the logic. Regardless of flipping the logic, I agree that having CYGWIN in the name makes a lot of sense. > b) Autodetection: > (Just loud thinking), running > $grep mingw /usr/include/w32api/winsock2.h > * This file is part of the mingw-w64 runtime package. > #include <_mingw_unicode.h> > > on cygwin 1.7.17 indicates that we can use grep in the Makefile to > autodetect the "mingw headers" Hmm. Can we rely on the /usr/include bit, though? I assume a test-compile would be sufficient, but currently we do not do anything more magic than "uname" in the Makefile itself to determine defaults. Maybe it would be better to do the detection in the configure script? And then eventually flip the default in the Makefile once sufficient time has passed for most people to want the new format (which would not be necessary for people using autoconf, but would help people who do not). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 14.11.12 20:02, Jeff King wrote: > On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote: > >> On 11/13/2012 03:45 PM, Torsten Bögershausen wrote: * ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on newer cygwin. Will merge to 'next'. >>> (Sorry for late answer, I managed to test the original patch minutes before >>> Peff merged it to pu) >>> (And thanks for maintaining git) >>> >>> Is everybody using cygwin happy with this? >>> >>> I managed to compile on a fresh installed cygwin, >>> but failed to compile under 1.7.7, see below. >>> Is there a way we can achieve to compile git both under "old" and "new" >>> cygwin 1.7 ? >>> Or is this not worth the effort? >>> >> I found no version info defined that could be used to automatically >> switch between the old and current headers. You can always >> >> make V15_MINGW_HEADERS=1 ... >> >> to force using the old set if you do not wish to update your installation. > > Should we keep the code change, then, but not flip the default (i.e., > make people on the newer version opt into it)? I am not clear on how > common the newer include system is. Of course, auto-detecting would be > the ideal. > > -Peff There are a couple of things which we may want consider: a) the name V15_MINGW_HEADERS: It indicates that this is true for Version 1.5 (of what?) If I assume Cygwin version 1.5 , then this name is confusing. Even cygwin versions like 1.7.7 use the same (or similar) include files as 1.5 A better name could be CYGWIN_USE_MINGW_HEADERS (or the like) and to revert the logic. b) Autodetection: (Just loud thinking), running $grep mingw /usr/include/w32api/winsock2.h * This file is part of the mingw-w64 runtime package. #include <_mingw_unicode.h> on cygwin 1.7.17 indicates that we can use grep in the Makefile to autodetect the "mingw headers" Something like this in Makefile: +ifeq ($(shell grep mingw /usr/include/w32api/winsock2.h />/dev/null 2>/dev/null && echo y),y) + CYGWIN_USE_MINGW_HEADERS=YesPlease +endif c) I'm not sure if we want to change cygwin.c or git-compat-util.h for this. I can prepare a proper patch within the next couple of days /Torsten -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On Tue, Nov 13, 2012 at 08:18:53PM -0500, Mark Levedahl wrote: > On 11/13/2012 03:45 PM, Torsten Bögershausen wrote: > >>* ml/cygwin-mingw-headers (2012-11-12) 1 commit > >> - Update cygwin.c for new mingw-64 win32 api headers > >> > >> Make git work on newer cygwin. > >> > >> Will merge to 'next'. > >(Sorry for late answer, I managed to test the original patch minutes before > >Peff merged it to pu) > >(And thanks for maintaining git) > > > >Is everybody using cygwin happy with this? > > > >I managed to compile on a fresh installed cygwin, > >but failed to compile under 1.7.7, see below. > >Is there a way we can achieve to compile git both under "old" and "new" > >cygwin 1.7 ? > >Or is this not worth the effort? > > > I found no version info defined that could be used to automatically > switch between the old and current headers. You can always > > make V15_MINGW_HEADERS=1 ... > > to force using the old set if you do not wish to update your installation. Should we keep the code change, then, but not flip the default (i.e., make people on the newer version opt into it)? I am not clear on how common the newer include system is. Of course, auto-detecting would be the ideal. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
On 11/13/2012 03:45 PM, Torsten Bögershausen wrote: * ml/cygwin-mingw-headers (2012-11-12) 1 commit - Update cygwin.c for new mingw-64 win32 api headers Make git work on newer cygwin. Will merge to 'next'. (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu) (And thanks for maintaining git) Is everybody using cygwin happy with this? I managed to compile on a fresh installed cygwin, but failed to compile under 1.7.7, see below. Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ? Or is this not worth the effort? /Torsten I found no version info defined that could be used to automatically switch between the old and current headers. You can always make V15_MINGW_HEADERS=1 ... to force using the old set if you do not wish to update your installation. Mark -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Jeff King writes: > What's cooking in git.git (Nov 2012, #03; Tue, 13) > -- > > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. > > This is my final "what's cooking" as interim maintainer. I didn't > graduate anything to master, but I updated my plans for each topic to > give Junio an idea of where I was. > > You can find the changes described here in the integration branches of > my repository at: > > git://github.com/peff/git.git > > Until Junio returns, kernel.org and the other "usual" places will not be > updated. And now the "usual places" have been updated with the same tips of integration branches (the broken-out https://github.com/gitster/git repository, too). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's cooking in git.git (Nov 2012, #03; Tue, 13)
> -Original Message- > From: Torsten Bögershausen > Sent: Tuesday, November 13, 2012 3:45 PM > > > * ml/cygwin-mingw-headers (2012-11-12) 1 commit > > - Update cygwin.c for new mingw-64 win32 api headers > > > > Make git work on newer cygwin. > > > > Will merge to 'next'. > > (Sorry for late answer, I managed to test the original patch minutes > before Peff merged it to pu) > (And thanks for maintaining git) > > Is everybody using cygwin happy with this? > > I managed to compile on a fresh installed cygwin, > but failed to compile under 1.7.7, see below. > Is there a way we can achieve to compile git both under "old" and "new" > cygwin 1.7 ? > Or is this not worth the effort? Only supporting the new cygwin would make sense. You have to work hard at using older cygwin environments. I will give it a spin later today or tomorrow. -Jason smime.p7s Description: S/MIME cryptographic signature
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
> * ml/cygwin-mingw-headers (2012-11-12) 1 commit > - Update cygwin.c for new mingw-64 win32 api headers > > Make git work on newer cygwin. > > Will merge to 'next'. (Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu) (And thanks for maintaining git) Is everybody using cygwin happy with this? I managed to compile on a fresh installed cygwin, but failed to compile under 1.7.7, see below. Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ? Or is this not worth the effort? /Torsten CC compat/cygwin.o In file included from compat/../git-compat-util.h:90, from compat/cygwin.c:9: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: warning: #warning "fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets" In file included from /usr/include/sys/socket.h:16, from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr' /usr/include/cygwin/socket.h:41: error: redefinition of `struct sockaddr_storage' In file included from /usr/include/sys/socket.h:16, from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/cygwin/socket.h:59: error: redefinition of `struct linger' In file included from compat/../git-compat-util.h:131, from compat/cygwin.c:9: /usr/include/sys/socket.h:30: error: conflicting types for 'accept' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: error: previous declaration of 'accept' was here -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
Jeff King writes: > This is my final "what's cooking" as interim maintainer. I didn't > graduate anything to master, but I updated my plans for each topic to > give Junio an idea of where I was. After exploding the first-parent history between your master..pu into component topics and recreating one new merge-fix for nd/wildmatch topic, I think I now know how to rebuild your integration branches. I still haven't caught up with the past discussions (and still am slightly jetlagged), but I think I can take it over from here with help from contributors. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
