[ANNOUNCE] WinGit - native x86/x64 Git for Windows

I'm proud to announce WinGit: an attempt to bring Git powers to 64-bit Windows.

WinGit is currently used only by my coworkers and isn't considered production-ready-rock-solid. Use at your own risk.

Homepage & build instructions ----------------------------- https://github.com/slonopotamus/wingit

Binaries -------- MSI packages: https://github.com/slonopotamus/wingit/releases

After installation, git.exe is ready to be used from cmd.exe or TortoiseGit. No kind of "Git Bash" or own explorer integration is provided.

Issues ------ Of course WinGit has issues: https://github.com/slonopotamus/wingit/issues?state=open

Most notable are: git documentation is not packaged, no Tcl/Tk (thus, no gitk), no SVN, no Explorer integration.

Sources ------------------

All sources are available on GitHub: https://github.com/slonopotamus/wingit

I know that build.sh is UGLY, especially openssl part.

Relationship with msysgit =========================

Unlike msysgit, WinGit is a pure-Windows binary build with MSVC.

Like msysgit, WinGit also uses msys environment (sh/perl/etc) both during build-time and runtime.

WinGit adds a few patches to Git itself on top of msysgit ones. Patches are required due to insufficient testing of MSVC builds (caused by total absence of any MSVC-built Git distributions).

All WinGit patches are sent upstream, just didn't get to master yet.

On Thu, 3 Apr 2014 17:18:50 +0400 marat@slonopotamus.org wrote:

[...]

What is the state of Unicode support in WinGit?

On Thursday 03 April 2014 at 17:48:08  Konstantin Khomoutov wrote:

I haven't seen any Unicode-related issues when using through TortoiseGit.

Command-line usage is currently broken: no UTF-8 <->cmd.exe encoding conversion is performed. Fixing this is a high-priority issue though, most likely by migrating to newer (yet-to-be-released) msys lib.

marat@ wrote:

Thank you for doing this, it's very much needed. It would be great if there was a place to list all the tools that need to be converted to C, so that neither Perl, nor a shell are needed for most of Git's operations, don't you think?

Cheers.

Hi Marat,

On Thu, Apr 03, 2014 at 05:18:50PM +0400, marat@slonopotamus.org wrote:

So the reason for this new package is that you need 64bit binaries?

I can see the need for a pure Windows solution (no msys tools at least for runtime). But this sounds to me that the only thing you changed is the compiler and 64bit? The git binaries in msysgit are already pure Windows binaries with no need of msys.dll. The only reason why so many other tools are shipped with msysgit is to run scripted commands (e.g. like gitk or rebase).

What is the reason of using a closed source compiler? Why not use the 64bit mingw that is already used to build the 64bit explorer extension to package 64bit binaries along with the 32bit ones in the installer?

Sorry if I am a little bit skeptic, but I am wondering whether it does make sense for you to join forces with msysgit instead of creating a fork? I think the main reason why there are no 64 bit binaries shipped with msysgit is that nobody needed them and the need to ship both (at least for some time).

That would also make the maintenance burden easier for you.

Cheers Heiko

Hi,

On Sat, 19 Apr 2014, Heiko Voigt wrote:

Marat, please do not add to the confusion. "msysGit" is the name of the *development environment* for developing Git for Windows. It also brings facilities to use MSVC instead of GCC.

So do not compare WinGit to msysgit (that would be like comparing Git to GCC). Compare WinGit to Git for Windows (and clarify that you mean a different WinGit than the old name of Git for Windows).

So it is not purely 64-bit, because MSys is not.

We do have a facility to build 64-bit binaries with msysGit. It is even dirt-easy: just run the two release scripts in /src/mingw-w64/, and then build Git with "make W64=1".

The real reason why Git for Windows does not ship 64-bit binaries is that they did not pass the test suite last time I tried.

And for the record: I would have welcome contributions to the Git for Windows project. I still will. After all, there is no reason for yet another fork.

Ciao, Johannes

On Sat, Apr 19, 2014 at 05:24:33PM +0200, Johannes Schindelin wrote:

This confusion comes from the fact that major part of msysGit is packaged with Git for Windows to be used at runtime.

If you insist on msysGit-is-a-development-environment, you have to admit that msysGit is technically a fork of msys.

My approach undoes this fork step and uses upstream runtime environment as-is, be it msys, msys2, Cygwin or even SUA [1]. I could even make it a noop and say "dear user, I don't care how, but please put sh/awk/find/etc on PATH to make Git work, like things normally happen in *nix world".

Actually, even if Git was pure C, things like `git filter-branch` would be almost useless without coreutils & friends.

If there wasn't, mingwGitDevEnv would not be started.

I'd say I am doing a 'rebase' instead of 'fork' by using codebase of Git for Windows (upstream Git sources with Windows-specific patches) but replacing msysGit-provided runtime environment with another one.

[1]: http://en.wikipedia.org/wiki/Windows_Services_for_UNIX

On Sat, Apr 19, 2014 at 08:58:32PM +0400, Marat Radchenko wrote:

Only the tools that are needed to run git (and some that the contributors like) are packaged in Git for Windows. For example there is no compiler or similar packaged.

Well it is a git repository that conveniently packages all the needed tools you need to build "Git for Windows" together. It is a little bit quick and dirty but it works. We have nothing against improving this situation.

I would not consider mingwGitDevEnv a fork. It is more msysgit next generation. But it needs more work to fully replace msysgit.

The downside of doing this approach is that you regularly have to update your 'rebase' and fix problems. If you integrate your changes into msysgit itself you do not have to do that anymore. Well, if it is one of your changes that breaks something, it still would be nice if you do so ;-)

Cheers Heiko

P.S.: BTW, just in case: Being criticized in open-source is good. Even though it might not feel like that. It means people care about the stuff you do and think it is important enough it deserves a reply. They just want to help you improve it.

I've created CMake files to be able to build git with MSVC without the need for msys. I haven't tested it with latest git and didn't really see the recent changes with respect to compilation with MSVC.

But, if you're interested, let me know.

Vincent