Modularisation and uutils

[Okeanos]

With the adoption of uutils (the Rust rewrite of GNU coreutils, findutils, diffutils) by Ubuntu (2) starting with Ubuntu 25.10, I am wondering whether it makes sense to discuss uutils in the context of Git for Windows (GfW) as well. The continued (increased) adoption and improvements in compatibility with GNU versions should make them a safe alternative.

They offer statically linked (pre-built) binaries of these utils for Windows (for ARM64, x86, and x64) as well. At least from an end-user perspective this is quite neat because I can just download & use them – without having to rely on MSYS2 (MinGW, …), its toolchain or related bits and pieces to provide these tools on Windows. Particularly, I can use them from Windows, e.g. PowerShell, directly and they work. So … use them instead of the GNU utils? Not entirely sure this is a useful direction to begin with:

Previously GfW was modified to allow a different OpenSSH provider (somewhat hacky but it mostly works). The work on doing the same for GPG was abandoned because it turned out not to be "manageable but hacky" but "unmaintainably hacky". Having read through the linked MSYS2 discussion pertaining to GPG I am now wondering whether this whole "pick and choose" needs a broader view instead of tailored patches that bloat the whole process to allow for some individual replacements.

What do I mean with that? I am wondering what could be done centrally (in a maintainable fashion!) to "modularize" Git for Windows and allow users to either pick (or self-provide) alternative implementations for various tools that Git for Windows needs outright or provides for useful convenience.

I am currently aware of the following bits and pieces that ship with Git for Windows where alternative Windows binaries exist (from upstream/official sources):

• coreutils
• findutils
• diffutils
• curl
• OpenSSH
• GPG
• less
• vim

Some of the upstream sources (curl, less, …) are already in use, I believe, but at the same time much of this software is also available via WinGet (community) packages allowing for (from a user perspective) easy access with a smooth installation experience using Windows built-in tooling + allowing individual updates.

As pointed out above: modifying the installer to dynamically provide compositions where users pick & choose individual replacements is non-trivial and also bloats the whole process. Additionally, it introduces a lot of surface for errors & incompatibilities that no-one can test for or foresee.

Instead, I am wondering whether the magic of git.exe and its PATH modification ("git.exe forcefully prepends its own /usr/bin/ to the PATH")should be looked at instead.

I am thinking in terms of:

• GfW provides the current batteries included environment and doesn't allow changes to it (effectively the current system minus OpenSSH-installer shenanigans for instance I introduced at have problems with portable editions). Kind of a "guaranteed to work"-version aka "safe-mode"?
• GfW provides an additional stripped down (for lack of a better term) git.exe (and bash.exe, …) + a "checklist" (POSIX-compatibility?, for lack of a better term) that can be used instead and allows "to bring your own environment"
  • relies on Windows PATH to find necessary tools
  • should (might?) provide a PATH-shim that substitutes in fallback options from the "safe-mode" environment if no other alternative is found

If people then want to use a customized experience they would install the tools they like to replace (OpenSSH, GPG, …), put it onto the Windows native PATH and start invoking the stripped down version. In case there are problems because of incompatibilities, they can always use the "safe-mode" version as a fallback.

I think this kind-of might replace the existing picker of the 3 different integration approaches as well?

There are obviously a great many unknowns & holes in this proposal & a lot of work involved if it even makes sense. So no hurt feelings on my side if this is flat out refused to be entertained. However, I would still like to hear your thoughts on this and where GfW will go in the future considering things like WinGet & uutils as well as the huge internal maintenance effort to provide all the bits and pieces that make Git work on Windows work.

[dscho]

The primary reason, and maybe even the only reason, really, for these tools to be included in Git for Windows is that they are required by Git itself. Git is very opinionated in its use of those tools. In particular, it uses them in shell scripts, and uses forward slashes and Unix type paths that are not legal or at least not correct on Windows. Git for Windows relies on the MSYS2 runtime to translate between correct Windows paths and those Unix-y paths.

So the first and foremost question must be, what is the reason to switch those tools out for Rust versions? In particular, you need to focus first on the question whether they can be used or whether they will break Git. And that's of paramount importance because breaking Git is obviously a non-option here. And I need to point out that this needs to be the main, maybe even the only focus: Does it benefit Git? If not, we can end the discussion early 😄

[Okeanos]

Yes, the path translation issue is something I briefly considered when writing this. I consider it one of the many large holes in my initial post.

Particular reasons for the interest in the Rust util versions? I personally don't have too many stakes in them beyond the fact that they offer Windows native builds without the MSYS2 translation layer that is otherwise required to interact with Unix tools on Windows (generally) making them somewhat enticing. Additionally, as rimrul pointed out, there are some performance benefits that sound wonderful to have.

As also pointed out below, I generally wanted to have some form of reference in the context of GfW concerning the uutils and I am very much satisfied with your initial responses. They broadly touch on the huge complexity of such an undertaking and in case someone (even myself) comes along again they have some food for thought.

[rimrul]

