Re: What's cooking in git.git (Jan 2018, #02; Tue, 9)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 10, 2018, 20:02 UTC
- Message-ID
- <xmqqo9m11nyt.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <87vaga9mgf.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 17 quoted lines
> On Tue, Jan 09 2018, Junio C. Hamano jotted: > >> * ab/wildmatch-tests (2018-01-04) 7 commits >> (merged to 'next' on 2018-01-09 at 09f0b84098) >> + wildmatch test: create & test files on disk in addition to in-memory >> + wildmatch test: perform all tests under all wildmatch() modes >> + wildmatch test: remove dead fnmatch() test code >> + wildmatch test: use a paranoia pattern from nul_match() >> + wildmatch test: don't try to vertically align our output >> + wildmatch test: use more standard shell style >> + wildmatch test: indent with tabs, not spaces >> >> More tests for wildmatch functions. >> >> Will cook in 'next'. > > Please don't merge it down for now.
Oops, the above entry in the "What's cooking" report is totally bogus. It is not merged to 'next' yet, and 09f0b84098 does not exist in the public history of the project.
What happened was that I rewound 'next' after making a trial merge before pushing the result out. I updated the "What's cooking" report while the trial merge was in 'next', which I should have redone.
Show 17 quoted lines
>> * ab/perf-grep-threads (2018-01-04) 1 commit >> (merged to 'next' on 2018-01-09 at 8fe1d71894) >> + perf: amend the grep tests to test grep.threads >> >> More perf tests for threaded grep >> >> Will cook in 'next'. > > Re: the concern raised in xmqqa7xsaqki.fsf@gitster.mtv.corp.google.com I > think it makes sense to just document (and I can do that if you agree) > that: > > test_expect_success SOME_PREREQ,$SOME_OTHER_PREREQ,$ANOTHER_ONE [...] > > Will work as far as prereqs goes even though the variables might be > empty. It's much less verbose than the proposed alternative, and easy to > support.
OK.
>> Will [cook in|merge to] 'next'. > > Refresh my memory, that means merge down post-2.16.0 at this point, > right?
After -rc1, anything merged to 'next' will by default stay there until the final. Hotfixes will be merged to 'next' and (unless I forget) will be marked as "will merge to 'master'" when that happens, so that we will have them in the final.