Re: [PATCH] mingw: make stderr unbuffered again

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 15, 2017, 12:48 UTC
Message-ID: <alpine.DEB.2.20.1702151332540.3496@virtualbox>
In-Reply-To: <xmqq37fga9rn.fsf@gitster.mtv.corp.google.com>

Hi Junio,

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

Show 11 quoted lines

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