281–290 of 433 posts
Earlier quoted context omitted.
I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.
Who says you do not? :)
Earlier quoted context omitted.
I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.
(There is a persistent idea that the lack of memory safety in C is good because it allows people to jailbreak their phones.)
Earlier quoted context omitted.
That would be a stronger argument if people were facing implementation deficiencies in git
I'm not sure exactly what you mean but of course people are facing implementation deficiencies in Git. Last I checked submodules were still "experimental" and extremely buggy, and don't work at all with worktrees. (And yeah submodules suck but sometimes I don't have a choice.)
Earlier quoted context omitted.
>> insisting on a closed C compiler in 2025. > Everything should use one compiler, one run-time and one package manager. If you think that calling out closed C compilers is somehow an argument for a single toolchain for all things, I doubt there's anything I can do to help educate you about why this isn't the case. If you do understand and are choosing to purposely misinterpret what I said, there are a lot of much st…
For various libs, you provide a way to build without it. If it's not auto-detected, or explicitly disabled via the configure command line, then don't try to use it. Then whatever depends on it just doesn't work. If for some insane reason git integrates XML and uses libxml for some feature, let it build without the feature for someone who doesn't want to provide libxml. > At the end of the day, there's a finite amount…
As cited elsewhere in the this thread, the person making this proposal on the mailing list has been involved in significant contributions to git in the past, so I'd be inclined to trust their judgment about whether it's a worthwhile use of their time in the absence of evidence to the contrary. If you have something that would indicate this proposal was made in bad faith, I'd certainly be interested to see it, but otherwise, I don't see how you can make this claim other than as your own subjective opinion. That's fine, but I can't say I'm shocked that the people actually making the decisions on how to maintain git don't find it convincing.
Earlier quoted context omitted.
> Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. I'm yet to know a single software engineer who isn't well versed on multiple programming languages. This is not a problem.
Agreed. And if someone is interested in contributing to the Linux kernel, a new programming language is far from the hardest thing that they need to learn...
In C, you have to remember lots of rules of when what is safe and what locks to hold when. In Rust, APIs are structured to make unsafe use impossible without explicitly saying `unsafe`.
Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.
Earlier quoted context omitted.
They're proposing porting over one small piece that has no dependencies and exposing it to the rest of git via a C interface. Yes, they'll presumably port more over in the future if it goes well, but it's a gross exaggeration to characterize this as somehow making it impossible to contribute without knowing Rust.
I know that it is a "slippery slope" argument, but in the future, it will become more difficult to contribute without knowing Rust. That's the entire point of introducing it.
Earlier quoted context omitted.
Actually, the Rust toolchain makes cross-compiling way easier than any other fully-compiled language I've ever used. There are like 100 different platforms you can target by just setting the `--target` flag, and they all pretty much just work on any host platform. Sounds like the real issue is that some Git developers have ancient, rigid requirements for their own development machines.
That has not been my experience. I develop on Windows and need to compile for Linux. After spending several hours trying to get cross-compilation working, I gave up and do it via WSL now. I switched from Go and I feel like Go was much better at this than Rust. (I tried “cross” but it was very slow and I found it faster to rsync the files inside the container and then run the build scripts)
bruh what is that goofy ass capcha protection??