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

Re: [DISCUSS] Introducing Rust into the Git project

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jan 10, 2024, 23:40 UTC
Message-ID
<ZZ8q40OdPy0v-ZxQ@tapette.crustytoothpaste.net>
In-Reply-To
<xmqqjzog96uh.fsf@gitster.g>
On 2024-01-10 at 22:11:34, Junio C Hamano wrote:
Show 16 quoted lines
> A few obvious ones that come to my mind are that you should be able
> to write a new merge strategy and link the resulting binary into Git
> without much hassle.  You might even want to make that a dynamically
> loaded object.  The interface into a merge strategy is fairly narrow
> IIRC.  Or possibly a new remote helper.
> 
> Adding a new refs backend may need to wait for the work Patrick is
> doing to add reftable support, but once the abstraction gets to the
> point to sufficiently hide the differences between files and reftables
> backends, I do not see a reason why you cannot add the third one.
> 
> And more into the future, we might want to have an object DB
> abstraction, similar to how we abstracted refs API over time, at
> which time you might be writing code that stores objects to and
> retrieves objects from persistent redis and whatnot in your favorite
> language.

This is definitely a thing people will want to do. I think Microsoft had some code for Azure DevOps that stored their code in the cloud and the refs database in a real database. I can imagine that being a valuable set of features people would want to implement in a variety of environments, with all of the benefits of basing on upstream Git.

I also feel that I would absolutely not want to write those things in C. Rust is much more ergonomic when writing these things because freeing resources (freeing memory, rolling back transactions, closing files, etc.) becomes as easy as implementing the Drop trait and you write less boilerplate.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Previous: Elijah NewrenNext: Elijah Newren
Message 24 of 38 in “[DISCUSS] Introducing Rust into the Git project”
  1. Taylor BlauJan 10, 2024
  2. Dragan SimicJan 10, 2024
  3. Junio C HamanoJan 10, 2024
  4. rsbecker@nexbridge.comJan 10, 2024
  5. Taylor BlauJan 10, 2024
  6. rsbecker@nexbridge.comJan 10, 2024
  7. Elijah NewrenJan 11, 2024
  8. rsbecker@nexbridge.comJan 11, 2024
  9. Elijah NewrenJan 11, 2024
  10. rsbecker@nexbridge.comJan 11, 2024
  11. Elijah NewrenJan 11, 2024
  12. Patrick SteinhardtJan 11, 2024
  13. rsbecker@nexbridge.comJan 11, 2024
  14. brian m. carlsonJan 11, 2024
  15. rsbecker@nexbridge.comJan 11, 2024
  16. Trevor GrossJan 11, 2024
  17. rsbecker@nexbridge.comJan 11, 2024
  18. Trevor GrossJan 11, 2024
  19. Defining a platform support policy (Was: [DISCUSS] Introducing Rust into the Git project)Emily Shaffer, Jan 22, 2024
  20. rsbecker@nexbridge.comJan 23, 2024
  21. Junio C HamanoJan 23, 2024
  22. Junio C HamanoJan 23, 2024
  23. Elijah NewrenJan 24, 2024
  24. brian m. carlsonJan 10, 2024
  25. Elijah NewrenJan 11, 2024
  26. Dragan SimicJan 11, 2024
  27. Elijah NewrenJan 11, 2024
  28. Dragan SimicJan 17, 2024
  29. Elijah NewrenJan 24, 2024
  30. Dragan SimicJan 24, 2024
  31. Elijah NewrenJan 11, 2024
  32. Dragan SimicJan 11, 2024
  33. brian m. carlsonJan 11, 2024
  34. Sam JamesJan 11, 2024
  35. brian m. carlsonJan 11, 2024
  36. Sam JamesJan 12, 2024
  37. Antoni BoucherJan 12, 2024
  38. Trevor GrossJan 11, 2024

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.