With the adoption of uutils (the Rust rewrite of GNU coreutils, findutils, diffutils) by Ubuntu (2) starting with Ubuntu 25.10, I am wondering whether it makes sense to discuss uutils in the context of Git for Windows (GfW) as well. The continued (increased) adoption and improvements in compatibility with GNU versions should make them a safe alternative.

Sure, it's an idea we could discuss.

They offer statically linked (pre-built) binaries of these utils for Windows (for ARM64, x86, and x64) as well.

While the performance of native utils (meaning coreutils, diffutils and findutils) would be nice, non-msys utils would probably break a lot of things for us. And even if we decide to bundle native utils, these prebuilt binaries are probably not what we want to go with.

Some of the upstream sources (curl, less, …) are already in use, I believe,

Well, pretty much everything we distribute has to come from some upstream. I'm not sure what your distinction for this "some" is?

but at the same time much of this software is also available via WinGet (community) packages allowing for (from a user perspective) easy access with a smooth installation experience using Windows built-in tooling + allowing individual updates.

As pointed out above: modifying the installer to dynamically provide compositions where users pick & choose individual replacements is non-trivial and also bloats the whole process. Additionally, it introduces a lot of surface for errors & incompatibilities that no-one can test for or foresee.

It seems like the mix and match approach also comes with "a lot of surface for errors & incompatibilities that no-one can test for or foresee."

I also don't think we want to allow replacements for some of the packages you listed. vim or less replacements just sound like painfully undesirable experiences. curl replacements without libcurl replacements sound like all kinds of fun and libcurl replacements without rebuilding git would need some great installer shenannigans (like the MinTTY/Conhost option), if it would work at all.

What might work is switching to MSYS2s uutils-coreutils package (after the causes for msys2/MSYS2-packages#5888 have been fixed and probably some more improvements to uutils GNU compatibility). That way we could gain some of the performance benefits of uutils (though not to the degree of native binaries) while keeping breakages to a minimum.

[Okeanos]

Some of the upstream sources (curl, less, …) are already in use, I believe,

Well, pretty much everything we distribute has to come from some upstream. I'm not sure what your distinction for this "some" is?

My thoughts were about how closely coupled the projects are to the MSYS2+GfW build chain, i.e. is it "just" a (simplified) "pull in correct source version + build it (with some patches)" or full-blown "parallel fork maintained under the umbrella of MSYS2 or GfW" situation.

You neatly laid out some of those situations with the libcurl example in your response, clarifying the gradient and consequences based on the interdependent parts.

vim or less replacements just sound like painfully undesirable experiences.

Could you expand on this?

---

To rephrase my thoughts: I have seen a number of requests for "I want to use alternative X with GfW" and was curious that no one broached the "uutils" topic yet. As a result I wanted to understand whether that was something (already) being considered (internally) and furthermore to better understand where the "fault lines" for "replacing X" are in general.

You satisfied my initial curiosity by both pointing out the (retrospectively obvious) intricate interdependencies (that I neglected to consider as an end-user) and that particular tools really shouldn't be considered for being user replaceable at all.

Thank you for taking the time to consider this and shed some light on the situation :)

[rimrul]

Some of the upstream sources (curl, less, …) are already in use, I believe,

Well, pretty much everything we distribute has to come from some upstream. I'm not sure what your distinction for this "some" is?

My thoughts were about how closely coupled the projects are to the MSYS2+GfW build chain, i.e. is it "just" a (simplified) "pull in correct source version + build it (with some patches)" or full-blown "parallel fork maintained under the umbrella of MSYS2 or GfW" situation.

Oh, in that case there are only a few things where we keep an actual forkof the upstream source: the msys2-runtime, wintoast, busybox, git and 7-zip SFX. Most other things are packaged from upstream source (with some patches), either by MSYS2 or sometimes by us. git-lfs and git-credential-manager are packaged from prebuilt binaries, because we're not that well equipped to build Go and .NET-Framework binaries.

You neatly laid out some of those situations with the libcurl example in your response, clarifying the gradient and consequences based on the interdependent parts.

vim or less replacements just sound like painfully undesirable experiences.

Could you expand on this?

Git considers vim a fallback editor that exists on every system. It has expectations about it's existence and some of it's behaviours.

It's less intertwined with less, but still kinda expects pagers to behave similar to less.

We'd also need both of them to work well with Cygwin PTYs, MinTTY, legacy Conhost and Windows Terminal.

---

To rephrase my thoughts: I have seen a number of requests for "I want to use alternative X with GfW" and was curious that no one broached the "uutils" topic yet.

I think it's mainly requests for things that people have available on Windows as either part of the OS (curl, openssh, powershell, more.com) or as part of some long established workflow (editors, gpg, putty). uutils is a bit on the unixy side, which is probably why it hasn't come up yet.

As a result I wanted to understand whether that was something (already) being considered (internally)

I don't think we have internally considered uutils so far.

and furthermore to better understand where the "fault lines" for "replacing X" are in general.

"fault lines" include (but are probably not limited to)

• how unixy something is
• library dependencies
• scripts or tools depending on tools and certain behaviours of those tools
• posix/windows conversions