From: Junio C Hamano <email@example.com>
To: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>
Subject: Re: What's cooking in git.git (Jan 2018, #02; Tue, 9)
Date: Wed, 10 Jan 2018 12:02:50 -0800 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (=?utf-8?B?IsOGdmFyIEFy?= =?utf-8?B?bmZqw7Zyw7A=?= Bjarmason"'s message of "Wed, 10 Jan 2018 08:56:00 +0100")
Ævar Arnfjörð Bjarmason <email@example.com> 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 firstname.lastname@example.org I
> think it makes sense to just document (and I can do that if you agree)
> 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
>> Will [cook in|merge to] 'next'.
> Refresh my memory, that means merge down post-2.16.0 at this point,
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.
next prev parent reply other threads:[~2018-01-10 20:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 23:33 What's cooking in git.git (Jan 2018, #02; Tue, 9) Junio C Hamano
2018-01-10 7:56 ` Ævar Arnfjörð Bjarmason
2018-01-10 20:02 ` Junio C Hamano [this message]
2018-01-10 16:25 ` Jeff Hostetler
2018-01-10 19:57 ` Junio C Hamano
2018-01-10 22:03 ` Jeff Hostetler
2018-01-18 8:56 ` Christian Couder
2018-01-18 22:31 ` Jonathan Tan
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).