4 ms·

I’m all for memory safety and such but honestly what’s the use case for this? Showing off agentic development? In 10+ years git has never failed on a memory ove

I’m all for memory safety and such but honestly what’s the use case for this? Showing off agentic development? In 10+ years git has never failed on a memory overflow or else. Sometimes software is “good as is” and I’m pretty confident git classifies as such. I’ve also never really hit the limitations of git, even with teams of 20+ developers and lots of binary artefacts. You got to really stretch git limitations, in which case you might need to move away from git, and a rust rewrite will not help in any way whatsoever. So again … why?

absintini 4mo ago
[flagged]
- galangalalgol 4mo ago
  When we go a full year without a lpe in the linux kernel I'll start considering it...
  - NekkoDroid 4mo ago
    How many of the LPE would rust even fix? They mostly seem logical errors and not memory or threading related race conditions to me.
    - galangalalgol 4mo ago
      This year, none of them. Historically most or all. So that is another caveat. If all future lpe are logic errors I'd start reconsidering the value proposition. I do actually like writing rust though. I don't feel like it slows me down. I also love the simplicity of c vim and gdb, though my first exposure was lattice on the amiga 1000. I wonder if strict typing makes it take fewer tokens to find bugs?
  - absintini 4mo ago
    I mean we’re almost there with Mythos/Fable so there ya go. In two years bye bye rust.
    - galangalalgol 4mo ago
      Did you create this account just to lament rust hype? I mean, it is excessive. But I also don't think it is manufactured. We are more like some mostly benign evangelical denomination trying to get everyone to see the joys of Ferris.
      - absintini 4mo ago
        Honestly, if the language actually looked nicer, great. But I mean the source code looks like a steaming pile of crate-includes. We can do better, seriously.
        galangalalgol 4mo ago
        You have touched on my biggest complaint, the supply chain depth. It has definite advantages, but a signed and vetted set of crates is sorely needed. I could always just write everything my self like I would in c, but the crates are right there...
WD-42 4mo ago
License washing
- jraph 4mo ago
  "Grift" (The f is for "feft")
schacon 4mo ago
I addressed this in the post, but Git has no linkable library and never has. If you want to do even something small, you need to fork/exec a process and communicate with it via stdin/out. Or completely reimplement it and all of the edge cases - for example, reading even one object can be either loose (easy) or in a packfile (much more difficult). Reading a reference (what SHA does a branch point to) can be in a loose file, a packfile, or a reftable. etc. There is no way anyone would ever use this for it's CLI - it will almost certainly always be slower and worse in every way, even if I get it stable (which it's currently not). You can use libgit2 (a project I also helped kickstart), or Gitoxide (a project GitButler also currently helps drive) - they are faster and better in nearly every way, but they are not feature complete. This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.
- eminence32 4mo ago
  But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
  - llimllib 4mo ago
    the author of this post (whom you were responding to) made `libgit`, the library that preceded `libgit2`, and contributed to libgit2 a long time ago as well. Here he is in 2010 writing about libgit2: https://github.blog/news-insights/libgit2-a-git-linkable-library/ https://github.blog/news-insights/libgit2-a-git-linkable-lib...
    - schacon 4mo ago
      To be clear, I 100% did not make libgit. I did help the libgit2 project get off the ground.
- gritzko 4mo ago
  Nice experiment, but a bit expensive. I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more. But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code. Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming. May look differently from your vantage point though. [1]: https://github.com/gritzko/beagle https://github.com/gritzko/beagle [2]: https://replicated.wiki/blog/abc https://replicated.wiki/blog/abc
well_ackshually 4mo ago
How else could they launder the git license and set themselves up for a bait and switch later down the line?

absintini 4mo ago

[flagged]

