Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html