git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Emily Shaffer <nasamuffin@google.com>
Date
Feb 17, 2023, 22:49 UTC
Message-ID
<CAJoAoZkMR9Acy7thVs-_e=Fz8wwjoDGDKb46wmwn8yxk0ODGow@mail.gmail.com>
In-Reply-To
<Y/ACqlhtLMjfgJFQ@tapette.crustytoothpaste.net>

On Fri, Feb 17, 2023 at 2:41 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 21 quoted lines
>
> On 2023-02-17 at 21:38:34, Emily Shaffer wrote:
> > For example, I seem to remember you saying during the SHA-256 series
> > that the next hashing algorithm would also be painful to implement;
> > would that still be true if the hashing algorithm is encapsulated well
> > by a library interface? Or is it for a different reason?
>
> Right now, most of the code for a future hash algorithm wouldn't be too
> difficult to implement, I'd think, because we can already support two of
> them.  If we decide, say, to implement SHA-3-512, we basically just add
> that algorithm, update all the entries in the tests (which is kind of a
> pain since there's a lot of them, but not really difficult), and then
> move on with our lives.
>
> The difficulty is dealing with interop work, which is basically
> switching from dealing with just one algorithm to rewriting things
> between the two on the fly.  I think _that_ work would be made easier by
> library work because sometimes it involves working with submodules, such
> as when updating the submodule commit, and being able to deal with both
> object stores more easily at the same time would be very helpful in that
> regard.
Ooh, I see what you mean. Thanks for the extra context here.
Show 13 quoted lines
> I can imagine there are other things that would be easier as well, and I
> can also imagine that we'll have better control over memory allocations
> and leak less, which would be nice.  If we can get leaks low enough, we
> could even add CI jobs to catch them and fail, which I think would be
> super valuable, especially since I find even after over two decades of C
> that I'm still not very good about catching all the leaks (which is one
> of the reasons I've mostly switched to Rust).  We might also be able to
> make nicer steps on multithreading our code as well.
>
> Personally, I'd like to see some sort of standard error type (whether
> integral or not) that would let us do more bubbling up of errors and
> less die().  I don't know if that's in the cards, but I thought I'd
> suggest it in case other folks are interested.

Yes!!! We have talked about this a lot internally - but this is one thing that will be difficult to introduce into Git without making parts of the codebase a little uglier. Since obviously C doesn't have an intrinsic to do this, we'll have to roll our own, which means that manipulating it consistently at function exits might end up pretty ugly. So hearing that there's interest outside of my team to come up with such a type makes me optimistic that we can figure out a neat-enough solution.

> --
> brian m. carlson (he/him or they/them)
> Toronto, Ontario, CA
Previous: brian m. carlsonNext: Jeff King
Message 5 of 37 in “Proposal/Discussion: Turning parts of Git into libraries”
  1. Emily ShafferFeb 17, 2023
  2. brian m. carlsonFeb 17, 2023
  3. Emily ShafferFeb 17, 2023
  4. brian m. carlsonFeb 17, 2023
  5. Emily ShafferFeb 17, 2023
  6. Jeff KingFeb 22, 2023
  7. Emily ShafferFeb 24, 2023
  8. Jeff KingFeb 24, 2023
  9. Junio C HamanoFeb 24, 2023
  10. rsbecker@nexbridge.comFeb 17, 2023
  11. brian m. carlsonFeb 17, 2023
  12. Junio C HamanoFeb 17, 2023
  13. demerphqFeb 18, 2023
  14. Phillip WoodFeb 18, 2023
  15. Felipe ContrerasMar 23, 2023
  16. rsbecker@nexbridge.comMar 23, 2023
  17. Felipe ContrerasMar 23, 2023
  18. rsbecker@nexbridge.comMar 23, 2023
  19. Felipe ContrerasMar 23, 2023
  20. rsbecker@nexbridge.comMar 24, 2023
  21. Felipe ContrerasMar 24, 2023
  22. rsbecker@nexbridge.comMar 24, 2023
  23. Felipe ContrerasMar 24, 2023
  24. Emily ShafferFeb 21, 2023
  25. Junio C HamanoFeb 22, 2023
  26. Elijah NewrenFeb 18, 2023
  27. Emily ShafferFeb 21, 2023
  28. Elijah NewrenFeb 22, 2023
  29. Jeff KingFeb 22, 2023
  30. Taylor BlauFeb 21, 2023
  31. Emily ShafferFeb 21, 2023
  32. Victoria DyeFeb 22, 2023
  33. Jonathan TanFeb 25, 2023
  34. Derrick StoleeFeb 22, 2023
  35. Emily ShafferFeb 24, 2023
  36. Felipe ContrerasMar 23, 2023
  37. rsbecker@nexbridge.comMar 23, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.