galangalalgol 4mo ago
When we go a full year without a lpe in the linux kernel I'll start considering it...
- NekkoDroid 4mo ago
  How many of the LPE would rust even fix? They mostly seem logical errors and not memory or threading related race conditions to me.
  - galangalalgol 4mo ago
    This year, none of them. Historically most or all. So that is another caveat. If all future lpe are logic errors I'd start reconsidering the value proposition. I do actually like writing rust though. I don't feel like it slows me down. I also love the simplicity of c vim and gdb, though my first exposure was lattice on the amiga 1000. I wonder if strict typing makes it take fewer tokens to find bugs?
- absintini 4mo ago
  I mean we’re almost there with Mythos/Fable so there ya go. In two years bye bye rust.
  - galangalalgol 4mo ago
    Did you create this account just to lament rust hype? I mean, it is excessive. But I also don't think it is manufactured. We are more like some mostly benign evangelical denomination trying to get everyone to see the joys of Ferris.
    - absintini 4mo ago
      Honestly, if the language actually looked nicer, great. But I mean the source code looks like a steaming pile of crate-includes. We can do better, seriously.
      - galangalalgol 4mo ago
        You have touched on my biggest complaint, the supply chain depth. It has definite advantages, but a signed and vetted set of crates is sorely needed. I could always just write everything my self like I would in c, but the crates are right there...

WD-42 4mo ago

License washing

jraph 4mo ago
"Grift" (The f is for "feft")

schacon 4mo ago

I addressed this in the post, but Git has no linkable library and never has. If you want to do even something small, you need to fork/exec a process and communicate with it via stdin/out. Or completely reimplement it and all of the edge cases - for example, reading even one object can be either loose (easy) or in a packfile (much more difficult). Reading a reference (what SHA does a branch point to) can be in a loose file, a packfile, or a reftable. etc. There is no way anyone would ever use this for it's CLI - it will almost certainly always be slower and worse in every way, even if I get it stable (which it's currently not). You can use libgit2 (a project I also helped kickstart), or Gitoxide (a project GitButler also currently helps drive) - they are faster and better in nearly every way, but they are not feature complete. This isn't for the person using Git. This is for someone trying to build a tool that wants to use parts of Git, which is different.

eminence32 4mo ago
But libgit2 exists, right? It may not have 100% feature parity with git, but that's a linkable library that gives you a lot of functionality when working with git repos.
- llimllib 4mo ago
  the author of this post (whom you were responding to) made `libgit`, the library that preceded `libgit2`, and contributed to libgit2 a long time ago as well. Here he is in 2010 writing about libgit2: https://github.blog/news-insights/libgit2-a-git-linkable-library/ https://github.blog/news-insights/libgit2-a-git-linkable-lib...
  - schacon 4mo ago
    To be clear, I 100% did not make libgit. I did help the libgit2 project get off the ground.
gritzko 4mo ago
Nice experiment, but a bit expensive. I work on Beagle, a git-compatible SCM [1]. I use ABC, Abstractionless C [2] dialect with slices, optional range checking, etc. So far, memory safety was the least of my concerns, frankly. Most of the thorny issues would be equally thorny in Rust (e.g. right now: reflog zeroed when VM ran out of disk space; must be some state machine issue or an OS level glitch). Also, forking off a C process (no runtime) is cheap enough that you actually want to do that more. But, those are all technicalities. The key issue I see with the approach: the data structures and algos of git have been fanatically fine tuned for that particular application with those particular usage patterns. By very sophisticated low-level C programmers. So, quite likely, any other app/lib working with that store will always be a suboptimal fit. I would recommend read-only access only, esp for LLM code. Meanwhile, git's underlying data model (blobs/trees/commits) is very simple and very much internet-standard level. Decoupling at that interface is so much easier with so much less issues looming. May look differently from your vantage point though. [1]: https://github.com/gritzko/beagle https://github.com/gritzko/beagle [2]: https://replicated.wiki/blog/abc https://replicated.wiki/blog/abc

well_ackshually 4mo ago

How else could they launder the git license and set themselves up for a bait and switch later down the line?