Re: [PATCH 2/2] git-curl-compat.h: addition of all symbols defined by curl

From: Elia Pinto <gitter.spiros@gmail.com>
Date: Mar 16, 2022, 22:24 UTC
Message-ID: <CA+EOSBmmK0hEfgiYiSgzGmBVuib1rOZsgd8yNPLxonJ0Lj3M_g@mail.gmail.com>
In-Reply-To: <220316.86czimdkb0.gmgdl@evledraar.gmail.com>

Il giorno mer 16 mar 2022 alle ore 15:49 Ævar Arnfjörð Bjarmason <avarab@gmail.com> ha scritto:

Show 31 quoted lines

>
>
> On Wed, Mar 16 2022, Elia Pinto wrote:
>
> Per the comment on v1 I really think we should not do this...
>
> > This file was produced from a modified version of symbols.pl
> > (https://github.com/curl/curl/blob/master/docs/libcurl/symbols.pl) and
> > by manually adding the previous comments describing the dates of release
> > of some curl versions not currently reported in the symbols-in-versions.
> >
> > To do this the symbols are listed in the order defined in the file
> > symbols-in-versions rather than as they were previously inserted based
> > on release dates.
> >
> > Most of these symbols are not used by git today. However, inserting
> > them all starting from an automatic tool makes it largely unnecessary
> > to update this file and therefore reduces the possibility
> > of introducing possible errors in the future.
> >
> > Helped-by: Junio C Hamano <gitster@pobox.com>
> > Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
>
> But more generally, re your reply on v1:
>
>     In the end I did not understand if you think it is worthwhile that i
>     do a reroll of  the patch[...]
>
> Better than a re-roll is replying to outstanding concerns about your
> patches. I.e. this, which still applies here
> https://lore.kernel.org/git/220315.86pmmndmre.gmgdl@evledraar.gmail.com/

Yes, sorry, I was going to do this, but it was a tough day at work and I could only try to redo the patch. However, I largely agree with your comments. The biggest work is what you have done previously in trying to simplify and rationalize dependencies on curl versions. My patch only extends your work by adopting the curl maintainer best practices for doing the same thing, although I had to adapt them to the schema you introduced. But I don't see it as a problem. So my patch does not introduce any ad hoc version of these dependencies but the choice made upstream, which I think may be worth in terms of extensibility and future maintenance. Initially I wanted to release the tool I made to produce git-curl-compat.h indeed but symbol-in-versions has no information on the release dates of the various curl versions and even if a symbol is an enum or not: so so i left your comments where they were

That the biggest job is what you (or whoever gets to work on it) have done working on the git source is no doubt for me. My contribution, much smaller, just wanted to enhance what you had done.

If my patch is completely useless or not I leave it to the git community, including you, of course. Anyway at least the Junio fix I put in the other patch I think is a good thing anyway.

Thanks and sorry again for the delay in replying.

Elia