* Re: [PATCH 00/10] Enrich Trailer API
From: Junio C Hamano @ 2024-01-10 19:45 UTC (permalink / raw)
To: Linus Arver via GitGitGadget
Cc: git, Emily Shaffer, Christian Couder, Linus Arver
In-Reply-To: <pull.1632.git.1704869487.gitgitgadget@gmail.com>
"Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:
> This patch series is the first 10 patches of a much larger series I've been
> working. The main goal of this series is to enrich the API in trailer.h. The
> larger series brings a number of additional code simplifications and
> cleanups (exposing and fixing some bugs along the way), and builds on top of
> this series. The goal of the larger series is to make the trailer interface
> ready for unit testing. By "trailer API" I mean those functions exposed in
> trailer.h.
Are there places in the current code that deals with trailers but
does not use the trailer API (e.g., manually parse and/or insert the
trailer in an in-core buffer)? Is it part of the larger goal to
update these places so that we will always use the trailer API to
touch trailers, and if so, have these places been identified?
Obviously the reason why I ask is that testing cannot be the goal by
itself. The "alternative" ...
> As an alternative to this patch series, we could keep trailer.h intact and
> decide to unit-test the existing "trailer_info_get()" function which does
> most of the trailer parsing work.
... may allow you to "test", but it would make it more difficult in
the future to revamp the trailer API, if it is needed, in order to
cover code paths that ought to be using but currently bypassing the
trailer API.
> This series breaks up "process_trailers()" into smaller pieces, exposing
> many of the parts relevant to trailer-related processing in trailer.h. This
> forces us to start writing unit tests for these now public functions, but
> that is a good thing because those same unit tests should be easy to write
> (due to their small(er) sizes), but also, because those unit tests will now
> ensure some degree of stability across new versions of trailer.h (we will
> start noticing when the behavior of any of these API functions change).
And helper functions, each of which does one small thing well, may
be more applicable to other code paths that are currently bypassing
the API.
> Thanks to the aggressive refactoring in this series, I've been able to
> identify and fix a couple bugs in our existing implementation. Those fixes
> build on top of this series but were not included here, in order to keep
> this series small.
It would be nicer to have a concise list of these fixes (in the form
of "git shortlog") as a teaser here ;-). That would hopefully
entice others into reviewing this part that forms the foundation.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/4] reftable/stack: refactor reloading to use file descriptor
From: Junio C Hamano @ 2024-01-10 19:57 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <726d302d7b21a5b948575492c717cfdb701de5cd.1704714575.git.ps@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> We're about to introduce a stat(3P)-based caching mechanism to reload
> the list of stacks only when it has changed. In order to avoid race
> conditions this requires us to have a file descriptor available that we
> can use to call fstat(3P) on.
>
> Prepare for this by converting the code to use `fd_read_lines()` so that
> we have the file descriptor readily available.
> ---
Missing sign-off.
Other than that, the change is a refactoring that is very faithful
to the original. Instead of doing the "open - pretend we opened an
empty file if it does not exist - read - close" dance all inside the
read_lines() call, this sort-of open codes the helper in this caller,
so that later steps of this series can look at the file descriptor
open to it.
Looking good.
> reftable/stack.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/reftable/stack.c b/reftable/stack.c
> index bf869a6772..b1ee247601 100644
> --- a/reftable/stack.c
> +++ b/reftable/stack.c
> @@ -308,6 +308,7 @@ static int reftable_stack_reload_maybe_reuse(struct reftable_stack *st,
> struct timeval deadline;
> int64_t delay = 0;
> int tries = 0, err;
> + int fd = -1;
>
> err = gettimeofday(&deadline, NULL);
> if (err < 0)
> @@ -329,9 +330,19 @@ static int reftable_stack_reload_maybe_reuse(struct reftable_stack *st,
> if (tries > 3 && tv_cmp(&now, &deadline) >= 0)
> goto out;
>
> - err = read_lines(st->list_file, &names);
> - if (err < 0)
> - goto out;
> + fd = open(st->list_file, O_RDONLY);
> + if (fd < 0) {
> + if (errno != ENOENT) {
> + err = REFTABLE_IO_ERROR;
> + goto out;
> + }
> +
> + names = reftable_calloc(sizeof(char *));
> + } else {
> + err = fd_read_lines(fd, &names);
> + if (err < 0)
> + goto out;
> + }
>
> err = reftable_stack_reload_once(st, names, reuse_open);
> if (!err)
> @@ -356,12 +367,16 @@ static int reftable_stack_reload_maybe_reuse(struct reftable_stack *st,
> names = NULL;
> free_names(names_after);
> names_after = NULL;
> + close(fd);
> + fd = -1;
>
> delay = delay + (delay * rand()) / RAND_MAX + 1;
> sleep_millisec(delay);
> }
>
> out:
> + if (fd >= 0)
> + close(fd);
> free_names(names);
> free_names(names_after);
> return err;
^ permalink raw reply
* Re: [PATCH 3/4] reftable/stack: use stat info to avoid re-reading stack list
From: Junio C Hamano @ 2024-01-10 20:07 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <4fabdc3d8016dbc1e20fbe90058ee7320a5f770b.1704714575.git.ps@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> We can do better and use the same stat(3P)-based mechanism that the
> "packed" backend uses. Instead of reading the file, we will only open
> the file descriptor, fstat(3P) it, and then compare the info against the
> cached value from the last time we have updated the stack. This should
> always work alright because "tables.list" is updated atomically via a
> rename, so even if the ctime or mtime wasn't granular enough to identify
> a change, at least the inode number should have changed.
Or the file size. Let's keep in mind that many users get useless
inum from their filesystem X-<.
> Summary
> update-ref: create many refs (refcount = 1, revision = HEAD~) ran
> 1.01 ± 0.09 times faster than update-ref: create many refs (refcount = 1, revision = HEAD)
> 2.72 ± 0.11 times faster than update-ref: create many refs (refcount = 100, revision = HEAD)
> 3.42 ± 0.13 times faster than update-ref: create many refs (refcount = 100, revision = HEAD~)
> 163.59 ± 5.62 times faster than update-ref: create many refs (refcount = 10000, revision = HEAD)
> 233.91 ± 7.92 times faster than update-ref: create many refs (refcount = 10000, revision = HEAD~)
> ---
Nice.
> @@ -374,6 +375,8 @@ static int reftable_stack_reload_maybe_reuse(struct reftable_stack *st,
> sleep_millisec(delay);
> }
>
> + stat_validity_update(&st->list_validity, fd);
> +
> out:
> if (fd >= 0)
> close(fd);
The stat_validity_update() does not happen in the error codepath.
Should we be clearing the validity of the list when somebody jumps
to "out:" due to an error? Or by the time this function gets
called, the caller would already have cleared the validity and an
error that jumps to "out:" keeps the list invalid?
Other than the missing sign-off, the change looks very straight-forward.
^ permalink raw reply
* [DISCUSS] Introducing Rust into the Git project
From: Taylor Blau @ 2024-01-10 20:16 UTC (permalink / raw)
To: git
Over the holiday break at the end of last year I spent some time
thinking on what it would take to introduce Rust into the Git project.
There is significant work underway to introduce Rust into the Linux
kernel (see [1], [2]). Among their stated goals, I think there are a few
which could be potentially relevant to the Git project:
- Lower risk of memory safety bugs, data races, memory leaks, etc.
thanks to the language's safety guarantees.
- Easier to gain confidence when refactoring or introducing new code
in Rust (assuming little to no use of the language's `unsafe`
feature).
- Contributing to Git becomes easier and accessible to a broader group
of programmers by relying on a more modern language.
Given the allure of these benefits, I think it's at least worth
considering and discussing how Rust might make its way into Junio's
tree.
I imagine that the transition state would involve some parts of the
project being built in C and calling into Rust code via FFI (and perhaps
vice-versa, with Rust code calling back into the existing C codebase).
Luckily for us, Rust's FFI provides a zero-cost abstraction [3], meaning
there is no performance impact when calling code from one language in
the other.
Some open questions from me, at least to get the discussion going are:
1. Platform support. The Rust compiler (rustc) does not enjoy the same
widespread availability that C compilers do. For instance, I
suspect that NonStop, AIX, Solaris, among others may not be
supported.
One possible alternative is to have those platforms use a Rust
front-end for a compiler that they do support. The gccrs [4]
project would allow us to compile Rust anywhere where GCC is
available. The rustc_codegen_gcc [5] project uses GCC's libgccjit
API to target GCC from rustc itself.
2. Migration. What parts of Git are easiest to convert to Rust? My
hunch is that the answer is any stand-alone libraries, like
strbuf.h. I'm not sure how we should identify these, though, and in
what order we would want to move them over.
3. Interaction with the lib-ification effort. There is lots of work
going on in an effort to lib-ify much of the Git codebase done by
Google. I'm not sure how this would interact with that effort, but
we should make sure that one isn't a blocker for the other.
I'm curious to hear what others think about this. I think that this
would be an exciting and worthwhile direction for the project. Let's
see!
Thanks,
Taylor
[1]: https://rust-for-linux.com/
[2]: https://lore.kernel.org/rust-for-linux/20210414184604.23473-1-ojeda@kernel.org/
[3]: https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#c-talking-to-rust
[4]: https://github.com/Rust-GCC/gccrs
[5]: https://github.com/rust-lang/rustc_codegen_gcc
^ permalink raw reply
* Re: [PATCH 4/4] reftable/blocksource: use mmap to read tables
From: Junio C Hamano @ 2024-01-10 21:24 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <a23f38a80609a5c5a6931400ffd28a92b33838bb.1704714575.git.ps@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> Using mmap comes with a significant drawback on Windows though, because
> mmapped files cannot be deleted and neither is it possible to rename
> files onto an mmapped file. But for one, the reftable library gracefully
> handles the case where auto-compaction cannot delete a still-open stack
> already and ignores any such errors. Also, `reftable_stack_clean()` will
> prune stale tables which are not referenced by "tables.list" anymore so
> that those files can eventually be pruned. And second, we never rewrite
> already-rewritten stacks, so it does not matter that we cannot rename a
> file over an mmaped file, either.
I somehow thought that we use "read into an allocated memory and
pretend as if we mapped" emulation on Windows, so all of that may be
moot.
> diff --git a/reftable/blocksource.c b/reftable/blocksource.c
> index a1ea304429..5d3f3d264c 100644
> --- a/reftable/blocksource.c
> +++ b/reftable/blocksource.c
> @@ -13,6 +13,12 @@ license that can be found in the LICENSE file or at
> #include "reftable-blocksource.h"
> #include "reftable-error.h"
>
> +#if defined(NO_MMAP)
> +static int use_mmap = 0;
> +#else
> +static int use_mmap = 1;
> +#endif
Is there (do you need) some externally controllable knob that the
user can use to turn this off on a system that is compiled without
NO_MMAP? Otherwise it is misleading to have this as a variable.
> -static void file_close(void *b)
> +static void file_close(void *v)
> {
> - int fd = ((struct file_block_source *)b)->fd;
> - if (fd > 0) {
> - close(fd);
> - ((struct file_block_source *)b)->fd = 0;
> + struct file_block_source *b = v;
> +
> + if (b->fd >= 0) {
> + close(b->fd);
> + b->fd = -1;
> }
>
> + if (use_mmap)
> + munmap(b->data, b->size);
> + else
> + reftable_free(b->data);
> + b->data = NULL;
> +
> reftable_free(b);
> }
It would have been nicer to do this kind of "a void pointer is taken
and we immediately cast it to a concrete and useful type upon entry"
clean-up as a separate step that is purely clean-up, if there were
many instances. It is the first such one in the series as far as I
remember, so it is not a huge deal.
> @@ -108,9 +119,7 @@ static int file_read_block(void *v, struct reftable_block *dest, uint64_t off,
> {
> struct file_block_source *b = v;
> assert(off + size <= b->size);
> - dest->data = reftable_malloc(size);
> - if (pread_in_full(b->fd, dest->data, size, off) != size)
> - return -1;
> + dest->data = b->data + off;
> dest->len = size;
> return size;
> }
So, we used to delay the allocation and reading of a block until
this function gets called. Now, by the time the control reaches
the function, we are expected to have the data handy at b->data.
That is ensured by reftable_block_source_from_file(), I presume?
> @@ -127,8 +136,10 @@ int reftable_block_source_from_file(struct reftable_block_source *bs,
> {
> struct stat st = { 0 };
> int err = 0;
> - int fd = open(name, O_RDONLY);
> + int fd;
> struct file_block_source *p = NULL;
> +
> + fd = open(name, O_RDONLY);
> if (fd < 0) {
> if (errno == ENOENT) {
> return REFTABLE_NOT_EXIST_ERROR;
This is a no-op clean-up that would have been better in a separate
clean-up step. Again, not a huge deal.
> @@ -144,7 +155,18 @@ int reftable_block_source_from_file(struct reftable_block_source *bs,
>
> p = reftable_calloc(sizeof(struct file_block_source));
> p->size = st.st_size;
> - p->fd = fd;
> + if (use_mmap) {
> + p->data = xmmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
> + p->fd = fd;
This is a bit unusual for our use of mmap() where the norm is to
close the file descriptor once we mapped (we only need the memory
region itself and not the originating file descriptor to unmap it).
Is there a reason why we need to keep p->fd? Now the other side of
this if/else preallocates the whole thing and slurps everything in
core to allow the remainder of the code to mimic what happens on the
mmaped block memory (e.g., we saw how file_read_block() assumes that
b->data[0..b->size] are valid) and does not obviously need p->fd,
can we just remove .fd member from the file_block_source structure?
That way, file_close() can also lose the conditional close() call.
For that matter, do we need any codepath in this file that is
enabled by !use_mmap? Can't we just use xmmap() and let its
"instead, we allocate, read into it and return" emulation?
Thanks.
> + } else {
> + p->data = xmalloc(st.st_size);
> + if (read_in_full(fd, p->data, st.st_size) != st.st_size) {
> + close(fd);
> + return -1;
> + }
> + close(fd);
> + p->fd = -1;
> + }
>
> assert(!bs->ops);
> bs->ops = &file_vtable;
^ permalink raw reply
* Re: ps/reftable-optimize-io
From: Junio C Hamano @ 2024-01-10 21:25 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
In-Reply-To: <ZZ5AJL4di1TAC-up@tanuki>
Patrick Steinhardt <ps@pks.im> writes:
> Let's wait a few days for reviews. I don't expect there to be a ton of
> reviews from the usual contributors due to the still-limited knowledge
> around reftables in our community.
A successful nerd-sniping?
^ permalink raw reply
* Re: [PATCH] branch: error description when deleting a not fully merged branch
From: Junio C Hamano @ 2024-01-10 21:46 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <xmqqbk9tcc57.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> This is probably one sensible step forward, so let's queue it as-is.
>
> But with reservations for longer-term future direction. Stepping
> back a bit, when 'foo' is not fully merged and the user used "branch
> -d" on it, is it sensible for us to suggest use of "branch -D"?
>
> Especially now this is a "hint" to help less experienced folks, it
> may be helpful to suggest how the user can answer "If you are sure
> you want to delete" part. As this knows what unique commits on the
> branch being deleted are about to be lost, one way to do so may be
> to tell the user about them ("you are about to lose 'branch: error
> description when deleting a not fully merged branch' and other 47
> commits that are not merged the target branch 'main'", for example).
>
> Another possibility is to suggest merging the branch into the
> target, instead of suggesting a destructive "deletion", but I
> suspect that it goes too far second-guessing the end-user intention.
The longer-term concerns aside, if you are inclined, we might want
to have this as a two step series, where [1/2] does a clean-up of
existing source file, i.e. losing the unwanted leading space from "
enum advice_type {" in advice.h and sort the advice.*:: list in
Documentation/config/advice.txt. It is optional to sort the
advice_setting[] list in advice.c and "enum advice_type" in
advice.h, as they are not end-user facing, and we should be using
the defined constant without relying on their exact values. But
keeping the config/advice.txt sorted would help readers more easily
locate which configuration variable to use to squelch a message.
And [2/2] does the rest.
Also I forgot that in the version I queued, I fixed the title to
branch: make the advice to force-deleting a conditional one
Thanks.
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: Dragan Simic @ 2024-01-10 21:57 UTC (permalink / raw)
To: Taylor Blau; +Cc: git
In-Reply-To: <ZZ77NQkSuiRxRDwt@nand.local>
On 2024-01-10 21:16, Taylor Blau wrote:
> Over the holiday break at the end of last year I spent some time
> thinking on what it would take to introduce Rust into the Git project.
>
> There is significant work underway to introduce Rust into the Linux
> kernel (see [1], [2]). Among their stated goals, I think there are a
> few
> which could be potentially relevant to the Git project:
>
> - Lower risk of memory safety bugs, data races, memory leaks, etc.
> thanks to the language's safety guarantees.
>
> - Easier to gain confidence when refactoring or introducing new code
> in Rust (assuming little to no use of the language's `unsafe`
> feature).
>
> - Contributing to Git becomes easier and accessible to a broader
> group
> of programmers by relying on a more modern language.
>
> Given the allure of these benefits, I think it's at least worth
> considering and discussing how Rust might make its way into Junio's
> tree.
Quite frankly, that would only complicate things and cause
fragmentation. The goal of introducing Rust into the Linux kernel is
to, possibly, have some new "leafs" written in Rust, such as some new
device drivers. No existing kernel code, AFAIK, has been planned to be
rewritten in Rust.
Thus, Git should probably follow the same approach of not converting the
already existing code, but frankly, I don't see what would actually be
the "new leafs" written in Rust.
> I imagine that the transition state would involve some parts of the
> project being built in C and calling into Rust code via FFI (and
> perhaps
> vice-versa, with Rust code calling back into the existing C codebase).
> Luckily for us, Rust's FFI provides a zero-cost abstraction [3],
> meaning
> there is no performance impact when calling code from one language in
> the other.
>
> Some open questions from me, at least to get the discussion going are:
>
> 1. Platform support. The Rust compiler (rustc) does not enjoy the
> same
> widespread availability that C compilers do. For instance, I
> suspect that NonStop, AIX, Solaris, among others may not be
> supported.
>
> One possible alternative is to have those platforms use a Rust
> front-end for a compiler that they do support. The gccrs [4]
> project would allow us to compile Rust anywhere where GCC is
> available. The rustc_codegen_gcc [5] project uses GCC's libgccjit
> API to target GCC from rustc itself.
>
> 2. Migration. What parts of Git are easiest to convert to Rust? My
> hunch is that the answer is any stand-alone libraries, like
> strbuf.h. I'm not sure how we should identify these, though, and
> in
> what order we would want to move them over.
>
> 3. Interaction with the lib-ification effort. There is lots of work
> going on in an effort to lib-ify much of the Git codebase done by
> Google. I'm not sure how this would interact with that effort, but
> we should make sure that one isn't a blocker for the other.
>
> I'm curious to hear what others think about this. I think that this
> would be an exciting and worthwhile direction for the project. Let's
> see!
>
> Thanks,
> Taylor
>
> [1]: https://rust-for-linux.com/
> [2]:
> https://lore.kernel.org/rust-for-linux/20210414184604.23473-1-ojeda@kernel.org/
> [3]:
> https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#c-talking-to-rust
> [4]: https://github.com/Rust-GCC/gccrs
> [5]: https://github.com/rust-lang/rustc_codegen_gcc
^ permalink raw reply
* [PATCH] gitweb: Fixes error handling when reading configuration
From: Marcelo Roberto Jimenez @ 2024-01-10 22:05 UTC (permalink / raw)
To: marcelo.jimenez; +Cc: git
In-Reply-To: <CACjc_5pdijCZrrXQWHswsxYrGUzZ7pZq+nj3SzY1z+Xxop64Ww@mail.gmail.com>
This patch fixes a possibility of a permission to access error go
unnoticed.
Perl uses two different variables to manage errors from a do. One
is $@, which is set in this case when do is unable to compile the
file. The other is $!, which is set in case do cannot read the file.
By printing the value of $! I found out that it was set to Permission
denied. Since the script does not currently test for $!, the error
goes unnoticed.
Perl do block documentation: https://perldoc.perl.org/functions/do
Signed-off-by: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
---
gitweb/gitweb.perl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e66eb3d9ba..47577ec566 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -728,9 +728,11 @@ sub filter_and_validate_refs {
sub read_config_file {
my $filename = shift;
return unless defined $filename;
- # die if there are errors parsing config file
if (-e $filename) {
do $filename;
+ #die if there is a problem accessing the file
+ die $! if $!;
+ # die if there are errors parsing config file
die $@ if $@;
return 1;
}
--
2.43.0
^ permalink raw reply related
* Re: [DISCUSS] Introducing Rust into the Git project
From: Junio C Hamano @ 2024-01-10 22:11 UTC (permalink / raw)
To: Dragan Simic; +Cc: Taylor Blau, git
In-Reply-To: <b2651b38a4f7edaf1c5ffee72af00e46@manjaro.org>
Dragan Simic <dsimic@manjaro.org> writes:
> Thus, Git should probably follow the same approach of not converting
> the already existing code, but frankly, I don't see what would
> actually be the "new leafs" written in Rust.
A few obvious ones that come to my mind are that you should be able
to write a new merge strategy and link the resulting binary into Git
without much hassle. You might even want to make that a dynamically
loaded object. The interface into a merge strategy is fairly narrow
IIRC. Or possibly a new remote helper.
Adding a new refs backend may need to wait for the work Patrick is
doing to add reftable support, but once the abstraction gets to the
point to sufficiently hide the differences between files and reftables
backends, I do not see a reason why you cannot add the third one.
And more into the future, we might want to have an object DB
abstraction, similar to how we abstracted refs API over time, at
which time you might be writing code that stores objects to and
retrieves objects from persistent redis and whatnot in your favorite
language.
^ permalink raw reply
* RE: [DISCUSS] Introducing Rust into the Git project
From: rsbecker @ 2024-01-10 22:15 UTC (permalink / raw)
To: 'Junio C Hamano', 'Dragan Simic'
Cc: 'Taylor Blau', git
In-Reply-To: <xmqqjzog96uh.fsf@gitster.g>
On Wednesday, January 10, 2024 5:12 PM, Junio C Hamano wrote:
>Dragan Simic <dsimic@manjaro.org> writes:
>
>> Thus, Git should probably follow the same approach of not converting
>> the already existing code, but frankly, I don't see what would
>> actually be the "new leafs" written in Rust.
>
>A few obvious ones that come to my mind are that you should be able to
write a
>new merge strategy and link the resulting binary into Git without much
hassle. You
>might even want to make that a dynamically loaded object. The interface
into a
>merge strategy is fairly narrow IIRC. Or possibly a new remote helper.
>
>Adding a new refs backend may need to wait for the work Patrick is doing to
add
>reftable support, but once the abstraction gets to the point to
sufficiently hide the
>differences between files and reftables backends, I do not see a reason why
you
>cannot add the third one.
>
>And more into the future, we might want to have an object DB abstraction,
similar
>to how we abstracted refs API over time, at which time you might be writing
code
>that stores objects to and retrieves objects from persistent redis and
whatnot in
>your favorite language.
Just a brief concern: Rust is not broadly portable. Adding another
dependency to git will remove many existing platforms from future releases.
Please consider this carefully before going down this path.
--Randall
^ permalink raw reply
* Re: [PATCH 1/5] t5309: run expected-to-fail `index-pack`s with `--threads=1`
From: Junio C Hamano @ 2024-01-10 22:18 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Jeff King
In-Reply-To: <588de2e4f16ab090ff477088084e0b81d9615ec5.1704909216.git.me@ttaylorr.com>
Taylor Blau <me@ttaylorr.com> writes:
> But that requires us to tweak production code (albeit at a negligible
> cost) in order to appease LSan in this narrow circumstance. Another
> approach is to simply run these expected-to-fail `index-pack`
> invocations with `--threads=1` so that we bypass the above issue
> entirely.
But of course, multi-threaded operation that production folks use
will not be tested at all with the alternative.
> The downside of that approach is that the test doesn't match our
> production code as well as it did before (where we might have run those
> same `index-pack` invocations with >1 thread, depending on how many CPUs
> the testing machine has). The risk there is that we might miss a
> regression that would leave us in an inconsistent state. But that feels
> rather unlikely in practice, and there are many other tests related to
> `index-pack` in the suite.
As long as "make sure we spawn all of them atmically" has negligible
downside, I'd rather take that approach. Buying predictability with
minimum cost is quite attractive.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/5] t5309: run expected-to-fail `index-pack`s with `--threads=1`
From: Taylor Blau @ 2024-01-10 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <xmqqfrz496ib.fsf@gitster.g>
On Wed, Jan 10, 2024 at 02:18:52PM -0800, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > But that requires us to tweak production code (albeit at a negligible
> > cost) in order to appease LSan in this narrow circumstance. Another
> > approach is to simply run these expected-to-fail `index-pack`
> > invocations with `--threads=1` so that we bypass the above issue
> > entirely.
>
> But of course, multi-threaded operation that production folks use
> will not be tested at all with the alternative.
Just the ones that we expect to fail *and* are in test scripts which are
marked as leak-free.
> > The downside of that approach is that the test doesn't match our
> > production code as well as it did before (where we might have run those
> > same `index-pack` invocations with >1 thread, depending on how many CPUs
> > the testing machine has). The risk there is that we might miss a
> > regression that would leave us in an inconsistent state. But that feels
> > rather unlikely in practice, and there are many other tests related to
> > `index-pack` in the suite.
>
> As long as "make sure we spawn all of them atmically" has negligible
> downside, I'd rather take that approach. Buying predictability with
> minimum cost is quite attractive.
Like I said earlier, I have no strong preference between either
approach. If you want to pick up Peff's patch instead of these five,
that is fine with me :-).
Thanks,
Taylor
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: Taylor Blau @ 2024-01-10 22:26 UTC (permalink / raw)
To: rsbecker; +Cc: 'Junio C Hamano', 'Dragan Simic', git
In-Reply-To: <006b01da4412$96c6c500$c4544f00$@nexbridge.com>
Hi Randall,
On Wed, Jan 10, 2024 at 05:15:53PM -0500, rsbecker@nexbridge.com wrote:
> Just a brief concern: Rust is not broadly portable. Adding another
> dependency to git will remove many existing platforms from future releases.
> Please consider this carefully before going down this path.
I was hoping to hear from you as one of the few (only?) folks who
participate on the list and represent HPE NonStop users.
I'm curious which if any of the compiler frontends that I listed in my
earlier email would work for you.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH v2 0/2] doc: bisect: change plural paths to singular pathspec
From: Junio C Hamano @ 2024-01-10 22:38 UTC (permalink / raw)
To: Britton Leo Kerin; +Cc: Taylor Blau, git
In-Reply-To: <ZZWWmXHa8ebtkZQ8@nand.local>
Taylor Blau <me@ttaylorr.com> writes:
> On Tue, Jan 02, 2024 at 07:02:05PM -0900, Britton Leo Kerin wrote:
>> Britton Leo Kerin (2):
>> doc: use singular form of repeatable path arg
>> doc: refer to pathspec instead of path
>>
>> Documentation/git-bisect.txt | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Range-diff against v1:
>> 1: 90c081dcab ! 1: da40e4736b doc: use singular form of repeatable path arg
>> @@ Commit message
>> later document text mentions 'path' arguments, while it doesn't mention
>> 'paths'.
>>
>> - Signed-off-by: Britton L Kerin <britton.kergin@gmail.com>
>> + Signed-off-by: Britton Leo Kerin <britton.kergin@gmail.com>
>>
>> ## Documentation/git-bisect.txt ##
>> @@ Documentation/git-bisect.txt: The command takes various subcommands, and different options depending
>> -: ---------- > 2: d932b6d501 doc: refer to pathspec instead of path
>> --
>> 2.43.0
>
> Hmm. The end-state of these two patches looks good to me, but I probably
> would have written this change as a single change from "paths" ->
> "pathspec", not "paths" -> "path" -> "pathspec".
Have we seen a resolution to this comment? I _think_ it is an OK
approach to take to do this in two steps, if the use of technical
term "pathspec" could be controversial, but since it is not, I am
fine with either one or two patches. Since we already have the
two-patch version, let's take it.
Thanks.
^ permalink raw reply
* [PATCH v2] gitweb: Fixes error handling when reading configuration
From: Marcelo Roberto Jimenez @ 2024-01-10 22:57 UTC (permalink / raw)
To: marcelo.jimenez; +Cc: git
In-Reply-To: <CACjc_5pdijCZrrXQWHswsxYrGUzZ7pZq+nj3SzY1z+Xxop64Ww@mail.gmail.com>
This patch fixes a possibility of a permission to access error go
unnoticed.
Perl uses two different variables to manage errors from a do. One
is $@, which is set in this case when do is unable to compile the
file. The other is $!, which is set in case do cannot read the file.
By printing the value of $! I found out that it was set to Permission
denied. Since the script does not currently test for $!, the error
goes unnoticed.
Perl do block documentation: https://perldoc.perl.org/functions/do
Signed-off-by: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
---
gitweb/gitweb.perl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e66eb3d9ba..5d0122020f 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -728,9 +728,11 @@ sub filter_and_validate_refs {
sub read_config_file {
my $filename = shift;
return unless defined $filename;
- # die if there are errors parsing config file
if (-e $filename) {
do $filename;
+ # die if there is a problem accessing the file
+ die $! if $!;
+ # die if there are errors parsing config file
die $@ if $@;
return 1;
}
base-commit: 564d0252ca632e0264ed670534a51d18a689ef5d
--
2.43.0
^ permalink raw reply related
* Re: Limited operations in unsafe repositories
From: brian m. carlson @ 2024-01-10 23:34 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20240110120531.GA25541@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 906 bytes --]
On 2024-01-10 at 12:05:31, Jeff King wrote:
> My thinking is to flip that around: run all code, but put protection in
> the spots that do unsafe things, like loading config or examining
> hooks. I.e., a patch like this:
I think that's much what I had intended to do with not invoking binaries
at all, except that it was limited to rev-parse. I wonder if perhaps we
could do something similar if we had the `--assume-unsafe` argument you
proposed, except that we would only allow the `git` binary and always
pass that argument to it in such a case.
I don't think reading config is intrinsically unsafe; it's more of what
we do with it, which is spawning external processes, that's the problem.
I suppose an argument could be made for injecting terminal sequences or
such, though. Hooks, obviously, are definitely unsafe.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: brian m. carlson @ 2024-01-10 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dragan Simic, Taylor Blau, git
In-Reply-To: <xmqqjzog96uh.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]
On 2024-01-10 at 22:11:34, Junio C Hamano wrote:
> A few obvious ones that come to my mind are that you should be able
> to write a new merge strategy and link the resulting binary into Git
> without much hassle. You might even want to make that a dynamically
> loaded object. The interface into a merge strategy is fairly narrow
> IIRC. Or possibly a new remote helper.
>
> Adding a new refs backend may need to wait for the work Patrick is
> doing to add reftable support, but once the abstraction gets to the
> point to sufficiently hide the differences between files and reftables
> backends, I do not see a reason why you cannot add the third one.
>
> And more into the future, we might want to have an object DB
> abstraction, similar to how we abstracted refs API over time, at
> which time you might be writing code that stores objects to and
> retrieves objects from persistent redis and whatnot in your favorite
> language.
This is definitely a thing people will want to do. I think Microsoft
had some code for Azure DevOps that stored their code in the cloud and
the refs database in a real database. I can imagine that being a
valuable set of features people would want to implement in a variety of
environments, with all of the benefits of basing on upstream Git.
I also feel that I would absolutely not want to write those things in C.
Rust is much more ergonomic when writing these things because freeing
resources (freeing memory, rolling back transactions, closing files,
etc.) becomes as easy as implementing the Drop trait and you write less
boilerplate.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* RE: [DISCUSS] Introducing Rust into the Git project
From: rsbecker @ 2024-01-10 23:52 UTC (permalink / raw)
To: 'Taylor Blau'
Cc: 'Junio C Hamano', 'Dragan Simic', git
In-Reply-To: <ZZ8ZlX6bf+hjmhN+@nand.local>
On Wednesday, January 10, 2024 5:26 PM, Taylor Blau wrote:
>On Wed, Jan 10, 2024 at 05:15:53PM -0500, rsbecker@nexbridge.com wrote:
>> Just a brief concern: Rust is not broadly portable. Adding another
>> dependency to git will remove many existing platforms from future releases.
>> Please consider this carefully before going down this path.
>
>I was hoping to hear from you as one of the few (only?) folks who participate on
>the list and represent HPE NonStop users.
>
>I'm curious which if any of the compiler frontends that I listed in my earlier email
>would work for you.
Unfortunately, none of the compiler frontends listed previously can be built for NonStop. These appear to all require gcc either directly or transitively, which cannot be ported to NonStop. I do not expect this to change any time soon - and is outside of my control anyway. An attempt was made to port Rust but it did not succeed primarily because of that dependency. Similarly, Golang is also not portable to NonStop because of architecture assumptions made by the Go team that cannot be satisfied on NonStop at this time. If some of the memory/pointer issues are the primary concern, c11 might be something acceptable with smart pointers. C17 will eventually be deployable, but is not available on most currently supported OS versions on the platform.
^ permalink raw reply
* Re: Limited operations in unsafe repositories
From: Junio C Hamano @ 2024-01-11 0:04 UTC (permalink / raw)
To: brian m. carlson; +Cc: Jeff King, git
In-Reply-To: <ZZ8pbAMNaBDFgf3G@tapette.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2024-01-10 at 12:05:31, Jeff King wrote:
>> My thinking is to flip that around: run all code, but put protection in
>> the spots that do unsafe things, like loading config or examining
>> hooks. I.e., a patch like this:
>
> I think that's much what I had intended to do with not invoking binaries
> at all, except that it was limited to rev-parse. I wonder if perhaps we
> could do something similar if we had the `--assume-unsafe` argument you
> proposed, except that we would only allow the `git` binary and always
> pass that argument to it in such a case.
>
> I don't think reading config is intrinsically unsafe; it's more of what
> we do with it, which is spawning external processes, that's the problem.
> I suppose an argument could be made for injecting terminal sequences or
> such, though. Hooks, obviously, are definitely unsafe.
Sure. And we allow the location of hook programs to be specified as
configuration variable values, which would make the config even more
dangerous X-<.
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: Elijah Newren @ 2024-01-11 0:12 UTC (permalink / raw)
To: Taylor Blau; +Cc: git
In-Reply-To: <ZZ77NQkSuiRxRDwt@nand.local>
On Wed, Jan 10, 2024 at 12:18 PM Taylor Blau <me@ttaylorr.com> wrote:
>
> Over the holiday break at the end of last year I spent some time
> thinking on what it would take to introduce Rust into the Git project.
I'm very happy to see this email.
> There is significant work underway to introduce Rust into the Linux
> kernel (see [1], [2]). Among their stated goals, I think there are a few
> which could be potentially relevant to the Git project:
>
> - Lower risk of memory safety bugs, data races, memory leaks, etc.
> thanks to the language's safety guarantees.
>
> - Easier to gain confidence when refactoring or introducing new code
> in Rust (assuming little to no use of the language's `unsafe`
> feature).
>
> - Contributing to Git becomes easier and accessible to a broader group
> of programmers by relying on a more modern language.
>
> Given the allure of these benefits, I think it's at least worth
> considering and discussing how Rust might make its way into Junio's
> tree.
I think there are other benefits as well; I'll list them at the end of
the email to avoid side-tracking too much[6].
> I imagine that the transition state would involve some parts of the
> project being built in C and calling into Rust code via FFI (and perhaps
> vice-versa, with Rust code calling back into the existing C codebase).
> Luckily for us, Rust's FFI provides a zero-cost abstraction [3], meaning
> there is no performance impact when calling code from one language in
> the other.
I agree with the zero-cost abstraction, but there is a funny caveat
with measuring it if anyone is curious[7].
> Some open questions from me, at least to get the discussion going are:
>
> 1. Platform support. The Rust compiler (rustc) does not enjoy the same
> widespread availability that C compilers do. For instance, I
> suspect that NonStop, AIX, Solaris, among others may not be
> supported.
>
> One possible alternative is to have those platforms use a Rust
> front-end for a compiler that they do support. The gccrs [4]
> project would allow us to compile Rust anywhere where GCC is
> available. The rustc_codegen_gcc [5] project uses GCC's libgccjit
> API to target GCC from rustc itself.
Another alternative (as discussed at Git Merge when we were last
talking about Rust[8]), is requiring all Rust code to be optional for
now. If we choose to go that route, I think that means that (a) for
existing components, we have both a Rust and a C implementation
available, and (b) for new components (e.g. new top-level commands
like git-replay), they can be Rust-only and those compiling without
Rust just don't get them.
> 2. Migration. What parts of Git are easiest to convert to Rust? My
> hunch is that the answer is any stand-alone libraries, like
> strbuf.h. I'm not sure how we should identify these, though, and in
> what order we would want to move them over.
If we're happy to allow Rust, I'd like to rewrite git-replay in Rust
as a testcase. It's almost certainly not "easiest", but I think it's
an interesting testcase because it's a new top-level command that
hasn't appeared in any release yet. Further, it is currently only
designed for server-side usecases, so would likely not be affected by
more limited platform support. (I haven't started on this; my
previous experiments were with diffcore-delta.)
> I'm curious to hear what others think about this. I think that this
> would be an exciting and worthwhile direction for the project. Let's
> see!
:-)
>
> Thanks,
> Taylor
>
> [1]: https://rust-for-linux.com/
> [2]: https://lore.kernel.org/rust-for-linux/20210414184604.23473-1-ojeda@kernel.org/
> [3]: https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#c-talking-to-rust
> [4]: https://github.com/Rust-GCC/gccrs
> [5]: https://github.com/rust-lang/rustc_codegen_gcc
[6] Here are some additional benefits I see:
- Parallel performance. We avoid making things parallel in Git because
debugging/maintaining/reviewing parallel code in C often isn't worth
the squeeze. Rust was designed to greatly reduce this effort (the
whole "fearless concurrency" thing).
- Single-threaded Performance. Multiple factors:
- We had (and might still have) O(N^2) stuff in a lot of places in
our codebase, because we tend to over-use arrays. (e.g. with
string_list, or with insertions and deletions into the index
during a merge, etc.)
- Relatedly, using hashes in C is quite onerous, to the point that
we often simply avoid it. I know I have, and I also know that
even after I introduced strmap and tried to use it outside of
merge-ort, that I got pushback because "string hash-maps are not
really typical for a C program. I'm sure they are the best choice
for an advanced merge algorithm but they are not really necessary
[here; let's use sorted arrays instead]..." I then had to go
through multiple rounds of responses and ended up reimplementing
everything as suggested (before finally convincing others to just
use the strmap implementation after all).
- We use QSORT() which basically calls libc's qsort(). Due to the
design of this function (where the comparator is a separate
function call), it is slow. When languages avoid making the
comparator a separate function call, they can speed sorts up by a
factor of 2 (or even by 3 when an unstable sort is good enough
and the platform's qsort() is stable).
- Difficulty of incorporating other libraries. For example, our
hashmap.[ch] make use of FNV, but picking something else is a big
amount of effort. Now, while FNV is faster than Rust's default
of SipHash, cargo makes it easy to pull in alternatives like
FnvHashMap or FxHashMap, which we can then use where it matters.
I'm also tempted to include bullet points for having a unit testing
framework built in, and potentially fewer platform-dependent issues
(e.g. forgetting to use STABLE_QSORT when required since qsort is
stable in some libc implementations, since rust defines those more
carefully to be consistent across platforms), but I'm not sure these
additional advantages are big enough to merit a full bullet point.
[7] If you ignore Rust for a moment, and simply divide your files into
different libraries (e.g. introducing a new.c file, moving some
functions to it, and then compiling new.c into a new library,
libnew.a, and linking both libgit.a and libnew.a into git), you can
sometimes measure some small performance differences. At least, I
did. What this scenario has to do with Rust is that if we start
moving some code to Rust, that will naturally likely result in a
different division of files into libraries. Thus, for me to verify
that Rust did provide zero-cost abstractions with my experiments, in
order to compare the performance of my Rust changes, I had to compare
to a version of git where I split some functions out into a separate
library. When I did that, the performance overhead was actually 0.
Otherwise, there was a tiny performance degradation in the particular
splitting I employed. However, while splitting did give me a small
performance drop, it was completely outweighed by the performance
advantages I got elsewhere in the things I converted to Rust.
[8] https://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/
^ permalink raw reply
* Re: [PATCH v2] gitweb: Fixes error handling when reading configuration
From: Junio C Hamano @ 2024-01-11 0:17 UTC (permalink / raw)
To: Marcelo Roberto Jimenez; +Cc: git
In-Reply-To: <20240110225709.30168-1-marcelo.jimenez@gmail.com>
Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com> writes:
> This patch fixes a possibility of a permission to access error go
> unnoticed.
>
> Perl uses two different variables to manage errors from a do. One
> is $@, which is set in this case when do is unable to compile the
> file. The other is $!, which is set in case do cannot read the file.
> By printing the value of $! I found out that it was set to Permission
> denied. Since the script does not currently test for $!, the error
> goes unnoticed.
Well explained how the current code behaves and why.
With my devil's advocate hat on, I suspect that the current
behaviour comes from the wish to see "file exists but unreadable"
and "the named file does not exist" behave the same way. If you
pass the name of a configuration file that does not exist, however,
the codeblock to die does not trigger at all. If a file does exist
but unreadable, to gitweb, it is just as good as having no file to
read configuration data from---either way, it cannot use anything
useful from the named file. So returning silently, which is the
"bug" you are fixing, does not sound too bad.
I dunno. Let's queue and see what others would say.
Thanks.
> Perl do block documentation: https://perldoc.perl.org/functions/do
>
> Signed-off-by: Marcelo Roberto Jimenez <marcelo.jimenez@gmail.com>
> ---
> gitweb/gitweb.perl | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e66eb3d9ba..5d0122020f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -728,9 +728,11 @@ sub filter_and_validate_refs {
> sub read_config_file {
> my $filename = shift;
> return unless defined $filename;
> - # die if there are errors parsing config file
> if (-e $filename) {
> do $filename;
> + # die if there is a problem accessing the file
> + die $! if $!;
> + # die if there are errors parsing config file
> die $@ if $@;
> return 1;
> }
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: Elijah Newren @ 2024-01-11 0:33 UTC (permalink / raw)
To: Dragan Simic; +Cc: Taylor Blau, git
In-Reply-To: <b2651b38a4f7edaf1c5ffee72af00e46@manjaro.org>
On Wed, Jan 10, 2024 at 1:57 PM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Thus, Git should probably follow the same approach of not converting the
> already existing code
I disagree with this. I saw significant performance improvements
through converting some existing Git code to Rust. Granted, it was
only a small amount of code, but the performance benefits I saw
suggested we'd see more by also doing similar conversions elsewhere.
(Note that I kept the old C code and then conditionally compiled
either Rust or C versions of what I was converting.)
Further, I found a really old bug from this effort as well[1], and I
find it extremely unlikely that I would have found that bug otherwise.
So, converting to Rust can even improve our existing C code.
>, but frankly, I don't see what would actually be
> the "new leafs" written in Rust.
In addition to some of the examples Junio mentioned elsewhere, I think
new toplevel commands, like git-replay, would qualify.
[1] Yeah, I really need to dig the patch out and send it in. I'll do
so shortly.
^ permalink raw reply
* Re: [PATCH 0/2] Generalize reference locking in tests
From: Junio C Hamano @ 2024-01-11 0:36 UTC (permalink / raw)
To: Justin Tobler via GitGitGadget; +Cc: git, Justin Tobler
In-Reply-To: <pull.1634.git.1704912750.gitgitgadget@gmail.com>
"Justin Tobler via GitGitGadget" <gitgitgadget@gmail.com> writes:
> This approach is more verbose and may warrant consideration of implementing
> an abstraction to further simplify this operation. There appears to be one
> other existing test in t1400 that also follows this pattern. Being that
> there is only a handful of affected tests the implemented approach may be
> sufficient as is.
The use of two fifos and avoiding deadlocking parent and child is
tricky enough that it does feel that it warrants a helper function
to do the common part of what these two patches add.
I think I read t1401 patch carefully enough to understand what is
going on, but I cannot yet claim the same for the other one.
Thanks.
> Justin Tobler (2):
> t1401: generalize reference locking
> t5541: generalize reference locking
>
> t/t1401-symbolic-ref.sh | 28 ++++++++++++++++++++++++----
> t/t5541-http-push-smart.sh | 25 +++++++++++++++++++++++--
> 2 files changed, 47 insertions(+), 6 deletions(-)
>
>
> base-commit: 624eb90fa8f65a79396615f3c2842ac5a3743350
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1634%2Fjltobler%2Fjt%2Fbackend-generic-ref-lock-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1634/jltobler/jt/backend-generic-ref-lock-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1634
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: Elijah Newren @ 2024-01-11 0:59 UTC (permalink / raw)
To: rsbecker; +Cc: Taylor Blau, Junio C Hamano, Dragan Simic, git
In-Reply-To: <007c01da4420$10a7b700$31f72500$@nexbridge.com>
On Wed, Jan 10, 2024 at 3:52 PM <rsbecker@nexbridge.com> wrote:
>
> On Wednesday, January 10, 2024 5:26 PM, Taylor Blau wrote:
> >On Wed, Jan 10, 2024 at 05:15:53PM -0500, rsbecker@nexbridge.com wrote:
> >> Just a brief concern: Rust is not broadly portable. Adding another
> >> dependency to git will remove many existing platforms from future releases.
> >> Please consider this carefully before going down this path.
> >
> >I was hoping to hear from you as one of the few (only?) folks who participate on
> >the list and represent HPE NonStop users.
> >
> >I'm curious which if any of the compiler frontends that I listed in my earlier email
> >would work for you.
>
> Unfortunately, none of the compiler frontends listed previously can be built for NonStop. These appear to all require gcc either directly or transitively, which cannot be ported to NonStop. I do not expect this to change any time soon - and is outside of my control anyway. An attempt was made to port Rust but it did not succeed primarily because of that dependency. Similarly, Golang is also not portable to NonStop because of architecture assumptions made by the Go team that cannot be satisfied on NonStop at this time. If some of the memory/pointer issues are the primary concern, c11 might be something acceptable with smart pointers. C17 will eventually be deployable, but is not available on most currently supported OS versions on the platform.
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.)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox