git is discussing on introducing Rust to the project

[NobodyXu]

https://lore.kernel.org/git/CALNs47s3tUQoOD4ejdoTn6y12ywjL0j5hWU-fUnBLe_o3vV5SQ@mail.gmail.com/T/

cc @Byron

[NobodyXu]

Seems that one of the showstoppers is the architecture support, which will require rustc_codegen_gcc

[NobodyXu]

There's also discussion of rustc_codegen_c in the zulip, which might help fixing not only the architecture support but also resolve the complaint that adding Rust makes git less portable and harder to compile on OSes without pre-builts.

[NobodyXu]

Seems like there's an arch called Nonstop which neither GCC nor LLVM supports but Git currently supports

[Byron]

Yes, NonStop showed up a lot, and this seems to be it according to Wikipedia.

[NobodyXu]

A completely proprietary stack, from hardware to software and doesn't even have gcc or llvm support, sounds like very hard to support.

However I do think it's possible to support with rustc_codegen_c, a new idea proposed in zulip https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/rustc_codegen_c

[Byron]

Thanks for sharing! I think gitoxide even got a mention.

From what I can tell, the main benefit of this happening would be that the code should become more readable over time. It seems like a giant undertaking as well and I feel lucky to have been able to start from scratch.

[NobodyXu]

It definitely yes, all the supoort of old targets is even harder, I think they can actually pull in your crate/code when rewriting code in Rust.

[Byron]

If I were them, I absolutely wouldn't even try to do that. After all, it's more like a C-to-Rust-librification that especially in the first stages has to be made for C ->Rust interop, probably with a share of Rust-> interop as well. It's so custom especially at first, I doubt gitoxide is of any use as a crate.
Trying to share code would probably slow both projects down as well.

[NobodyXu]

Thanks, that's something I didn't considered.