On Fri, Apr 09 2021, Junio C Hamano wrote:
Thanks, brief notes on my topics & some others:
> * ab/unexpected-object-type (2021-03-27) 10 commits
> - tag: don't misreport type of tagged objects in errors
> - object tests: add test for unexpected objects in tags
> - object.c: add and use oid_is_type_or_die_msg() function
> - object.c: add a utility function for "expected type X, got Y"
> - tree.c: fix misindentation in parse_tree_gently()
> - object-name.c: make dependency on object_type order more obvious
> - object-file.c: make oid_object_info() return "enum object_type"
> - object.c: make type_from_string() return "enum object_type"
> - object.c: refactor type_from_string_gently()
> - object.c: stop supporting len == -1 in type_from_string_gently()
>
> Error reporting upon object type mismatch has been improved
>
> Expecting a reroll.
> cf. <YGBL88lYheyFmwCg@xxxxxxxxxxxxxxxxxxxxxxx>
> ... we would be much better off to say something like "somebody
> expected X to be a commit, but now somebody else expects it to be a
> blob", which is all that we can reliably say.
I split this up and will have a re-submission of it soon.
> * ab/describe-tests-fix (2021-03-01) 10 commits
> - test-lib: return 1 from test_expect_{success,failure}
> - svn tests: refactor away a "set -e" in test body
> - svn tests: remove legacy re-setup from init-clone test
> - describe tests: support -C in "check_describe"
> - describe tests: fix nested "test_expect_success" call
> - describe tests: convert setup to use test_commit
> - test-lib functions: add an --annotated-tag option to "test_commit"
> - describe tests: always assert empty stderr from "describe"
> - describe tests: refactor away from glob matching
> - describe tests: improve test for --work-tree & --dirty
>
> Various updates to tests around "git describe"
>
> Expecting a reroll.
> cf. <xmqq1rcj6hzr.fsf@gitster.g>
Let's discard it for now, I was looking it at today hoping to re-roll it
and saw that it some of the test-lib.sh changes would be a hassle for
me/you to manage with other things I have in-flight.
So I'll either submit it after that, or another version which doesn't
textually/semantically conflict like that, but in any case let's drop
this version.
> * ab/pickaxe-pcre2 (2021-02-18) 24 commits
> - pickaxe -G: don't special-case create/delete
> - pickaxe -G: terminate early on matching lines
> - xdiff-interface: support early exit in xdiff_outf()
> - xdiff-interface: allow early return from xdiff_emit_{line,hunk}_fn
> - pickaxe -S: slightly optimize contains()
> - pickaxe: rename variables in has_changes() for brevity
> - pickaxe -S: support content with NULs under --pickaxe-regex
> - pickaxe: assert that we must have a needle under -G or -S
> - pickaxe: refactor function selection in diffcore-pickaxe()
> - perf: add performance test for pickaxe
> - pickaxe/style: consolidate declarations and assignments
> - diff.h: move pickaxe fields together again
> - pickaxe: die when --find-object and --pickaxe-all are combined
> - pickaxe: die when -G and --pickaxe-regex are combined
> - pickaxe tests: test for -G, -S and --find-object incompatibility
> - pickaxe tests: add test for "log -S" not being a regex
> - pickaxe tests: add test for diffgrep_consume() internals
> - pickaxe tests: refactor to use test_commit --append --printf
> - test-lib functions: add --printf option to test_commit
> - test-lib-functions: reword "test_commit --append" docs
> - test-lib-functions: document and test test_commit --no-tag
> - grep/pcre2 tests: reword comments referring to kwset
> - Merge branch 'jk/rev-list-disk-usage' into ab/pickaxe-pcre2
> - Merge branch 'ab/test-lib' into ab/pickaxe-pcre2
>
> Rewrite the backend for "diff -G/-S" to use pcre2 engine when
> available.
>
> Needs (hopefully the final round of) reroll and its review.
> cf. <xmqqh7ksb5j7.fsf@gitster.g>, <xmqqa6qkb5fi.fsf@gitster.g>, etc.
Will re-roll this soon. Need to get to addressing your outstanding
feedback...
> * es/config-hooks (2021-03-10) 36 commits
> . run-command: stop thinking about hooks
> . git-send-email: use 'git hook run' for 'sendemail-validate'
> . bugreport: use hook_exists instead of find_hook
> . receive-pack: convert receive hooks to hook.h
> . post-update: use hook.h library
> . proc-receive: acquire hook list from hook.h
> . receive-pack: convert 'update' hook to hook.h
> . reference-transaction: look for hooks in config
> . transport: convert pre-push hook to use config
> . hook: convert 'post-rewrite' hook to config
> . hooks: convert 'post-checkout' hook to hook library
> . git-p4: use 'git hook' to run hooks
> . receive-pack: convert push-to-checkout hook to hook.h
> . read-cache: convert post-index-change hook to use config
> . rebase: teach pre-rebase to use hook.h
> . gc: use hook library for pre-auto-gc hook
> . merge: use config-based hooks for post-merge hook
> . am: convert applypatch hooks to use config
> . commit: use config-based hooks
> . hooks: allow callers to capture output
> . run-command: allow capturing of collated output
> . hook: provide stdin by string_list or callback
> . run-command: add stdin callback for parallelization
> . hook: allow specifying working directory for hooks
> . hook: allow parallel hook execution
> . run-command: allow stdin for run_processes_parallel
> . hook: support passing stdin to hooks
> . hook: introduce hook_exists()
> . hook: add 'run' subcommand
> . parse-options: parse into strvec
> . hook: implement hookcmd.<name>.skip
> . hook: teach hook.runHookDir
> . hook: include hookdir hook in list
> . hook: add list command
> . hook: scaffolding for git-hook subcommand
> . doc: propose hooks managed by the config
>
> The "hooks defined in config" topic.
FWIW I commented a bit on the status just now in another thread here:
https://lore.kernel.org/git/87tuoggwmy.fsf@xxxxxxxxxxxxxxxxxxx/
> * ds/maintenance-prefetch-fix (2021-04-06) 5 commits
> - maintenance: allow custom refspecs during prefetch
> - test-tool: test refspec input/output
> - refspec: output a refspec item
> - test-lib: use exact match for test_subcommand
> - maintenance: simplify prefetch logic
>
> The prefetch task in "git maintenance" assumed that "git fetch"
> from any remote would fetch all its local branches, which would
> fetch too much if the user is interested in only a subset of
> branches there.
>
> Expecting a reroll.
> cf. <35fa99cf-ba24-f13e-0607-f9acce2905cf@xxxxxxxxx>
And, just to add to your note, also the back & forth thread about the
need/design for the new refspec.c API here:
https://lore.kernel.org/git/xmqqsg41ut72.fsf@gitster.g/
> * ab/complete-cherry-pick-head (2021-04-07) 1 commit
> - bash completion: complete CHERRY_PICK_HEAD
>
> The command line completion (in contrib/) has learned that
> CHERRY_PICK_HEAD is a possible pseudo-ref.
>
> Will merge to 'next'?
I think so, it's trivial :)
FWIW to your suggestion of completion instead checking *_HEAD: As part
of another (abandoned for now) topic of mine I tried to exhaustively
enumerate all the magic all-caps refs just the test suite generates in
.git/FILE, and it's quite a big list.
So I found listing a new known one less scary.
Also, even though the bash completion is pretty bad about it now, I
thinkw we should aim more for it not needing to hit disk for completing
a thing like "git show REBASE_HE<TAB>" (which it'll needlessly do now).
> * ab/send-email-validate-errors (2021-04-06) 3 commits
> (merged to 'next' on 2021-04-06 at d7fb1dbde0)
> + git-send-email: improve --validate error output
> + git-send-email: refactor duplicate $? checks into a function
> + git-send-email: test full --validate output
> (this branch uses ab/perl-do-not-abuse-map.)
>
> Clean-up codepaths that implements "git send-email --validate"
> option and improves the message from it.
>
> Will merge to 'master'.
Thanks. FWIW I kept hacking on send-email a bit, and have some local
patches that bring the runtime of t9001-send-email.sh from 30 seconds to
13, and a typical invocation time for git-send-email from ~250ms on my
box to ~40-60ms).
> * ab/userdiff-tests (2021-04-08) 9 commits
> - blame tests: simplify userdiff driver test
> - blame tests: don't rely on t/t4018/ directory
> - userdiff: remove support for "broken" tests
> - userdiff tests: list builtin drivers via test-tool
> - userdiff tests: explicitly test "default" pattern
> - userdiff: add and use for_each_userdiff_driver()
> - userdiff style: normalize pascal regex declaration
> - userdiff style: declare patterns with consistent style
> - userdiff style: re-order drivers in alphabetical order
>
> A bit of code clean-up and a lot of test clean-up around userdiff
> area.
>
> Will merge to 'next'?
Please :)
But perhaps Jeff King would like to look it over first...
> * gk/gitweb-redacted-email (2021-03-31) 1 commit
> - gitweb: add "e-mail privacy" feature to redact e-mail addresses
>
> "gitweb" learned "e-mail privacy" feature to redact strings that
> look like e-mail addresses on various pages.
>
> Waiting for reviews.
> cf. <xmqq5z19k9wu.fsf@gitster.g>
FWIW it seems it's now past that per
https://lore.kernel.org/git/xmqqblaoqtjf.fsf@gitster.g/ and this note
was added before that update to the thread.
I know you know that, just noting that for the benefit of others who are
following along.
> * en/ort-readiness (2021-03-20) 13 commits
> - Add testing with merge-ort merge strategy
> - t6423: mark remaining expected failure under merge-ort as such
> - Revert "merge-ort: ignore the directory rename split conflict for now"
> - merge-recursive: add a bunch of FIXME comments documenting known bugs
> - merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a conflict
> - t: mark several submodule merging tests as fixed under merge-ort
> - merge-ort: implement CE_SKIP_WORKTREE handling with conflicted entries
> - t6428: new test for SKIP_WORKTREE handling and conflicts
> - merge-ort: support subtree shifting
> - merge-ort: let renormalization change modify/delete into clean delete
> - merge-ort: have ll_merge() use a special attr_index for renormalization
> - merge-ort: add a special minimal index just for renormalization
> - merge-ort: use STABLE_QSORT instead of QSORT where required
> (this branch is used by en/ort-perf-batch-11; uses en/ort-perf-batch-10.)
>
> Plug the ort merge backend throughout the rest of the system, and
> start testing it as a replacement for the recursive backend.
>
> Will merge to 'next'?
I'd like that, some of the ORT code is over my head currently, but
having it tested by default would be very beneficial to smoke out any
bugs sooner than later.
