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

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

[marat]

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.

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

[Konstantin Khomoutov]

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

> I'm proud to announce WinGit:
> an attempt to bring Git powers to 64-bit Windows.
[...]
> 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.

What is the state of Unicode support in WinGit?

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

[Marat Radchenko]

On Thursday 03 April 2014 at 17:48:08  Konstantin Khomoutov wrote:
>
> What is the state of Unicode support in WinGit?

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.

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

[Vincent van Ravesteijn]

>
> I know that build.sh is UGLY, especially openssl part.
>
> 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).
>


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

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

[Felipe Contreras]

marat@ wrote:
> 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.

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.

-- 
Felipe Contreras

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

[Heiko Voigt]

Hi Marat,

On Thu, Apr 03, 2014 at 05:18:50PM +0400, marat@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.
> 
> Like msysgit, WinGit also uses msys environment (sh/perl/etc) both during
> build-time and runtime.

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

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[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.

> I can see the need for a pure Windows solution (no msys tools at least for runtime).

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 64bit?
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 [2] (by msysgit developer).
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

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

[Johannes Schindelin]

Hi,

On Sat, 19 Apr 2014, Heiko Voigt wrote:

> On Thu, Apr 03, 2014 at 05:18:50PM +0400, marat@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

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Marat Radchenko]

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

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Heiko Voigt]

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.

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sebastian Schuberth]

On 19.04.2014 15:35, Marat Radchenko wrote:

> But in practice, msysgit is:
>   1) outdated msys that was patched in multiple ways without
>    sending patches upstream

It's not true that we are not sending patches upstream to MSYS, see [1]. 
It's just that most of them don't get included due to a lack of time 
from the MSYS maintainers, see e.g. [2].

>   2) heavily patched git, again not upstreamed

"Heavily" is relative, in fact it's not that much that I would give up 
hope on getting everything upstream. We once had put large efforts in 
bringing our stuff to upstream Git, just to over and over again being 
pulled into fussy discussions, costing way more time than developing the 
patches themselves. So at some time most of us just decided to spend 
their time more efficiently by bringing Git for Windows forward.

> 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).

I agree that MSYS is not at all that great (anymore). It simply does not 
seem to be well maintained. But neither do I trust MSYS2 (yet), which 
looks to me like a spare time project by one or two guys, both newcomers 
not part of the original MSYS team. However, if MSYS2 turns out to be 
maintained better than MSYS in the future, I'm open to base 
mingwGitDevEnv on MSYS2.

> 1) It makes sense to purge msysgit and start over. See mingwGitDevEnv [2] (by msysgit developer).

You would have been very welcomed to contribute 64-bit support to 
mingwGitDevEnv (which I'm the maintainer of). I saddens me that we blow 
out our energy on forks (without even getting in touch first) instead of 
pulling together.

[1] http://sourceforge.net/p/mingw/bugs/search/?q=msysgit
[2] http://sourceforge.net/p/mingw/bugs/1823/

-- 
Sebastian Schuberth

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

[David Kastrup]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Mon, 21 Apr 2014, Felipe Contreras wrote:
>
>> Johannes Schindelin wrote:
>> > Now, clearly you have all the motivation that is needed to get 64-bit
>> > builds of Git for Windows going, and all the motivation required to make
>> > sure that the MSVC support of the msysGit project works.
>> 
>> s/msysGit/Git/
>
> No. I meant the msysGit project; the project that maintains the current
> development environment for Git for Windows. Please do not try to
> reinterpret what I am saying.
>
>> Personally I don't see why ideally I shouldn't be able to build upstream
>> Git for Windows with mingw without leaving my Linux system.
>
> Maybe because you could not even test it properly, let alone run the test
> suite? And maybe because according to the famous "scratch your own itch"
> credo, it is actually the duty of Windows users -- i.e. users who do not
> even have your Linux system -- to fix the bugs that would never be
> encountered anywhere but Windows?

<URL:http://www.lilypond.org/gub>

The LilyPond project uses this to do automated builds for Windows,
MacOSX, FreeBSD, GNU/Linux on several CPUs.  The installation includes a
Python interpreter, GUILE, bash, and some other run-time necessary stuff
for executing scripts of various kinds.

LilyPond contains quite a few dependencies: efforts to do this natively
under the "everything that should be necessary is available somewhere"
assumptions led to bugs and time lags not dissimilar to what plagues
msysGit.

"duty of Windows users" sounds like a theory expounded by non-Windows
users.  Maintaining ports requires highly skilled programmers, and
highly skilled programmers tend to scratch a _lot_ of itches by not
using Windows in the first place.

It's been a long time since I had a grasp of the Windows/Git situation,
but my impression was that much of the msysGit stuff was done by you
yourself to scratch your personal itch of stopping people to say "Git is
not useful for large projects since it does not run under Windows" while
not actually being a Windows user yourself.

So if my memory does not do me a disfavor, you have kicked the "duty of
Windows users" theory in the curb yourself.

The developer demographic of LilyPond is similar: we actually have a
predominance of Windows users on the user mailing list.  But power users
and compile farm providers (all the cross-compiling is taking a serious
toll, even though most is in compiling the embedded example images in
the various manuals and their translations) use GNU/Linux, and where
their native system is Windows, in the form of a Ubuntu VM ("LilyDev")
put together for that purpose.

As a consequence, the bug tracker contains comparatively few and often
minor operating system specific bug reports (cf
<URL:http://code.google.com/p/lilypond/issues/list?can=1&q=OpSys%3DWindows>).
Many of them are catered for by programmers not even having a system
available for testing.  Stuff that is really only reproducible on
Windows tends to take longer to fix.  That involves things like
Font handling, PDF handling, filename issues, memory allocation handling
and others, often in the form of performance regressions that also
happen on GNU/Linux but are much less noticeable because the respective
facilities are much more efficient and thus mask unnecessarily repeated
operations much better.

While the user demographic of Git is likely leaning less towards Windows
than that of LilyPond, I expect some similar tendencies.  As a result of
the GUB crosscompiling environment, LilyPond offers a high quality
up-to-date Windows distribution with a somewhat typical installer
(though with acceptability problems that would not be dissimilar for
Git, cf
<URL:http://download.cnet.com/LilyPond/9241-2141_4-10995890.html?messageID=10589553&tag=uo;uo>).

In a way, using such a cross-building environment is a copout regarding
the defensible "duty of end users" line of thought.  But it's not like
the msysGit history supports that theory all that convincingly anyway.

-- 
David Kastrup