Junio C Hamano <gitster@xxxxxxxxx> writes: > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > > > I may be in the minority here, but I'm fairly negative on this entire > > patch series. As you say, supporting these old versions is effectively > > zero-cost, so how does this project benefit from these changes which > > potentially "break" Git for users on older platforms? I see no upside > > here. The cover letter provides no strong justification for > > (potentially) inconveniencing people; the argument about being able to > > utilize more modern Perl features is weak[1] at best and is not > > convincing. > > While I agree with all you said above, one thing I find missing is > that even with #ifdef, we won't be shipping what we tested in real, > as nobody, not just the author that touches the same file with the > #ifdef we added 6 months ago is in, but all other developers who > looked at the change. It merely is "we have #ifdef here and those > with ancient version of the library shouldn't see this new code", > which certainly is good enough for those of us who consider the > ancient platform support as a "best effort" thing. Should I go ahead and send the patch series that I had planned to fix the breakage for old libcurl after all? I've gone ahead and built the latest version for one of the ancient platforms I inexplicably build git for, but am now dealing with breakage on another (SunOS 5.10). (Specifically, the new unit test framework stuff was failing to generate a suite file, patch forthcoming, and depends on mkdtemp, which we check for in configure but use unconditionally in the newly-imported clar, and which I don't have here.) -Alejandro
