121–130 of 433 posts
Feel like there’s a ton of interesting things ahead for SCM — want to see more of those proposals. For example…had to build my own tool to extend git blame and track the AI generated code in our repository and save prompts: https://github.com/acunniffe/git-ai
Earlier quoted context omitted.
There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/
At this point maybe it's time to let them solve the problem they've created for themselves by insisting on a closed C compiler in 2025.
It seems unwise, to me, to tie the life of a project as fundamental, and conceptually simple, as git to a compiler and runtime as complicated as rust. The beauty of the unsafety of C is partially that it's pretty easy to spin up a compiler on a new platform. The same cannot be said of Rust.
One argument from the git devs is that it’s very hard to implement smarter algorithms in C, though. For example, it uses arrays in places where a higher level language would use a hash, because the C version of that is harder to write, maintain, and debug. It’s also much easier to write correct threaded code in Rust than C. Between those 2 alone, using a more robust language could make it straightforward to add perfo…
In my opinion, the verification of the implementation should be separate from the task of translating that implementation to bytecode. This leaves you with a simple compiler that is easy to implement but still with a strong verifier that is harder to implement, but optional.
Earlier quoted context omitted.
There's at least one proprietary platform that supports Git built by via a vendor-provided C compiler, but for which no public documentation exists and therefore no LLVM support is possible. Ctrl+F for "NonStop" in https://lwn.net/Articles/998115/
How is this git's concern?
Earlier quoted context omitted.
> I'm just old and moany, and I need to step aside for bigger and better things such as Rust. You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. In any case Rust is usually easier than C (excluding buggy C which is very easy to write), and certainly easier than actually learning the Git or Linux codebases.
> You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. It's viable, but limiting. Sometimes you have to do things you don't want to, which is why it's called work. But if you can choose what platforms you work on, you can orient towards things where things change less, and then you don't need to learn new things as often. Chances are, if you get i…
Earlier quoted context omitted.
because the rust compiler just doesn't support some platforms (os / architecture combination)? RESF members tend to say it the other way around as in the platform doesn't support rust, but the reality is that it's the compiler that needs to support a platform, not the other way around.
Rust can't support a platform when that platform's vendors just provide a proprietary C compiler and nothing else (no LLVM, no GCC). Perhaps someone could reverse-engineer it, but ultimately a platform with zero support from any FOSS toolchain is unlikely to get Rust support anytime soon.
Our source control, editing, compilation, and execution was understood to happen in different computational spaces, with possible copy/staging steps in between. You were doing something very naive if you assumed you could execute the built program on the same system where the sourcecode files existed and the editor/IDE was running.
This was a significant fraction of the build rules we used to manage. E.g. configuration steps had to understand that the target platform being measured/characterized is not the same as the platform executing the build tools. And to actually execute a built object may require remote file copies and remote program invocation.
Earlier quoted context omitted.
I did check this out. The shell, perl and python are likely for scripting and not used during runtime. TCL is likely some form of dynamic scripting. I think we also have to be honest about what the project here is too, it's not to have both C and Rust together, but to replace all C with Rust. In which case, it probably makes sense to just clone to repo and work on a fork like they did with SSH.
> The shell, perl and python are likely for scripting and not used during runtime. Some git subcommands are implemented in these. git filter-branch is a shell script, git cvsimport is a Perl script, and git p4 (perforce interop) is a Python script. There are not too many left these days (git add -p/-i also used to call a Perl script), but they exist.
Now it would seem the logic is reversed; even though there are less Rust devs than C devs, Rust is going to replace C. Maybe now that git is large enough and entrenched enough such a move can be forced through.
[flagged]
"Normal users" would just install the same way they already do today without bothering about the toolchain.
"Normal users" who want to build by theirselves probably won't find it too difficult. Given the size of Git it's incredibly easy to build: just install the dependencies and run `make`.