Re: [PATCH] mingw: make stderr unbuffered again

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 15, 2017, 22:22 UTC
Message-ID: <xmqqbmu32iyb.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1702151332540.3496@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 7 quoted lines

> Hi Junio,
> ...
> The hat of a person who sees how patches are reviewed before they enter
> pu/next/master/maint of git.git.
> ...
> 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*.

You wrote a lot, what you wrote were readable, and perhaps were good material to support your answer/conclusion, but you forgot to answer a simple question I asked. I think your description of where things currently are would support any of the possible answers below, and I cannot guess which one it would be.

The question was:

    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"?

Or is it "please ignore upstream and work off of Git for Windows?"

Or is it "please try to work with upstream and if you find Windows specific glitches, after checking to see if Git for Windows has already a fix for it and otherwise feed your fix to Git for Windows, so that we can upstream your fix for you, together with changes from others"?

Or is it "please try to work with upstream and if you find Windows specific glitches, after checking to see if Git for Windows has already a fix for it and otherwise upstream your fix, so that next pull from upstream into Git for Windows would have your fix"?

Or is it something else?

> FWIW I wish it were different, that git.git's `master` reflected more
> closely what the current Git for Windows version has.

Well, we two wishing the same thing together without doing anything else would make it happen.

As an experiment to see if our process can be improved, I've been meaning to suggest (which is what was behind my "question at a bit higher level" to Hannes [*1*]) asking you to throw me occasional pull requests for changes that are only about Windows specific issues, bypassing "patches on the list" for things like a hotfix to js/mingw-isatty [*2*] and use of OpenSSL SHA-1 on Windows [*3*], essentially treating Windows specific changes as "a sub-maintainer makes pull requests" we already do with Paul, Eric and Pat.

Interested parties would instead see only the pull request sent by you to me, either on the list or directly CC'ed to them, and do their own fetch to assess if it is a good idea for me to actually pull. Suggestions to the changes from bystanders like Peff's comment [*4*] may need to reproduce the patch text when sent to the list, which would burden reviewers a bit more, but they still are possible.

Such a pull-request workflow would either hide the communication from the list or force people to go to multiple places (i.e. both to the list and to GitHub comments) in order to view the whole picture, and I am still reluctant to extend it to other areas (e.g. a change that adds "#if WINDOWS" to a more generic codepath), but a trial on a limited scope may give us a better feel of how well such an updated workflow would work for us.

[References]

*1* <xmqq60kdev2r.fsf@gitster.mtv.corp.google.com>

*2* <c88612da0a62bfcbc3e278296f9d3eb010057071.1487025228.git.johannes.schindelin@gmx.de>

*3* <6a29f8c60d315a24292c1fa9f5e84df4dfdbf813.1486679254.git.johannes.schindelin@gmx.de>

*4* <20170210050237.gajicliueuvk6s5d@sigill.intra.peff.net>