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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Feb 5, 2026, 00:10 UTC
Message-ID: <aYPf9CnNLjJtinqw@fruit.crustytoothpaste.net>
In-Reply-To: <20260204232208.1615320-1-mh@glandium.org>

On 2026-02-04 at 23:22:08, Mike Hommey wrote:

Show 10 quoted lines

> 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.

Note that I don't have strong opinions for or against placing the Rust code in a subdirectory, but I do very much want the standard layout to be honoured.

Show 19 quoted lines

> The above is a post hoc justification. I do think it makes sense to do,
> but I should mention my real immediate motivation.
> 
> git-cinnabar, a git remote helper used to talk to Mercurial servers, is
> a project based on libgit (the C parts). As such, its repository
> includes the git codebase as a submodule.
> 
> As of about 3 years ago, most code that is not libgit in git-cinnabar is
> written in Rust, and is published on crates.io.
> 
> Part of publishing on crates.io involves running `cargo publish`, which
> does `cargo package` under the hood. `cargo package` has the feature
> of... not including directories that contain a Cargo.toml, so upgrading
> libgit to 2.52.0 breaks the publishing process because all of the git
> source code is skipped, and git-cinnabar can't be built as a result.
> 
> Of course, what this means is that this change is merely kicking the can
> down the road, because the problem will reappear when the rust code
> becomes non-optional in Git, thus why I'm making this RFC at the moment.

Perhaps you could ask Cargo upstream to add a feature to override that in the meantime (or add such a feature yourself). I can imagine other uses for such a feature.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA