Rendered at 04:20:45 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
eviks 38 minutes ago [-]
> It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism,
Good, are there (m)any other plans to ditch the slow files and use proper database? Or is it only reserved for various post-git competitors?
112233 17 minutes ago [-]
By "proper" I assume you mean relational? Or ACID? Or you mean using existing database software? What is so improper about the way git stores data?
KolmogorovComp 4 hours ago [-]
Does it mean that when switching trop sha1 to sha256 you need to forcepush and rewrite all history? Wouldn’t that be a massive source of potential vulnerabilities?
nextaccountic 10 minutes ago [-]
That's odd. Why not compute both sha1 and sha256 for all git objects for the foreseeable future?
Failing that, have a kind of git object that wraps another and says hey this is in sha1 don't mess with it
infogulch 1 hours ago [-]
Couldn't you write something that checks every commit's content and message is byte equal to the old tree? One scan through the history to verify it should be relatively simple if not cheap. Should be built into git.
em-bee 3 hours ago [-]
i guess that for now only the default will change for new repositories. support for sha1 is not going to be dropped, so most existing repositories won't switch any time soon. if you want to switch then yes, it sounds like a force push might be needed, although it could also be that simply switching is not possible, but that instead you have to create a new repo and import the history from the old repo, forcing everyone to clone the new repo intentionally.
nomel 4 hours ago [-]
I don't know much about this. How does that enable vulnerabilities exactly?
jayd16 4 hours ago [-]
Trusting a forced push w/o any other verification means nefarious history changes can be slipped in.
You can still verify the contents - the content blobs don’t change after the migration. Not sure if there’s a practical attack one could do but maybe
WCSTombs 4 hours ago [-]
`git add --resolved` is a wonderful idea, and definitely something I would start using.
drgo 3 hours ago [-]
[flagged]
coliveira 1 hours ago [-]
It is regrettable that they're trying to coerce the use of Rust everywhere just for the sake of it. It's a nonsense that is now forced on everyone.
epidemian 22 minutes ago [-]
Of the codebases i know that have adopted Rust, it has always been because some of their maintainers wanted to do so.
Maybe git's case is different though. Do you have more info about it? Are you a git maintainer who was coerced to use Rust, or do you know of such cases?
tombert 1 hours ago [-]
I don't think it's "just for the sake of it". I think they believe that the Rust code will be safer.
coliveira 59 minutes ago [-]
If that's the case, they should stop using git and Linux right now, because it's everything written in C. Having 0.1% of the code in a safe language will not change anything, it's only a bad security blanket.
aw1621107 41 minutes ago [-]
> Having 0.1% of the code in a safe language will not change anything, it's only a bad security blanket.
Just because something does provide an immediate perfect solution does not mean it isn't not worth investigating and/or pursuing.
Also consider that bugs tend to be more prevalent in new code (e.g., [0]) as a result, you are likely to see more of a benefit from writing new code in a memory-safe language than raw line count proportions would indicate.
You don't believe in slowly and iteratively improving a codebase over time? Should git stick with its weird mishmash of C and perl and shell scripts forever, for tradition's sake, performance and maintainability be damned?
I wouldn't agree with all of those reasons, but it's very definitely not "just for the sake of it." One of the better reasons so many people look to writing some things in Rust is that we now have pretty ample evidence than trying to write a binary file format parser in C is a cornucopia of CVEs that are just simply absent in Rust, and the excuse of "well, but a sufficiently smart programmer doesn't write bugs in C" doesn't cut it anymore.
coliveira 49 minutes ago [-]
Somehow we have binary file format parsers written in C everywhere, so the real world shows it is possible and we do have programmers capable of doing it.
jcranmer 40 minutes ago [-]
Sure, we can write a binary file format parser in C. We just can't figure out how to write one that isn't buggy and lets someone infect your computer if you give it sufficiently inventive garbage.
eviks 34 minutes ago [-]
The issue isn't whether it's possible to have parsers, but whether it's possible to have them be secure, and periodic CVEs "everywhere" suggest we don't
cxr 21 minutes ago [-]
Aside from memory safety, which is solved by using a compiler that just doesn't allow unsafe memory operations (so not GCC or Clang upstream), which CVEs specifically would have been ameliorated by a parser written in Rust instead of C?
Good, are there (m)any other plans to ditch the slow files and use proper database? Or is it only reserved for various post-git competitors?
Failing that, have a kind of git object that wraps another and says hey this is in sha1 don't mess with it
Maybe git's case is different though. Do you have more info about it? Are you a git maintainer who was coerced to use Rust, or do you know of such cases?
Just because something does provide an immediate perfect solution does not mean it isn't not worth investigating and/or pursuing.
Also consider that bugs tend to be more prevalent in new code (e.g., [0]) as a result, you are likely to see more of a benefit from writing new code in a memory-safe language than raw line count proportions would indicate.
[0]: https://security.googleblog.com/2024/09/eliminating-memory-s...
I wouldn't agree with all of those reasons, but it's very definitely not "just for the sake of it." One of the better reasons so many people look to writing some things in Rust is that we now have pretty ample evidence than trying to write a binary file format parser in C is a cornucopia of CVEs that are just simply absent in Rust, and the excuse of "well, but a sufficiently smart programmer doesn't write bugs in C" doesn't cut it anymore.