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

From: Junio C Hamano <[email-masked]>
Date: Tue, 21 Feb 2023 16:22:20 -0800

Emily Shaffer <[email-masked]> writes:

>> 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.