git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

  parent reply	other threads:[~2021-08-31  3:47 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

  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 \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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