Re: Proposal/Discussion: Turning parts of Git into libraries

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 22, 2023, 00:22 UTC
Message-ID: <xmqqk00aczwj.fsf@gitster.g>
In-Reply-To: <CAJoAoZn7Nt37Eh17dpLDK+YX2BaEaAaii2rJPXO3L0BmQQkcgQ@mail.gmail.com>

Emily Shaffer <nasamuffin@google.com> writes:

Show 8 quoted lines

>> 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.
>
> Because the error propagation path is complicated, you mean? Or
> because the cleanup is painful?

Both.

The amount of data the caller may want to learn about an error may not be uneven, depending on the caller even for a single function. And yes, cleaning up of shared resources like object flag bits after a traversal, especially a failed one, would be very painful unless the processing is designed from day one to allow it (and the revision traversal codepath is not).

> ... is it reasonable to consider, for example, further
> cleanup of cache.h as part of this effort? Is it reasonable to rework
> an ugly circular dependency between two headers as a prerequisite to
> doing library work around one of them?

I am not sure about which two headers you are talking about, but if there is circular dependency that can be untangled, it would be a reasonable preliminary clean-up work. I am not sure if that is "prerequisite"---it is up to folks who want to design how the "libification" work goes.