> So the reason for this new package is that you need 64bit binaries?
That's the most important bit. Plus, weird ssh transfer speeds  caused by
ansient openssh bundled in msysgit.
> I can see the need for a pure Windows solution (no msys tools at least for
Several Git scripts are written in perl, many in shell and a couple even in
tcl/tk (oh, my). Until this is true, Git requires unix-like userland
environment: all those sh, awk, coreutils, findutils and others.
> But this sounds to me that the only thing you changed is the compiler and
That would be true *if* msysgit was really msys + mingw-built-git.
But in practice, msysgit is:
1) outdated msys that was patched in multiple ways without
sending patches upstream
2) heavily patched git, again not upstreamed
To be honest, msys isn't a great tool. After all, it's just outdated
and heavily patched cygwin. There exists msys2 project (much less outdated and
much less patched cygwin).
So, msysgit is an (outdated patched)*2 cygwin + patched git.
> What is the reason of using a closed source compiler?
It happened to be already installed on my box. Switching to another one will
require just minor tweaks to my build script. I don't have any strong reasons
for using MSVC.
> 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?
1) It makes sense to purge msysgit and start over. See mingwGitDevEnv  (by
2) I only used msys due to my unawareness of msys2 at the time of initial
WinGit hacking. Due to massive Unicode-related msys troubles, ansient perl and
svn, I plan to switch to msys2 soon.
> there are no 64 bit binaries shipped with msysgit is that nobody needed them
That's wrong. Google for 'windows x64 git' or 'msysgit x64'. People need it.
There's even an issue  (stalled several years ago) in msysgit tracker.
After all, I needed it.