git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'Elijah Newren'" <newren@gmail.com>
Cc: "'Taylor Blau'" <me@ttaylorr.com>,
	"'Junio C Hamano'" <gitster@pobox.com>,
	"'Dragan Simic'" <dsimic@manjaro.org>, <git@vger.kernel.org>
Subject: RE: [DISCUSS] Introducing Rust into the Git project
Date: Thu, 11 Jan 2024 08:07:35 -0500	[thread overview]
Message-ID: <012801da448f$29434ee0$7bc9eca0$@nexbridge.com> (raw)
In-Reply-To: <CABPp-BGmXw0NQ8yBaMiVXHiKr0-Y_jkZWmJB1CG_oc4UGxt_gA@mail.gmail.com>

On Thursday, January 11, 2024 12:06 AM, Elijah Newren wrote:
>On Wed, Jan 10, 2024 at 6:57 PM <rsbecker@nexbridge.com> wrote:
>>
>> On Wednesday, January 10, 2024 9:21 PM, Elijah Newren wrote:
>> >On Wed, Jan 10, 2024 at 5:44 PM <rsbecker@nexbridge.com> wrote:
>> >>
>> >> On Wednesday, January 10, 2024 7:59 PM, Elijah Newren wrote:
>> >[...]
>> >> >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.


  parent reply	other threads:[~2024-01-11 13:07 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10 20:16 [DISCUSS] Introducing Rust into the Git project Taylor Blau
2024-01-10 21:57 ` Dragan Simic
2024-01-10 22:11   ` Junio C Hamano
2024-01-10 22:15     ` rsbecker
2024-01-10 22:26       ` Taylor Blau
2024-01-10 23:52         ` rsbecker
2024-01-11  0:59           ` Elijah Newren
2024-01-11  1:44             ` rsbecker
2024-01-11  2:21               ` Elijah Newren
2024-01-11  2:57                 ` rsbecker
2024-01-11  5:06                   ` Elijah Newren
2024-01-11  6:56                     ` Patrick Steinhardt
2024-01-11 13:07                     ` rsbecker [this message]
2024-01-11  2:55           ` brian m. carlson
2024-01-11  3:24             ` rsbecker
2024-01-11 20:07               ` Trevor Gross
2024-01-11 21:28                 ` rsbecker
2024-01-11 23:23                   ` Trevor Gross
2024-01-22 23:17           ` Defining a platform support policy (Was: [DISCUSS] Introducing Rust into the Git project) Emily Shaffer
2024-01-23  0:11             ` rsbecker
2024-01-23  0:57               ` Defining a platform support policy Junio C Hamano
2024-01-23  0:31             ` Junio C Hamano
2024-01-24  7:54             ` Defining a platform support policy (Was: [DISCUSS] Introducing Rust into the Git project) Elijah Newren
2024-01-10 23:40     ` [DISCUSS] Introducing Rust into the Git project brian m. carlson
2024-01-11  0:33   ` Elijah Newren
2024-01-11  5:39     ` Dragan Simic
2024-01-11 16:57       ` Elijah Newren
2024-01-17 21:30         ` Dragan Simic
2024-01-24  4:15           ` Elijah Newren
2024-01-24  5:14             ` Dragan Simic
2024-01-11  0:12 ` Elijah Newren
2024-01-11  5:33   ` Dragan Simic
2024-01-11  1:56 ` brian m. carlson
2024-01-11 11:45 ` Sam James
2024-01-11 23:48   ` brian m. carlson
2024-01-12  8:24     ` Sam James
2024-01-12 14:46       ` Antoni Boucher
2024-01-11 23:53 ` Trevor Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='012801da448f$29434ee0$7bc9eca0$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).