Thread (20 messages) 20 messages, 8 authors, 2024-01-24

RE: [DISCUSS] Introducing Rust into the Git project

From: <hidden>
Date: 2024-01-11 13:07:51

On Thursday, January 11, 2024 12:06 AM, Elijah Newren wrote:
On Wed, Jan 10, 2024 at 6:57 PM [off-list ref] wrote:
quoted
On Wednesday, January 10, 2024 9:21 PM, Elijah Newren wrote:
quoted
On Wed, Jan 10, 2024 at 5:44 PM [off-list ref] wrote:
quoted
On Wednesday, January 10, 2024 7:59 PM, Elijah Newren wrote:
[...]
quoted
quoted
Would you be okay with the following alternative: requiring that
all Rust code be optional for now?

(In other words, allow you to build with USE_RUST=0, or something
like that.  And then we have both a Rust and a C implementation of
anything that is required for backward compatibility, while any
new Rust-only stuff would not be included in your build.)
To address the immediate above, I assume this means that platform
maintainers will be responsible for developing non-portable
implementations that duplicate Rust functionality
This doesn't at all sound like what I thought I said.  The whole
proposal was so that folks like NonStop could continue using Git with
no more work than setting
USE_RUST=0 at build time.

Why do you feel you'd need to duplicate any functionality?
I think I misunderstood. What I took from this is that all new functionality would
be in Rust, which would require a custom implementation in C for platforms that did
not have Rust available - if that is even practical. Did I get that wrong?

I think you somehow missed the word optional?

I did say that new functionality should be allowed to be Rust only (unlike existing
functionality), but I'm not sure how you leaped to assuming that all new
functionality would be in Rust.  Further, I also don't understand why you jump to
assuming that all new functionality needs to be supported on all platforms.  The
point of the word "optional" in my proposal is that it is not required.  So, say, if git-
replay is in Rust, well you've never had git-replay before in any release, so you
haven't lost any functionality by it being implemented in Rust.  And existing things
(merge, cherry-pick, rebase, etc.) continue working with C-only code.  But you may
have one less optional addition.

At least that was _my_ proposal -- that Rust be optional for now.  It does differ from
what I think Taylor was originally proposing, but that's why I brought it up as an
alternative proposal.
Thank you for the clarification.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help