Re: What's cooking in git.git (Jan 2018, #02; Tue, 9)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

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

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux