Git development
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: Johannes Sixt <j6t@kdbg.org>, Junio C Hamano <gitster@pobox.com>,
	GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH] t7400: add BSLASHPSPEC prerequisite to 'add with \\ in path'
Date: Mon, 1 May 2017 12:59:14 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1705011221480.3480@virtualbox> (raw)
In-Reply-To: <4f88f1ec-eedc-1249-ef12-238a73d1dc7a@ramsayjones.plus.com>

Hi Ramsay,


On Sun, 30 Apr 2017, Ramsay Jones wrote:

> On 29/04/17 11:44, Johannes Schindelin wrote:
> 
> > On Sat, 29 Apr 2017, Johannes Sixt wrote:
> >> Am 29.04.2017 um 02:15 schrieb Ramsay Jones:
> >>> On 28/04/17 20:54, Johannes Sixt wrote:
> >>>> Am 28.04.2017 um 05:09 schrieb Junio C Hamano:
> >>>>> Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
> 
> >> I don't observe these failures. Are you using a vanila MSYS2
> >> environment?
> > 
> > Please note that the "vanilla MSYS2 environment" is *not* expected to
> > pass the test suite when compiling in MINGW mode. In fact, it is
> > expected to fail.
> > 
> > In 2015, I made a couple of changes to the MSYS2 runtime in
> > preparation for the big bump to Git for Windows 2.x (which switched
> > from the old MSys environment to the new MSYS2 environment), and
> > released Git for Windows 2.5.0 with a heavily patched msys-2.0.dll. My
> > hope was that those changes would be welcome in the MSYS2 project, but
> > well, they kinda weren't. So I was forced to abandon my original plan
> > to contribute all of those fixes to "upstream MSYS2".
> 
> Oh WOW. I didn't know you were maintaining your own version of
> the MSYS2 runtime. That must be a huge PITA. :-D

I manage. The long years of maintaining Git for Windows as a fork of Git
helps. I use the exact same strategy: merging rebases.

Amazingly, the Cygwin project itself has been quite open to accept my
patches, and the only problem there is time: I would like to contribute
more patches there, I get really valuable feedback, and I just need to
find the time to iterate the patches so they can be accepted.

> > I even started collecting the exact tests that are failing with the
> > vanilla MSYS2 runtime vs Git for Windows' fork, when I still had hopes
> > that we could test things with AppVeyor (but the builds were already
> > too slow, we hit the timeout even before trying to run the tests, so I
> > gave up on that front):
> > 
> > 	REM MSYS2's runtime does not carry Git for Windows' tweaks yet, so these
> > 	tests cannot pass:
> > 	set GIT_SKIP_TESTS='t0003 t0006 t0024 t1100 t1400 t1402 t1501 t1504 t1506
> > 	t1508 t1513 t3001 t3070 t3200 t3301 t3400 t3404 t3513 t3703 t4116 t4150
> > 	t4208 t4211 t5000 t5001 t5002 t5004 t5500 t5601 t5602 t5603 t5801 t6006
> > 	t6018 t6041 t6130 t6132 t6300 t7201 t7400 t7501 t7502 t8002 t8006 t9001
> > 	t9350 t9700 t9903'
> 
> I have only (fairly) recently installed MSYS2, so I've only ever
> run the MinGW64 test-suite once, which for me failed on tests:
> 
>    t0003, t0006, t0026, t0060, t0200, t0204, t1100, t1400, t1402,
>    t1501, t1504, t1506, t1508, t1513, t3001, t3070, t3200, t3301,
>    t3400, t3404, t3406, t3703, t3903, t3905, t4208, t4211, t5000,
>    t5500, t5516, t5601, t5602, t5603, t5615, t5801, t6006, t6018,
>    t6030, t6038, t6130, t6132, t6300, t7201, t7400, t7401, t7406,
>    t7501, t7610, t9001, t9020, t9350, t9700, t9903
> 
> (which I found somewhat intimidating!).

Yes, I expected the number to rise. Note that almost every patch in Git
for Windows' fork fixes a couple of test scripts at a time.

> So, as you would expect, it hasn't improved much! :-P
> 
> Hmm, I was hoping to use this installation to test some git patches
> on MinGW, but that looks like a lost cause. I may as well save some
> disk space and delete it!

Hopefully I (or other Git for Windows contributors) will have some time to
make installing a Git for Windows development environment as easy as

	git clone --depth 1 https://github.com/git-for-windows/git-skd-64

Then you do not even need to worry to keep a local installation
up-to-date. You'd just reclone when (if) needed.

Ciao,
Dscho

  reply	other threads:[~2017-05-01 10:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-28  1:53 [PATCH] t7400: add BSLASHPSPEC prerequisite to 'add with \\ in path' Ramsay Jones
2017-04-28  3:09 ` Junio C Hamano
2017-04-28 19:54   ` Johannes Sixt
2017-04-29  0:15     ` Ramsay Jones
2017-04-29  6:46       ` Johannes Sixt
2017-04-29 10:44         ` Johannes Schindelin
2017-04-30 18:00           ` Ramsay Jones
2017-05-01 10:59             ` Johannes Schindelin [this message]
2017-04-30 17:33         ` Ramsay Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1705011221480.3480@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=ramsay@ramsayjones.plus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox