Hi Jeff, On Tue, Apr 27, 2010 at 10:08:16PM -0400, Jeff King wrote: > On Tue, Apr 27, 2010 at 10:13:02PM +0200, Andreas Schwab wrote: > > Jeff King <peff@xxxxxxxx> writes: > > > > > Furthermore, if we do take such changes, how are we going to manage > > > portability going forward? Some constructs (like non-constant > > > initializers) make the code much easier to read. People _will_ submit > > > patches that use them. Is somebody going to be auto-building on all of > > > these platforms with vendor compilers to confirm that nothing is broken? And that's fine. People who are trying to build will notice the breakage on their platforms and likely submit patches in due course. A portability guide in the source tree might help reduce the code churn, I'd even be willing to draft it for you if you agree that it would help. I think it would be just a few hundred words setting out the 5 or 6 problems that I have to patch over-and-over when I port OS packages to our older architectures... > > You can use "gcc -pedantic" to find these portability problems. > > Sort of. It reports much more than we necessarily need to fix to remain > portable to even remotely sane platforms. So it's a nice tool for > finding problems, but somebody needs to do the work of figuring out > which are important and which are not, and then periodically run with > -pedantic and sort out the results. IMHO, unless it is a significant impediment to development of git, then it makes sense to support any platform for which you have someone prepared to maintain the port. While our release cycle revs only 2 or 3 times per year, for as long as I have customers who want me to port to their platforms, I will continue to patch support for those platforms into our packages. I think that it would be a shame if those ports were kept hidden away on our servers and only benefited our customers rather than integrated into upstream for the benefit of the whole community. So the real question is whether uglification of unportable code is so unacceptable that git wants to wilfully reject external maintenance of ports to end-of-life but none-the-less deployed and active architectures? Cheers, -- Gary V. Vaughan (gary@xxxxxxxxxxxxxxxxxx) -- 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