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

2014-04-22 Thread Johannes Schindelin
Hi,

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?

Hth,
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-22 Thread David Kastrup
Johannes Schindelin johannes.schinde...@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=1q=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=10589553tag=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
--
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: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-22 Thread Felipe Contreras
Johannes Schindelin wrote:
 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.

I don't care what you are saying, what I'm saying is that he has the motivation
to do it for the Git project. Why on Earth would he do it for the msysGit
project, when he can do it for the Git project (which would then percolate to
the msysGit project as well)?

  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?

Ideally you could.

 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?

That is your conclusion. If somebody reasonable sends reasonable patches that
make WinGit work in a way that doesn't impact negatively non-Windows users, I
don't see why they wouldn't be picked.

-- 
Felipe Contreras
--
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: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-22 Thread Johannes Schindelin
Hi Felipe,

On Tue, 22 Apr 2014, Felipe Contreras wrote:

 Johannes Schindelin wrote:
  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.
 
 I don't care what you are saying,

That is quite obvious and did not need clarifying.

Nevertheless, by stating that substitute command, you corrected me.
Except that you did not, I intended to say something different, and your
correction was quite misplaced.

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: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-21 Thread Sebastian Schuberth

On 21.04.2014 00:10, Johannes Schindelin wrote:


tests do not pass yet. (I also would like to look into getting the
performance improvement Hannes Sixt achieved by his patch [*1*] into
mingwGitDevEnv's Git installation, too.)

Whoops. Footnote *1*: https://github.com/msysgit/msysgit/commit/a0f5d4f


Dscho, this patch of Hannes is already in, see [1]. Also see the other 
files in that directory for the other MSYS patches being applied. In 
fact, mingwGitDevEnv has all MSYS patches that msysgit has except [2], 
[3] and [4] (because they mess up Bash for me and break many tests).


[1] 
https://github.com/sschuberth/mingwGitDevEnv-packages/blob/master/msys-core/0008-Do-not-start-the-fstab-observer-thread.patch
[2] 
https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0014-msys.dll-support-Unicode-console-input.patch
[3] 
https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0015-msys.dll-support-ALT-NUMPAD-console-input.patch
[4] 
https://github.com/msysgit/msysgit/blob/msys/src/rt/patches/0016-msys.dll-backport-multibyte-support-functions-from-n.patch


--
Sebastian Schuberth
--
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: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-21 Thread Johannes Schindelin
Hi Sebastian,

On Mon, 21 Apr 2014, Sebastian Schuberth wrote:

 On 21.04.2014 00:10, Johannes Schindelin wrote:
 
  tests do not pass yet. (I also would like to look into getting the
  performance improvement Hannes Sixt achieved by his patch [*1*] into
  mingwGitDevEnv's Git installation, too.)
 
  Whoops. Footnote *1*: https://github.com/msysgit/msysgit/commit/a0f5d4f
 
 Dscho, this patch of Hannes is already in, see [1].

Ah, I missed that. That's very good news!

Marat, you see that the patches *are* sent upstream.

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.

How about joining forces?

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: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-21 Thread Felipe Contreras
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/

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.

-- 
Felipe Contreras
--
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: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-20 Thread Johannes Schindelin
Hi Heiko,

On Sat, 19 Apr 2014, Heiko Voigt wrote:

 Regarding mingwGitDevEnv[2]: That is a project started by Sebastian who
 also contributes to msysgit (and Git for Windows).

In fact, Sebastian is not only a contributor. He is co-maintainer of Git
for Windows.

 It eventually can (and probably should) be a successor of the current
 situation [...]

Sebastian hinted at it in many a discussion on the msysgit mailing list
(where those people who are serious about Git for Windows development hang
out, hint, hint, hint) that mingwGitDevEnv was born out of the needs
identified while maintaining Git for Windows.

Our tentative plan is to switch with Git 2.0 (unless the timing turns out
to be unfortunate). We have to put some more effort into mingwGitDevEnv
first, though: due to the differences between the old MSys committed into
msysgit.git repository on the one hand, and the MSys environment
initialized and updated by mingwGitDevEnv on the other hand, some of the
tests do not pass yet. (I also would like to look into getting the
performance improvement Hannes Sixt achieved by his patch [*1*] into
mingwGitDevEnv's Git installation, too.)

Despite the common lack of time and of developers willing to spend time to
contribute to the Git for Windows effort, I think we are well on track,
and it will be pretty exciting when we switch to mingwGitDevEnv-based
development of Git for Windows!

Ciao,
Dscho
--
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: Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-20 Thread Johannes Schindelin
On Mon, 21 Apr 2014, Johannes Schindelin wrote:

 (I also would like to look into getting the performance improvement
 Hannes Sixt achieved by his patch [*1*] into mingwGitDevEnv's Git
 installation, too.)

Whoops. Footnote *1*: https://github.com/msysgit/msysgit/commit/a0f5d4f
--
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-19 Thread Heiko Voigt
Hi Marat,

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.
 
 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
--
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-19 Thread 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: [msysGit] Re: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-19 Thread Johannes Schindelin
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

2014-04-19 Thread 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
--
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

2014-04-19 Thread Thomas Braun
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

2014-04-19 Thread Johannes Schindelin
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-19 Thread Heiko Voigt
On Sat, Apr 19, 2014 at 05:35:07PM +0400, Marat Radchenko wrote:
  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.

Do not get me wrong. I was saying until now nobody needed it in a way
that he/she would do something about it. Of course there are many people
requesting it, but I just do not count those people anymore. You are
clearly doing something about it and thats great, I like it.

What I am trying to achieve here is that you join the msysgit community.
There already is just a very small amount of developers on the windows
side (compared to upstream). We should try to all work together. I think
it will greatly add to confusion if we have another installer of Git for
Windows. I think the msysgit community is quite open for changes like
the ones you are trying to achieve.

Regarding mingwGitDevEnv[2]: That is a project started by Sebastian who
also contributes to msysgit (and Git for Windows). It eventually can
(and probably should) be a successor of the current situation where we
always manually patch, build and commit our binaries into a git
repository. A proper package management system would greatly help here.
But AFAIK its not ready for production use yet. I guess Sebastian would
not mind contributions.

Cheers Heiko

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

2014-04-19 Thread 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.
--
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-19 Thread 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


--
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-19 Thread Sebastian Schuberth
On Sat, Apr 19, 2014 at 8:42 PM, Heiko Voigt hvo...@hvoigt.net wrote:

 But AFAIK its not ready for production use yet. I guess Sebastian would
 not mind contributions.

Not at all!

-- 
Sebastian Schuberth
--
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-09 Thread 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
--
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


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

2014-04-03 Thread 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.
--
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-03 Thread Konstantin Khomoutov
On Thu, 3 Apr 2014 17:18:50 +0400
ma...@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?
--
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: [ANNOUNCE] WinGit - native x86/x64 Git for Windows

2014-04-03 Thread 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.

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


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

2014-04-03 Thread 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
--
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