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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html