That and the fact that Mercurial worked on Windows renders this line very poorly researched. Then again, perhaps the author, like the title, learned just enough to write the article.

And git does work on Windows. There's even a windows logo on the official download page. https://www.git-scm.com/downloads

The originally released Git did not run on Windows.

The first Windows-compatible release was msysgit, which was effectively a mingw/msys Linux emulation layer for Windows. Not quite native, but it worked. Kind of. Not really very well at first.

The current Windows download - "Git for Windows" - is still msys-based, just with a lot of compatibility/package-management/ux-polish changes.

All that and the fact that recent Windows includes Windows Subsystem for Linux make the differentiation somewhat moot, but, essentially, Git is a *nix app.

Here's the full quote:

"What resulted was an expansive suite of programs and utilities (collectively, software) that were written in Linux, for Linux - much of which was never ported to Windows. One example of this is the popular version control system (VCS) called git. Developers could have written this software to work on Windows, but they didn't. "

It's just wrong.

Technically it's correct. It's just really odd in tone; it almost sounds like it's unusual or negative that these utilities were not written to be completely cross-platform, as if that would be a norm.

But git is not an example of software that wasn't ported to windows. It was ported to windows.

Yeah, the wording is ambiguous. It could be construed to say Git is an example of a utility that wasn't ported, or just that it was a utility that was written in Linux, for Linux.

Git for Windows relies pretty heavily on MinGW, though. And it's best used from the included bash shell.

I do want to point out that Git being built with MinGW doesn't do anything to affect its compatibility. MinGW is basically just the GCC compiler suite ported Windows. It doesn't do anything about making C code written for Linux compatible with Windows.

Now typically, when you install MinGW it also installs some tools that let you operate within Windows a little bit more like you're working under Linux, such as by installing a more sane terminal emulator and Windows-compatible ports of some popular programs e.g. grep. But all those tools and such are ports of Linux programs running on Windows, not standard Linux programs running atop a compatibility layer to allow them to work on Windows.

I mention the above because this was an unclear distinction to me originally. Additionally, this was based on my experience with MinGW some five years ago, and I don't know if everything I've described is still true. Hopefully this slight aside clarifies things for someone.

> MinGW is basically just the GCC compiler suite ported Windows.

That's where you get it wrong. MinGW is a compatibility layer that helps port unix apps to windows. Yeah, it comes with GCC, but it also comes with support for POSIX, including a unix shell and other standard components.

Claiming that MinGW was just GCC would imply that to run Git on windows would be just a matter of recompiling the source code. But it isn't.

Why is git so heavily "posix-y" in a way that e.g. svn is not?

Wasn't git created to support the development of the linux kernel? It was a linux thing first.

>I think the real (and even stronger) reason is that Linus Torvalds specifically built Git to serve as the VCS for the Linux codebase.

Mercurial was built for exactly the same reason (VCS for Linux), at the same time. Yet it has always been cross-platform.

Linus wrote it for Linux because he didn't care about whether it would work in Windows. No other reason.

And who could fault him for that. After all, why would he care or even want to invest time to make it run on Windows? It’s GPL, anyone can port it if they want to.

Git for Windows and Cygwin Git have some issues (I use them daily at work), but many of these can be entirely attributed to the limitations of Windows: CRLF, case-insensitivity in filesystems, problems with long pathnames, slow process forking, etc.

The real reason is that cmd.exe is nothing like bash/zsh/csh/etc. Every OS except Windows can use bash (or an equivalent shell) natively.

There is no advantage to writing another interface to git that is directly compatible with cmd or powershell.

Yes, he has said this in interviews. Great write up! I too keep a list of helpful commands handy: https://github.com/vinniejames/koopa-troopa adding a link to yours

Linus wrote it with the code library interface only in mind. the cli was a hodgepodge just to access the interface, and i bet he had a bunch of other specialized hacky binaries that he used for his day to day tasks.