From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, Johannes Sixt <j6t@kdbg.org>,
Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH] mingw: make stderr unbuffered again
Date: Tue, 14 Feb 2017 10:48:44 -0800 [thread overview]
Message-ID: <xmqq37fga9rn.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1702141545380.3496@virtualbox> (Johannes Schindelin's message of "Tue, 14 Feb 2017 15:47:05 +0100 (CET)")
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"? Were you the "Git for Windows" maintainer, or were you a
contributor and a member of the Git development community that works
to improve the upstream? If it was not clear, I was asking the
question to you wearing the latter hat.
To put it differently, what is our position, as the upstream
developers, toward those who are on Windows and wants to build from
the source? It's not just Hannes.
Is our position "unless you are extremely competent and are willing
to cherry-pick missing things from Git for Windows tree as needed,
we recommend you to build Git for Windows source instead"?
It is inevitable that the upstream lags behind in Windows specific
changes. Even though you have been trickling Windows specific
changes (both things in compat/ and also changes to the generic
parts, updating "c == '/'" to "is_dir_sep(c)") in, and I have been
accepting them for the past few years, in order to reduce the size
of the patch pile Git for Windows needs on top of the upstream,
until the patch pile becomes empty, it will always be the case.
So I won't object if that were our position. I just need to know
what it is to adjust my expectations, and as far as I am concerned,
you and Hannes are the two people whose thinking I'd trust regarding
what to do with/to Windows users; even though I keep saying "our"
position, I am asking yours and Hannes's.
Thanks.
next prev parent reply other threads:[~2017-02-14 18:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 22:34 [PATCH] mingw: make stderr unbuffered again Johannes Schindelin
2017-02-13 22:39 ` Junio C Hamano
2017-02-14 14:47 ` Johannes Schindelin
2017-02-14 18:45 ` Johannes Sixt
2017-02-14 18:58 ` Junio C Hamano
2017-02-15 12:32 ` Johannes Schindelin
2017-02-15 20:45 ` Johannes Sixt
2017-02-16 17:10 ` Johannes Schindelin
2017-02-16 17:55 ` Johannes Sixt
2017-02-16 18:01 ` Junio C Hamano
2017-02-14 18:48 ` Junio C Hamano [this message]
2017-02-15 12:48 ` Johannes Schindelin
2017-02-15 22:22 ` Junio C Hamano
2017-02-15 23:34 ` Junio C Hamano
2017-02-17 16:00 ` Johannes Schindelin
2017-02-17 23:49 ` Junio C Hamano
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=xmqq37fga9rn.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=jeffhost@microsoft.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