Re: [PATCH] mingw: make stderr unbuffered again

From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Johannes Sixt <j6t@kdbg.org>,
	Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH] mingw: make stderr unbuffered again
Date: Wed, 15 Feb 2017 13:48:46 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1702151332540.3496@virtualbox> (raw)
In-Reply-To: <xmqq37fga9rn.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Tue, 14 Feb 2017, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> OK.  Should this go directly to 'master', as the isatty thing is
> >> already in?
> >
> > From my point of view, it is not crucial. The next Git for Windows
> > version will have it, of course, and Hannes is always running with his
> > set of patches, he can easily cherry-pick this one, too.
> 
> What hat were you wearing when you said the above "From my point of
> view"?

The hat of a person who sees how patches are reviewed before they enter
pu/next/master/maint of git.git.

If that review had anything to do with Windows, and refused to accept
patches unless they work correctly on Windows, I would agree that it is a
wise idea to fast-track important fixes for Windows.

But that is not the case. Quite often `pu`, sometimes `next`, and rarely
even `master` are regularly broken on Windows.

The only branch that is tested very stringently on Windows, and into which
nothing is allowed that breaks on Windows, is git-for-windows/git's
`master` branch.

BTW this is not just an opinion, this is just an account of the current
state.

Once you accept that this is reality, you will understand why I *dared* to
say that a criticial Windows-specific fix needs to be fast-tracked to
git-for-windows/git's `master`, but not into git.git's `master` branch.

FWIW I wish it were different, that git.git's `master` reflected more
closely what the current Git for Windows version has. If you are
attentive, you will have noticed that I continuously work toward that
goal. I frequently "upstream patches" from Git for Windows[*1*], even if
it seems that the influx of new patches is higher than the rate of patches
that make it into git.git's `master`. And even if I am often asked to
change these patches so much that it is virtually guaranteed that they
regress (hence my recently increasing reluctance to accept each and every
reviewer's suggestions as "must implement").

Ciao,
Johannes

Footnote *1*: Yes, I even "upstream patches" from developers other than
myself, trying to shield contributors from having to send their patches as
mails and to cope with the reviewers' suggestions that may, or may not,
make sense. This makes my life harder, but I believe that the alternative
would be *not* to have those patches in git.git *at all*.