Re: [msysGit] Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
Hi, On Sat, 19 Apr 2014, Heiko Voigt wrote: On Thu, Apr 03, 2014 at 05:18:50PM +0400, ma...@slonopotamus.org wrote: I'm proud to announce WinGit: an attempt to bring Git powers to 64-bit Windows. So the reason for this new package is that you need 64bit binaries? Relationship with msysgit = Unlike msysgit, WinGit is a pure-Windows binary build with MSVC. 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). Like msysgit, WinGit also uses msys environment (sh/perl/etc) both during build-time and runtime. So it is not purely 64-bit, because MSys is not. 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). 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
On Sat, Apr 19, 2014 at 05:24:33PM +0200, Johannes Schindelin wrote: Marat, please do not add to the confusion. msysGit is the name of the *development environment* for developing Git for Windows. 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. After all, there is no reason for yet another fork. 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
Am 19.04.2014 15:35, schrieb Marat Radchenko: So the reason for this new package is that you need 64bit binaries? That's the most important bit. Plus, weird ssh transfer speeds [1] caused by ansient openssh bundled in msysgit. Yes the msysgit openssh is ancient and slow. Openssh in mingGitDevEnv has proper speeds, see [1]. 1) outdated msys that was patched in multiple ways without sending patches upstream 2) heavily patched git, again not upstreamed You do realize how much work it is to send something upstream? And in the case of mingw patches have been sent upstream which are still either being reviewed or are just in a (presumably *very* long) queue. 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 [2] (by msysgit developer). I would be happy to see you contributing to the mingGitDevEnv project. 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 [3] (stalled several years ago) in msysgit tracker. After all, I needed it. [1] https://github.com/msysgit/msysgit/issues/31 [2]: https://github.com/sschuberth/mingwGitDevEnv [3]: http://code.google.com/p/msysgit/issues/detail?id=396 Actually I would need a 64bit git for windows too. The problem here is that of course everyone likes to have it, but nobody so desperatley what he/she will start to make the test suite pass. And before the test suite passes I don't think it is a good idea to use it in production. So for my part I decided to first get mingwGitDevEnv going and then start thinking about a 64bit version. [1]: https://github.com/sschuberth/mingwGitDevEnv/pull/5#issuecomment-15128748 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
Hi Marat, On Sat, 19 Apr 2014, Marat Radchenko wrote: 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 Again, this time explicitly: I wish you had done a little more research on the matter, and I wish you had participated in the msysGit community before going on to reinvent the wheel. I have nothing per se against your effort, of course, you can spend your time as you want, but please refrain from claiming things that are provably incorrect. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [msysGit] Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
On Sat, Apr 19, 2014 at 08:58:32PM +0400, Marat Radchenko wrote: On Sat, Apr 19, 2014 at 05:24:33PM +0200, Johannes Schindelin wrote: Marat, please do not add to the confusion. msysGit is the name of the *development environment* for developing Git for Windows. This confusion comes from the fact that major part of msysGit is packaged with Git for Windows to be used at runtime. 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. If you insist on msysGit-is-a-development-environment, you have to admit that msysGit is technically a fork of msys. 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. 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. After all, there is no reason for yet another fork. If there wasn't, mingwGitDevEnv would not be started. I would not consider mingwGitDevEnv a fork. It is more msysgit next generation. But it needs more work to fully replace msysgit. 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. 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 ;-) [1]: http://en.wikipedia.org/wiki/Windows_Services_for_UNIX 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
