Re: [PATCH v3 3/6] libgit-sys: add repo initialization and config access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024.10.07 14:21, Josh Steadmon wrote:
> On 2024.09.10 08:42, Patrick Steinhardt wrote:
> > I don't quite get why we expose functionality that is inherently not
> > libified. Exposing the current state to library users certainly does not
> > feel right to me, doubly so because `the_repository` is deprecated and
> > will eventually go away. So we already know that we'll have to break the
> > API here once that has happened. I'd rather want to see that introducing
> > the library makes us double down on providing properly encapsulated
> > interfaces from hereon.
> > 
> > Also, we already have ways to initialize a repository and read their
> > config without relying on `the_repository`. So shouldn't we expose that
> > instead?
> > 
> > Patrick
> 
> Specifically in this case, yeah, we should have started with the
> libified version. This is an artifact due to the way we are figuring out
> C/Rust interop as we go, and it was easier to convert it this way
> without making the Rust side care about handling repository pointers.
> But you're right, and I'll fix this soon for V4.
> 
> In general though, we're treating the initial version of libgit-rs as a
> proof-of-concept that we can call from JJ into Git without blowing
> things up. We might not always have the option of exposing
> fully-libified code paths, and for our $DAYJOB purposes, we may have to
> deal with non-ideal interfaces for the early versions. However, we do
> want to use this as a way to motivate development of better, libified
> APIs when we find real-world use cases for them.
> 
> We've said before (even before we started libgit-rs) that we're not
> going to be able to make guarantees about early libified APIs, because
> we're learning as we go along. I don't want to use that as an excuse to
> cover up bad design, but I do want to be upfront that we can't commit to
> fully libifying any given code path before we expose it through the shim
> library or through libgit-rs.

In fact, since the JJ proof-of-concept doesn't rely on repository
initialization or repository-level config access, I think we can just
drop this patch for now and worry about getting a better interface for
repo initialization later.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux