From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, "Taylor Blau" <me@ttaylorr.com>,
"SZEDER Gábor" <szeder.dev@gmail.com>,
"Derrick Stolee" <stolee@gmail.com>,
"Josh Steadmon" <steadmon@google.com>,
"Clemens Fruhwirth" <clemens@endorphin.org>,
"Han-Wen Nienhuys" <hanwen@google.com>
Subject: Re: What's cooking in git.git (Aug 2021, #09; Sun, 29)
Date: Mon, 30 Aug 2021 20:39:46 -0700 [thread overview]
Message-ID: <xmqqeeaaz3i5.fsf@gitster.g> (raw)
In-Reply-To: 87tuj7xhqo.fsf@evledraar.gmail.com
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Also re your <xmqqbl5ml70u.fsf@gitster.g> I'll switch to quoting
> Message-ID's in that style, and not as
> https://lore.kernel.org/git/<msgid> links. FWIW I was doing the latter
> for the benefit of readers on the sidelines, but will switch.
I can deal with either. What I meant was that often resend of the
patch outside the context of "What's cooking" would be easier to
find the patches.
>> * ab/commit-graph-usage (2021-08-25) 7 commits
>> - commit-graph: show "unexpected subcommand" error
>> - commit-graph: show usage on "commit-graph [write|verify] garbage"
>> - commit-graph: early exit to "usage" on !argc
>> - multi-pack-index: refactor "goto usage" pattern
>> - commit-graph: use parse_options_concat()
>> - commit-graph: remove redundant handling of -h
>> - commit-graph: define common usage with a macro
>
> Taylor, SZEDER: That's at
> <cover-v4-0.7-00000000000-20210823T122854Z-avarab@gmail.com>, you
> reviwed the earlier
> <cover-0.6-00000000000-20210720T113707Z-avarab@gmail.com>, what do you
> think about this version?
>> * ab/unbundle-progress (2021-08-27) 5 commits
>
> This has outstanding feedback at
> <cover-v3-0.5-00000000000-20210826T140414Z-avarab@gmail.com> that I need
> to respond to.
OK.
>> * zh/cherry-pick-advice (2021-08-23) 1 commit
>> - cherry-pick: use better advice message
>>
>> The advice message that "git cherry-pick" gives when it asks
>> conflicted replay of a commit to be resolved by the end user has
>> been updated.
>>
>> Will merge to 'next'?
>
> I think so, I looked it over as part of browsing advice()-related
> changes, looks good to me.
Thanks.
>> * es/config-based-hooks (2021-08-19) 7 commits
>> - hook: allow out-of-repo 'git hook' invocations
>> - hook: include hooks from the config
>> - hook: allow running non-native hooks
>> - hook: introduce "git hook list"
>> - hook: allow parallel hook execution
>> - hook: run a list of hooks instead
>> - Merge branch 'ab/config-based-hooks-base' into es/config-based-hooks
>> (this branch uses ab/config-based-hooks-base.)
>>
>> Revamp the hooks subsystem to allow multiple of them to trigger
>> upon the same event and control via the configuration variables.
>>
>> Will merge to 'next'?
>> cf. <87v93wflm0.fsf@evledraar.gmail.com>
>
> This needs a re-roll based on my comments in reply to
> <20210819033450.3382652-1-emilyshaffer@google.com>. It's mostly ready as
> far as the end-state is concerneb, but e.g. will break "rebase" (a
> commit in the middle doesn't compile), leaks memory etc.
>
> It needs a re-roll of ab/config-based-hooks-base, which I was waiting on
> some of Emily's feedback to do. Looks like there's no outstanding things
> there, so iwll work on that SOON.
OK, thanks. Will mark both as expecting reroll on my end.
>> * js/advise-when-skipping-cherry-picked (2021-08-10) 2 commits
>> - SQUASH???
>> - sequencer: advise if skipping cherry-picked commit
>>
>> "git rebase" by default skips changes that are equivalent to
>> commits that are already in the history the branch is rebased onto;
>> give messages when this happens to let the users be aware of
>> skipped commits, and also teach them how to tell "rebase" to keep
>> duplicated changes.
>
> This LGTM with your proposed obviously-correct squash.
>
> Re comment about ab/retire-advice-config above: I could also just fold
> this into that series if you'd prefer, i.e. it would be one way to deal
> with the only outstanding merge conflict in advice.c between
> master..seen.
Let's see how far we can go with these two as separate topics; I do
not foresee much issues in either topic and can advance them to
'next' soonish.
>> * cb/makefile-apple-clang (2021-08-06) 3 commits
>> - build: catch clang that identifies itself as "$VENDOR clang"
>> - build: clang version may not be followed by extra words
>> - build: update detect-compiler for newer Xcode version
>>
>> Build update.
>>
>> Will merge to 'next'.
>
> Makes sense. Any reason other than lack of time that you opted not to go
> for the IMO simpler approach I suggested in
> <87bl6aypke.fsf@evledraar.gmail.com>?
I just didn't see the need for this update to be so big to deserve
such a total rewrite.
>> * ab/lib-subtest (2021-08-05) 11 commits
>> - test-lib tests: assert 1 exit code, not non-zero
>> - test-lib tests: refactor common part of check_sub_test_lib_test*()
>> - test-lib tests: avoid subshell for "test_cmp" for readability
>> - test-lib tests: assert no copy/pasted mock test code
>> - test-lib tests: get rid of copy/pasted mock test code
>> - test-lib tests: don't provide a description for the sub-tests
>> - test-lib tests: stop using a subshell in write_sub_test_lib_test()
>> - test-lib tests: split up "write and run" into two functions
>> - test-lib tests: move "run_sub_test" to a new lib-subtest.sh
>> - Merge branch 'ps/t0000-output-directory-fix' into ab/lib-subtest
>> - Merge branch 'jk/t0000-subtests-fix' into ab/lib-subtest
>>
>> Updates to the tests in t0000 to test the test framework.
>
> I think with my re-roll at
> <cover-v3-0.9-0000000000-20210805T103237Z-avarab@gmail.com> it should be
> OK to declare this good to go sooner than later. I.e. the only trouble I
> can imagine this causing in
> <patch-v3-6.9-bc79b29f3c-20210805T103237Z-avarab@gmail.com> is now easy
> to revert in isolation.
What's queued is v3, I think. In the list of messages in the thread
on page
https://lore.kernel.org/git/cover-v3-0.9-0000000000-20210805T103237Z-avarab@gmail.com/
it is still a bit disturbing to see these three versions were sent
without much reaction to the list.
>> * ab/make-tags-cleanup (2021-08-05) 5 commits
>> - Makefile: normalize clobbering & xargs for tags targets
>> - Makefile: remove "cscope.out", not "cscope*" in cscope.out target
>> - Makefile: don't use "FORCE" for tags targets
>> - Makefile: add QUIET_GEN to "cscope" target
>> - Makefile: move ".PHONY: cscope" near its target
>>
>> Build clean-up for "make tags" and friends.
>>
>> Expecting a reroll.
>> 4/5 may want a minor tweak to the log and the patch text but otherwise looks good.
>
> (Summary copied from <87v93wflm0.fsf@evledraar.gmail.com>)
>
> This entire comment has been in What's Cooking since v3 of the series,
> but v4 has been out since August 4th:
> <cover-v4-0.5-00000000000-20210804T225222Z-avarab@gmail.com>
You're right. The topic branch has the v4 but the comment in the
What's cooking report is simply stale.
>> * ab/test-tool-cache-cleanup (2021-08-24) 4 commits
>> - read-cache perf: add a perf test for refresh_index()
>> - test-tool: migrate read-cache-again to parse_options()
>> - test-tool: migrate read-cache-perf to parse_options()
>> - test-tool: split up test-tool read-cache
>>
>> Test code shuffling.
>
> I had a "take it or leave it" comment at
> <878s0nz5q2.fsf@evledraar.gmail.com>.
Thanks, I'd eject it then. It should be easy to send in updates
when the tree is otherwise more quiescent.
next prev parent reply other threads:[~2021-08-31 3:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 1:19 What's cooking in git.git (Aug 2021, #09; Sun, 29) Junio C Hamano
2021-08-30 11:00 ` Ævar Arnfjörð Bjarmason
2021-08-30 12:23 ` Han-Wen Nienhuys
2021-08-30 13:27 ` Ævar Arnfjörð Bjarmason
2021-08-30 13:58 ` Han-Wen Nienhuys
2021-08-30 23:44 ` Junio C Hamano
2021-08-31 3:39 ` Junio C Hamano [this message]
2021-09-01 5:04 ` SZEDER Gábor
2021-08-30 14:02 ` Derrick Stolee
2021-08-31 0:29 ` Junio C Hamano
2021-08-31 22:02 ` Jonathan Tan
2021-09-01 14:55 ` Junio C Hamano
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqeeaaz3i5.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=clemens@endorphin.org \
--cc=git@vger.kernel.org \
--cc=hanwen@google.com \
--cc=me@ttaylorr.com \
--cc=steadmon@google.com \
--cc=stolee@gmail.com \
--cc=szeder.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
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 NNTP newsgroup(s).