[jpatte]

IMHO, "being portable" is more about "being available to many users" than "being available to many systems". Focusing on ancient and obscure systems (used by who, exactly?) while ignoring systems used by a large potential users population doesn't make a lot of sense to me. And I don't see how you can blame that on these major systems either.

Willing to specifically support archaic but important systems who desperately needs git (idk, NASA supercomputers perhaps?) is fine, but that's kind of a niche strategy; it's not about portability anymore.

[tommorris]

Git was built specifically to scratch the itch of Linux kernel developers.

Linux kernel developers tend to like making sure the Linux kernel works on as many obscure architectures as possible. See https://en.wikipedia.org/wiki/List_of_Linux_supported_archit...

Making sure Git is portable across system architectures is quite important.

Also, portability in the "being available to many systems" thing is important for a lot of developers. I build stuff that currently has to deploy on SPARC/Solaris, but there are plans to make it so that in the not-so-distant future, all that stuff will be moving to virtualized clusters of x86_64 Linux. Portability in the narrow UNIX sense is pretty damn important to a lot of people.

[jpatte]

I don't see how your example contradicts my point of view. When you move things from a fairly popular system to a widely popular system, you expect it to work as well as before. Now instead if you had chosen an obscure system nobody cared about, of course you would have loved your tools would be supported as well - but hey, you knew that choice was risky.

Of course portability is pretty damn important : it gives you the liberty to choose the system you want (depending on your needs) while keeping the same user experience everywhere. But x86_64 Linux systems (for instance) should not be supported because they run Linux : they should be supported because a whole bunch of people use them and need that support.