Hi Josh,

On Thu, 27 Mar 2025, Josh Steadmon wrote:

On 2025.03.25 16:08, Junio C Hamano wrote:

quoted

Josh Steadmon [off-list ref] writes:

quoted

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

If it is more like adding a new build configuration file whereever
we have Makefile (or meson.build), and is not like we are adding one
new file per one existing source file, then I see no reason why we
want to avoid adding a few files to the root-level.

quoted

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

Yeah, that would probably be a reasonable thing to try.  Thanks.

quoted

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.

Yeah, or putting it another way, #1 would help us gather enough Rust
minded folks who are familiar enough to come up with ideas and offer
better ways to manage this part of the system.

Thanks.

Unfortunately creating a workspace doesn't provide access to the
top-level source. Symlinks seem to be the only recommended approach [1]
for embedded crates, but since that breaks Windows CI let's just drop
the series for now.

[1] https://users.rust-lang.org/t/including-files-from-parent-directory-in-package/88969

If you need symbolic linkson Windows in CI, please set
`MSYS=winsymlinks:nativestrict` like it is done here:
https://github.com/git-for-windows/git/blob/4ca71ba5311a8f1bafbf002e97e076f15dcfc15b/t/t2040-checkout-symlink-attr.sh#L8-L10.

It might fail, though, if it requires _Git_ to be able to create symbolic
links because I have not yet managed to upstream the patches to implement
that.

We could fast-track support for `readlink()` without the other parts
(https://github.com/git-for-windows/git/commit/86420a1b84d1), but last
time I checked, Git's test suite did not pass under
`MSYS=winsymlinks:nativestrict` for some reasons I was unable to analyze
for lack of time.

Ciao,
Johannes