Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > On Thu, Feb 09 2023, Ævar Arnfjörð Bjarmason wrote: > >> On Thu, Feb 09 2023, Glen Choo wrote: >> >>> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >>>> [...] >>>> In a subsequent commit we'll fix the other *_get_*() functions to so >>>> that they'll ferry our underlying "ret" along, rather than normalizing >>>> it to a "return 1". But as an intermediate step to that we'll need to >>>> fix git_configset_get_value_multi() to return "int", and that change >>>> itself is smaller because of this change to migrate some callers away >>>> from the *_value_multi() API. >>> >>> I haven't read ahead, but on first impression this sounds like it might >>> be too intrusive for a series whose goal is to clean up >>> *_get_value_multi(). >> >> Yeah, that was my inclination too :) But Glen seemed to have a strong >> opinion on the end-state of the topic being inconsistent in its API >> (which he's right about, some stuff returning -1 or 1, some only 1). > > Hrm, so clearly I lost track of who I was replying to there, sorry :) > > I thought this was a reply from Junio at the time. Heh. Maybe I do a good Junio impression. >> I wanted to just leave it for a follow-up topic I've got to fix various >> warts in the API, but cherry-picked & included the new 06/10 here to >> address that concern. >> >> I'm also confident that we can expose this to current API users, so >> partly I'm playing reviewer flip-flop here and seeing what sticks. If >> you feel it should be ejected I'm also happy to do that, and re-roll... Reading ahead, I think that 06/10 should probably be ejected; the series is doing too many things. You're probably right that 06/10 is a safe change to make, but it's a big enough change to require some careful review. I don't think it's worth holding up the original *_multi() changes, especially since I think they're pretty much mergeable. The change would probably make more sense in the follow up topic. I wouldn't mind giving that topic a look. And if we are sending this follow up topic, then perhaps we could be consistent about *_get() only returning 0 or 1 in this series, and the follow up series could make all the functions ferry up the return code. This does introduce some churn, but the consistency will be a good property to have, especially if, in the follow up topic, we decide to do something else with the API.
