user/sven/git.git/src, branch master

rust: add a small wrapper around the hashfile code

2026-02-08T01:41:03Z

Our new binary object map code avoids needing to be intimately involved with file handling by simply writing data to an object implement Write. This makes it very easy to test by writing to a Cursor wrapping a Vec for tests, and thus decouples it from intimate knowledge about how we handle files. However, we will actually want to write our data to an actual file, since that's the most practical way to persist data. Implement a wrapper around the hashfile code that implements the Write trait so that we can write our object map into a file. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

rust: add a new binary object map format

2026-02-08T01:41:03Z

Our current loose object format has a few problems. First, it is not efficient: the list of object IDs is not sorted and even if it were, there would not be an efficient way to look up objects in both algorithms. Second, we need to store mappings for things which are not technically loose objects but are not packed objects, either, and so cannot be stored in a pack index. These kinds of things include shallows, their parents, and their trees, as well as submodules. Yet we also need to implement a sensible way to store the kind of object so that we can prune unneeded entries. For instance, if the user has updated the shallows, we can remove the old values. For these reasons, introduce a new binary object map format. The careful reader will notice that it resembles very closely the pack index v3 format. Add an in-memory object map as well, and allow writing to a batched map, which can then be written later as one of the binary object maps. Include several tests for round tripping and data lookup across algorithms. Note that the use of this code elsewhere in Git will involve some C code and some C-compatible code in Rust that will be introduced in a future commit. Thus, for example, we ignore the fact that if there is no current batch and the caller asks for data to be written, this code does nothing, mostly because this code also does not involve itself with opening or manipulating files. The C code that we will add later will implement this functionality at a higher level and take care of this, since the code which is necessary for writing to the object store is deeply involved with our C abstractions and it would require extensive work (which would not be especially valuable at this point) to port those to Rust. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

rust: add functionality to hash an object

2026-02-08T01:41:03Z

In a future commit, we'll want to hash some data when dealing with an object map. Let's make this easy by creating a structure to hash objects and calling into the C functions as necessary to perform the hashing. For now, we only implement safe hashing, but in the future we could add unsafe hashing if we want. Implement Clone and Drop to appropriately manage our memory. Additionally implement Write to make it easy to use with other formats that implement this trait. While we're at it, add some tests for the various hashing cases. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

rust: fix linking binaries with cargo

2026-02-08T01:41:02Z

When Cargo links binaries with MSVC, it uses the link.exe linker from PATH to do so. However, when running under a shell from MSYS, such as when building with the Git for Windows SDK, which we do in CI, the /ming64/bin and /usr/bin entries are first in PATH. That means that the Unix link binary shows up first, which obviously does not work for linking binaries in any useful way. To solve this problem, adjust PATH to place those binaries at the end of the list instead of the beginning. This allows access to the normal Unix tools, but link.exe will be the compiler's linker. Make sure to export PATH explicitly: while this should be the default, it's more robust to not rely on the shell operating in a certain way. The reason this has not shown up before is that we typically link our binaries from the C compiler. However, now that we're about to introduce a Rust build script (build.rs file), Rust will end up linking that script to further drive Cargo, in which case we'll invoke the linker from it. There are other solutions, such as using LLD, but this one is simple and reliable and is most likely to work with existing systems. Signed-off-by: Ezekiel Newren Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

rust: add additional helpers for ObjectID

2026-02-08T01:41:02Z

Right now, users can internally access the contents of the ObjectID struct, which can lead to data that is not valid, such as invalid algorithms or non-zero-padded hash values. These can cause problems down the line as we use them more. Add a constructor for ObjectID that allows us to set these values and also provide an accessor for the algorithm so that we can access it. In addition, provide useful Display and Debug implementations that can format our data in a useful way. Now that we have the ability to work with these various components in a nice way, add some tests as well to make sure that ObjectID and HashAlgorithm work together as expected. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

hash: add a function to look up hash algo structs

2026-02-08T01:41:01Z

In C, it's easy for us to look up a hash algorithm structure by its offset by simply indexing the hash_algos array. However, in Rust, we sometimes need a pointer to pass to a C function, but we have our own hash algorithm abstraction. To get one from the other, let's provide a simple function that looks up the C structure from the offset and expose it in Rust. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

rust: add a hash algorithm abstraction

2026-02-08T01:41:01Z

This works very similarly to the existing one in C except that it doesn't provide any functionality to hash an object. We don't currently need that right now, but the use of those function pointers do make it substantially more difficult to write a bit-for-bit identical structure across the C/Rust interface, so omit them for now. Instead of the more customary "&self", use "self", because the former is the size of a pointer and the latter is the size of an integer on most systems. Don't define an unknown value but use an Option for that instead. Update the object ID structure to allow slicing the data appropriately for the algorithm. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

rust: add a ObjectID struct

2026-02-08T01:41:01Z

We'd like to be able to write some Rust code that can work with object IDs. Add a structure here that's identical to struct object_id in C, for easy use in sharing across the FFI boundary. We will use this structure in several places in hot paths, such as index-pack or pack-objects when converting between algorithms, so prioritize efficient interchange over a more idiomatic Rust approach. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

rust: build correctly without GNU sed

2025-12-19T08:57:26Z

From e509b5b8be (rust: support for Windows, 2025-10-15), we check cargo's information to decide which library to build. However, that check mistakenly used "sed -s" ("consider files as separate rather than as a single, continuous long stream"), which is a GNU extension. The build thus fails on macOS with "meson -Drust=enabled", which comes with BSD-derived sed. Instead, use the intended "sed -n" and print the matching section of the output. This failure mode likely went unnoticed on systems with GNU sed (common for developer machines and CI) because, in those instances, the output being matched by case is the full cargo output (which either contains the string "-windows-" or doesn't). Helped-by: Eric Sunshine Helped-by: Patrick Steinhardt Signed-off-by: D. Ben Knoble Signed-off-by: Junio C Hamano

rust: support for Windows

2025-10-15T15:10:17Z

The initial patch series that introduced Rust into the core of Git only cared about macOS and Linux. This specifically leaves out Windows, which indeed fails to build right now due to two issues: - The Rust runtime requires `GetUserProfileDirectoryW()`, but we don't link against "userenv.dll". - The path of the Rust library built on Windows is different than on most other systems systems. Fix both of these issues to support Windows. Note that this commit fixes the Meson-based job in GitHub's CI. Meson auto-detects the availability of Rust, and as the Windows runner has Rust installed by default it already enabled Rust support there. But due to the above issues that job fails consistently. Install Rust on GitLab CI, as well, to improve test coverage there. Based-on-patch-by: Johannes Schindelin Based-on-patch-by: Ezekiel Newren Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano