Re: Proposal/Discussion: Turning parts of Git into libraries
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 17, 2023, 22:57 UTC
- Message-ID
- <xmqq3573lx2d.fsf@gitster.g>
- In-Reply-To
- <CAJoAoZ=Cig_kLocxKGax31sU7Xe4==BGzC__Bg2_pr7krNq6MA@mail.gmail.com>
Emily Shaffer <nasamuffin@google.com> writes:
Show 7 quoted lines
> Basically, if this effort turns out not to be fruitful as a whole, I'd > like for us to still have left a positive impact on the codebase. > ... > So what's next? Naturally, I'm looking forward to a spirited > discussion about this topic - I'd like to know which concerns haven't > been addressed and figure out whether we can find a way around them, > and generally build awareness of this effort with the community.
On of the gravest concerns is that the devil is in the details.
For example, "die() is inconvenient to callers, let's propagate errors up the callchain" is an easy thing to say, but it would take much more than "let's propagate errors up" to libify something like check_connected() to do the same thing without spawning a separate process that is expected to exit with failure.
It is not clear if we can start small, work on a subset of the things and still reap the benefit of libification. Is there an existing example that we have successfully modularlized the API into one subsystem? Offhand, I suspect that the refs API with its two implementations may be reasonably close, but is the inteface into that subsystem the granularity of the library interface you guys have in mind?