Re: What's cooking in git.git (Aug 2016, #08; Wed, 24)

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 26, 2016, 16:04 UTC
Message-ID: <xmqqa8fzjz3q.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1608261607050.4924@virtualbox>

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

Show 18 quoted lines

> On Wed, 24 Aug 2016, Junio C Hamano wrote:
>
>> * rt/help-unknown (2016-08-18) 2 commits
>>  - help: make option --help open man pages only for Git commands
>>  - help: introduce option --command-only
>> 
>>  "git nosuchcommand --help" said "No manual entry for gitnosuchcommand",
>>  which was not intuitive, given that "git nosuchcommand" said "git:
>>  'nosuchcommand' is not a git command".
>> 
>>  Waiting for the review discussion to settle.
>
> Not only that. For a week now, two of my build jobs have been failing (the
> one testing `pu` verbatim and the one testing Git for Windows' patches
> rebased on top of `pu`) because the test does not actually test what was
> just built, but relies on the Git man pages to be installed.
>
> So it needs more than just the review discussion to settle.

Ah, sorry for being inaccurate.

A topic may not be ready to be merged down to the next integration branch before being re-rolled. I say "Waiting for a reroll" when I saw review comments and responses have produced enough material to go into a reroll and the ball is in the submitter's court. While the review is still ongoing, I just label it differently to as a reminder to myself that it is premature for me to jump up and down and demand "Can we have a reroll pretty-please now?" This was in that latter kind when I labelled it.

I think the reviews on the topic has settled and I should have marked it as "Waiting for a reroll", but during the prerelease period, I do not have time to pay too much attention on things outside 'master' and fix-up topics that are moving through 'next' to 'master' aiming to become part of the upcoming release, so the marking was left behind [*1*]. My bad.

[Footnotes]

*1* It follows that it would not be unusual if the tip of 'pu' does
    not even build during the time.  Being able to test it does not
    contribute much to catching the remaining bug in the release
    candidates and I'd really like to see all of us paying more
    attention to the tip of 'master'.  A statement "With topic X
    that is still in 'next', A works" is not all that interesting
    unless it is accompanied by "And A used to work in the previous
    release, but broken in 'master'." at this point in a development
    cycle.