On 2025.03.24 08:42, Junio C Hamano wrote: > Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes: > > > On Fri, Mar 21, 2025 at 6:14 PM Josh Steadmon <steadmon@xxxxxxxxxx> wrote: > >> 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/ > > > >> 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.
