Subject: Re: [RFC PATCH] Move rust gitcore crate to a different subdirectory

From: "brian m. carlson" <[email-masked]>
Date: Thu, 5 Feb 2026 02:06:32 +0000

On 2026-02-05 at 01:45:53, Mike Hommey wrote:
> On Thu, Feb 05, 2026 at 12:10:28AM +0000, brian m. carlson wrote:
> > On 2026-02-04 at 23:22:08, Mike Hommey wrote:
> > > While `src/` is the default directory convention for Rust projects, it
> > > is too generic in the context of a multi-language project that is barely
> > > starting to (optionally) use Rust code.
> > > 
> > > Additionally, having `Cargo.toml` at the top-level of the repository
> > > implies that one can run `cargo build` directly, but this doesn't
> > > produce anything useful on its own.
> > > 
> > > Moving all Rust-specific files into a dedicated `rust/` subdirectory
> > > makes things clearer.
> > 
> > If we're going to do this, we should place the `src` directory under the
> > `rust` subdirectory to maintain the normal layout.  There are many tools
> > that depend on this repository layout and we want to make it as easy as
> > possible for people to use native, standard tooling to build things.
> 
> Not that I'm going to argue your preference, but I'm curious what tools
> you'd know that would not support a layout different than the typical
> one, because that means they're broken with some existing crates (e.g.
> those from https://github.com/servo/servo/) and should probably be
> fixed.

One of my goals is to see if we can get Git's Rust code to compile with
mrustc since that might make it easier for NonStop, as well as some
Linux OSes on obsolete architectures.

I can tell you from my experience that mrustc's cargo implementation is
extremely limited and does only the bare minimum in terms of
functionality.  It already needs some help to work with static
libraries, but I'd really like to minimize the work that needs to be
done on it since it's not lovely code, and using a standard layout is
going to help with minimizing the necessary changes.  I will admit that
I haven't tested using a non-standard layout, but I fully expect it will
not work based on my experience of the codebase.

Certainly people may think this is folly, but it costs nothing for us to
keep the standard layout and make the porting process a little easier.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA