On Fri, Sep 27, 2024 at 11:31 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > The dependency to "strbuf" (just as an example) was added initially > > fairly early. Soon after 27f7ed2a (reftable: add LICENSE, > > 2021-10-07) added the reftable/ hierarchy, e303bf22 (reftable: > > (de)serialization for the polymorphic record type., 2021-10-07). I For historical understanding, these commits are meaningless because they were a bulk import. You should look at https://github.com/hanwen/reftable instead. > > somehow had an impression that reftable "library" started without > > any Git dependency and then use of our helper functions seemed > > through from the shim layer, but it was pretty much part of the > > library from day one, it seems. > > I think the history goes a bit different. Initially, the reftable > library was developed completely outside of the Git tree in [1]. It did > not have any external dependencies and didn't use any of the Git code. Correct. strbuf was originally called 'slice', because it was a direct translation of the []byte type in Go. I renamed it to avoid offending the sensibilities of Git reviewers. See here https://github.com/hanwen/reftable/commit/06d9728b4fedb9ed996ac1ae48343e3879114e1b . It was a change that made me a little sad, because the strbuf type only works with explicit initialization (STRBUF_INIT), which means that every struct that transitively includes a strbuf must now have a XXX_INIT macro. It just required 12 strbuf functions, but I suppose more have crept in over time. > The difference here is roughly 100 to 200 lines of code, which I don't > think is much of a maintenance burden by itself. In fact, we'll even I think Patrick's plan is sound. The amount of code to make reftable work both standalone and in Git is small. It just needs some discipline on both the Git and libgit2 side to not add additional dependencies. -- Han-Wen Nienhuys - hanwenn@xxxxxxxxx - http://www.xs4all.nl/~hanwen
