On 2025.03.24 08:42, Junio C Hamano wrote:

Eric Sunshine [off-list ref] writes:

quoted

On Fri, Mar 21, 2025 at 6:14 PM Josh Steadmon [off-list ref] wrote:

quoted

Unlike `cargo build`, `cargo package` does not get access to the entire Git repo
containing a Rust crate. Instead, it prepares a directory starting from the
crate root (potentially excluding files, such as those not under version
control, or explicity excluded in the Cargo.toml file).

s/explicity/explicitly/

quoted

diff --git a/contrib/libgit-sys/git-src b/contrib/libgit-sys/git-src

@@ -0,0 +1 @@
+../..

\ No newline at end of file

Meh.

https://github.com/git/git/actions/runs/14030831429/job/39278185588#step:3:1

All of the Windows test jobs (not build ones) are broken due to the
presence of ../.. symbolic link.

Is that ugly hack the only way we can make this work?

It's the only way I know of to accomplish both:
1) creating a packaged crate with `cargo package` and
2) keeping the top-level clean of any Rust code or configuration.

If we're willing to have a Cargo.toml file in the repo root, we could
create a "Cargo workspace", but I'm not sure yet if that avoids the same
problem with accessing sources outside of the crates themselves. I'll be
able to test it out later this week.

If the workspace approach doesn't work, the alternatives are:

1) avoid the issue for now; anyone who wants to experiment with
libgit-rs can do so by building from source (but it will prevent them
from creating their own packaged crates IIUC).

2) move libgit-sys and libgit-rs to separate repos and depend on the Git
source via submodules. This is what I've seen done in other -sys crates
such as zlib-sys (https://github.com/rust-lang/libz-sys).

Of those alternatives, I prefer #1 for now. If we build enough momentum
on libification and expanding the coverage of these crates, then we
could think about switching to #2.