patch, 2 partsRestore support for older libcurl and fix some typos

Hi,

This is the small patchset I've mentioned on a couple of threads in the past few days [1, 2].

The first patch adds a version check for CURLOPT_PROXYHEADER in git-curl-compat.h and uses it to wrap the one use of CURLOPT_PROXYHEADER, replacing it with a translatable warning if it's used on an older version of libcurl.

The second patch adjusts some typos I noticed in git-curl-compat.h. These should be easily verifiable against curl's docs/libcurl/symbols-in-version, which is the source of truth for git-curl-compat.h.

This is presented as an alternative to the patch series from brian m. carlson that bumps the minimum version of libcurl to 7.61.0 [3].

-Alejandro

[1] https://lore.kernel.org/git/CAOO-Oz1KhFcyErVx1Qb142PtPJS=UpgSD-FacckqNS4_okAtFQ@mail.gmail.com/ [2] https://lore.kernel.org/git/20241011190812.2654837-1-asedeno@mit.edu/ [3] https://lore.kernel.org/git/20241010235621.738239-1-sandals@crustytoothpaste.net/

Alejandro R. Sedeño (2):
  Conditional use of CURLOPT_PROXYHEADER based on libcurl version
  Fix inconsistencies in git-curl-compat.h

 git-curl-compat.h | 11 +++++++++--
 http.c            |  4 ++++
 2 files changed, 13 insertions(+), 2 deletions(-)

Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Signed-off-by: Alejandro R. Sedeño <asedeno@google.com>
---
 git-curl-compat.h | 7 +++++++
 http.c            | 4 ++++
 2 files changed, 11 insertions(+)

Signed-off-by: Alejandro R. Sedeño <asedeno@mit.edu>
Signed-off-by: Alejandro R. Sedeño <asedeno@google.com>
---
 git-curl-compat.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:

This conflicts with brian's series as you mention, so I haven't picked this one up in 'seen' yet.

Could you summarize why you think this series is a better approach than what brian has posted? On its own, I do not understand the motivation.

Thanks, Taylor

On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:

It's a question of preserving compatibility vs ratcheting up minimum requirements. Both have their merits. I sent in this patch set after seeing some mild pushback to brian's series, just to present an alternative. Maintaining compatibility with older versions can be a burden to the project, though I think given this patch series, it's not a very big one. Ratcheting up the minimum requirements can be a burden to users stuck on (or choosing to try and support) older platforms. At some point the burden on the project outweighs the desire to support those older platforms. Where that tipping point is is for the community to decide.

For my own personal purposes, I've worked around the issue by building a newer libcurl to link git against, though brian's updates to the perl minimum requirements will pose a more substantial problem for me in the future.

-Alejandro

On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño <asedeno@mit.edu> wrote:

For reference, I'm the one who pushed back on brian's series. The "push-back" subthread starts at [1].

[1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe

On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:

OK. Junio had brian's series in 'seen' when I picked up the integration branches on Friday evening. Let's keep it that way for now while we wait to see what approach between the two is preferred.

Thanks, Taylor

On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:

Being one of the people who has to work with older distributions, I think that I would support the pushback.

There are many machines out there, which are still running in production with old installations. In my case it is a Centos 7 machine, coming with Git 1.8.3.1

Out of my head, git submodules didn't work (as good as today), and even things like git -P didn't exist then.

I may be worth to mention that this machines are protected by double or triple firewalls, routing tables, and whatever is needed to protect them. Maintaining production software and hardware, systems using specialized hardware with Linux drivers dependend on the Linux kernel is daily work.

And here tools like Git are needed (and appreciated).

My view is that the new developments can focus on the "latest" distributions, and if some comes along and has a patch that make Git compile and work under an older system, and that patch does not break newer systems, it would be a good thing to accept.

The seen branch from October 11 does not compile (any more) under Centos 7. One problem is the curl stuff. And then some warning, missing a prototype for lstat() in clar.c/fs_copy(). And warnings about missing braces around initializers, nothing to worry about.

Lets try a summarize: I can volunteer to compile Git from seen on this Centos box, lets say once a week, and report breakages.

Other toughts ?

On Thu, Oct 17, 2024 at 08:59:37AM +0200, Torsten Bögershausen wrote:

yes.

but why? why do you need bleeding edge git on these special-purpose systems from the stone age? wouldn't any sane developer (cross-)build on a modern system (which usually has about an order of magnitude more computing power, aside from the newer tools) and then deploy and extract only what's needed via some mostly automated process? it would only matter if git was part of the production software (what for?), but then we're back to square one.

Just a short update: This make git compile (again) on the mentioned centos system.