threads / discuss / 56864

What's cooking in git.git (Nov 2021, #03; Tue, 9)

Subject: What's cooking in git.git (Nov 2021, #03; Tue, 9)

## tl;dr

15 messages between Nov 10, 2021 and Nov 13, 2021.

replies: 14people: 6as markdown or json

Junio C Hamano· Nov 10, 2021, 00:59 UTC · lore

Here are the topics that have been cooking in my tree. Commits prefixed with '+' are in 'next' (being in 'next' is a sign that a topic is stable enough to be used and are candidate to be in a future release). Commits prefixed with '-' are only in 'seen', which means nothing more than that I have found them of interest for some reason (like "it may have hard-to-resolve conflicts with another topic already in flight" or "this may turn out to be useful"). Do not read too much into a topic being in (or not in) 'seen'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them.

Git 2.34-rc2 has been tagged with a few more regression fixes. Thank you all for finding, reporting and fixing them so quickly.

Copies of the source code to Git live in many repositories, and the following is a list of the ones I push into or their mirrors. Some repositories have only a subset of branches.

With maint, master, next, seen, todo:
	git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://kernel.googlesource.com/pub/scm/git/git/
	https://github.com/git/git/
	https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
	https://github.com/gitster/git/

Even though the preformatted documentation in HTML and man format are not sources, they are published in these repositories for convenience (replace "htmldocs" with "manpages" for the manual pages):

	git://git.kernel.org/pub/scm/git/git-htmldocs.git/
	https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
	https://www.kernel.org/pub/software/scm/git/

-------------------------------------------------- [New Topics]

* ak/fetch-not-overwrite-any-current-branch (2021-11-08) 2 commits
 - receive-pack: protect current branch for bare repository worktree
 - fetch: protect branches checked out in all worktrees
 "git fetch" without the "--update-head-ok" option ought to protect
 a checked out branch from getting updated, to prevent the working
 tree that checks it out to go out of sync.  The code was written
 before the use of "git worktree" got widespread, and only checked
 the branch that was checked out in the current worktree, which has
 been updated.
 Reroll exists.
* jk/test-bitmap-fix (2021-11-05) 1 commit
 - test_bitmap_hashes(): handle repository without bitmaps
 Tighten code for testing pack-bitmap.
 Will merge to 'next'.
* jk/jump-merge-with-pathspec (2021-11-09) 1 commit
 - git-jump: pass "merge" arguments to ls-files
 The "merge" subcommand of "git jump" (in contrib/) silently ignored
 pathspec and other parameters.
 Will merge to 'next'.

-------------------------------------------------- [Graduated to 'master']

* ab/parse-options-cleanup (2021-11-09) 1 commit
  (merged to 'next' on 2021-11-09 at b2b859289b)
 + parse-options.[ch]: revert use of "enum" for parse_options()
 Last minute fix to the update already in 'master'.
* ad/ssh-signing-testfix (2021-11-05) 1 commit
  (merged to 'next' on 2021-11-09 at f5ff9c35ad)
 + t/lib-git.sh: fix ACL-related permissions failure
 Fix ssh-signing test to work on a platform where the default ACL is
 overly loose to upset OpenSSH (reported on an installation of Cygwin).
* ar/fix-git-pull-no-verify (2021-10-28) 1 commit
  (merged to 'next' on 2021-11-01 at 74677b0a76)
 + pull: honor --no-verify and do not call the commit-msg hook
 "git pull --no-verify" did not affect the underlying "git merge".
* ar/no-verify-doc (2021-10-29) 1 commit
  (merged to 'next' on 2021-11-01 at f6809a9ddb)
 + Document positive variant of commit and merge option "--no-verify"
 Doc update.
* rd/http-backend-code-simplification (2021-10-25) 1 commit
  (merged to 'next' on 2021-11-01 at f45b33890c)
 + http-backend: remove a duplicated code branch
 Code simplification.
* vd/pthread-setspecific-g11-fix (2021-11-03) 1 commit
  (merged to 'next' on 2021-11-03 at b4fce69914)
 + async_die_is_recursing: work around GCC v11.x issue on Fedora
 One CI task based on Fedora image noticed a not-quite-kosher
 consturct recently, which has been corrected.

-------------------------------------------------- [Stalled]

* mp/absorb-submodule-git-dir-upon-deinit (2021-10-07) 1 commit
 - submodule: absorb git dir instead of dying on deinit
 "git submodule deinit" for a submodule whose .git metadata
 directory is embedded in its working tree refused to work, until
 the submodule gets converted to use the "absorbed" form where the
 metadata directory is stored in superproject, and a gitfile at the
 top-level of the working tree of the submodule points at it.  The
 command is taught to convert such submodules to the absorbed form
 as needed.
 Expecting a reroll.
 cf. <xmqqwnmopqqk.fsf@gitster.g>
* ar/submodule-update (2021-10-13) 9 commits
 . submodule--helper: rename helper functions
 . submodule--helper: remove unused helpers
 . submodule: move core cmd_update() logic to C
 . submodule--helper: run update using child process struct
 . submodule--helper: allow setting superprefix for init_submodule()
 . submodule--helper: refactor get_submodule_displaypath()
 . submodule--helper: rename helpers for update-clone
 . submodule--helper: get remote names from any repository
 . submodule--helper: split up ensure_core_worktree()
 Rewrite of "git submodule update" in C.
 Kicked out of 'seen' to make room for es/superproject-aware-submodules
 which is among the topics this topic stomps on.
* cf/fetch-set-upstream-while-detached (2021-07-06) 1 commit
 - fetch: fix segfault on --set-upstream while on a detached HEAD
 "git fetch --set-upstream" while on detached HEAD segfaulted
 instead of noticing that such an operation did not make sense.
 Getting tired of waiting for a reroll; will discard.

-------------------------------------------------- [Cooking]

* jk/strbuf-addftime-seconds-since-epoch (2021-11-04) 1 commit
 - strbuf_addftime(): handle "%s" manually
 The "--date=format:<strftime>" gained a workaround for the lack of
 system support for a non-local timezone to handle "%s" placeholder.
* js/ci-no-directional-formatting (2021-11-04) 1 commit
 - ci: disallow directional formatting
 CI has been taught to catch some Unicode directional formatting
 sequence that can be used in certain mischief.
* tw/var-default-branch (2021-11-03) 1 commit
 - var: add GIT_DEFAULT_BRANCH variable
 "git var GIT_DEFAULT_BRANCH" is a way to see what name is used for
 the newly created branch if "git init" is run.
* ab/mark-leak-free-tests-even-more (2021-11-01) 15 commits
 - leak tests: mark some fast-import tests as passing with SANITIZE=leak
 - leak tests: mark some config tests as passing with SANITIZE=leak
 - leak tests: mark some status tests as passing with SANITIZE=leak
 - leak tests: mark some clone tests as passing with SANITIZE=leak
 - leak tests: mark some add tests as passing with SANITIZE=leak
 - leak tests: mark some diff tests as passing with SANITIZE=leak
 - leak tests: mark some apply tests as passing with SANITIZE=leak
 - leak tests: mark some notes tests as passing with SANITIZE=leak
 - leak tests: mark some update-index tests as passing with SANITIZE=leak
 - leak tests: mark some rev-parse tests as passing with SANITIZE=leak
 - leak tests: mark some rev-list tests as passing with SANITIZE=leak
 - leak tests: mark some misc tests as passing with SANITIZE=leak
 - leak tests: mark most gettext tests as passing with SANITIZE=leak
 - leak tests: mark "sort" test as passing SANITIZE=leak
 - leak tests: mark a read-tree test as passing SANITIZE=leak
 More tests are marked as leak-free.
* if/redact-packfile-uri (2021-10-29) 2 commits
 - http-fetch: redact url on die() message
 - fetch-pack: redact packfile urls in traces
 Redact the path part of packfile URI that appears in the trace output.
* ew/test-wo-fsync (2021-10-29) 1 commit
 - tests: disable fsync everywhere
 Allow running our tests while disabling internal fsync.
* ja/doc-cleanup (2021-11-09) 10 commits
 - init doc: --shared=0xxx does not give umask but perm bits
 - doc: git-init: clarify file modes in octal.
 - doc: git-http-push: describe the refs as pattern pairs
 - doc: uniformize <URL> placeholders' case
 - doc: use three dots for indicating repetition instead of star
 - doc: git-ls-files: express options as optional alternatives
 - doc: use only hyphens as word separators in placeholders
 - doc: express grammar placeholders between angle brackets
 - doc: split placeholders as individual tokens
 - doc: fix git credential synopsis
 Doc update.
 Will merge to 'next'.
* re/color-default-reset (2021-10-28) 3 commits
 - color: allow colors to be prefixed with "reset"
 - color: support "default" to restore fg/bg color
 - color: add missing GIT_COLOR_* white/black constants
 "default" and "reset" colors have been added to our palette.
* jc/fix-first-object-walk (2021-10-29) 2 commits
 - docs: add headers in MyFirstObjectWalk
 - docs: fix places that break compilation in MyFirstObjectWalk
 Doc update.
* jc/unsetenv-returns-an-int (2021-10-29) 1 commit
  (merged to 'next' on 2021-11-01 at a11670a5a5)
 + unsetenv(3) returns int, not void
 The compatibility implementation for unsetenv(3) were written to
 mimic ancient, non-POSIX, variant seen in an old glibc; it has been
 changed to return an integer to match the more modern era.
 Will cook in 'next'.
* mc/clean-smudge-with-llp64 (2021-11-03) 8 commits
  (merged to 'next' on 2021-11-03 at fe5160a170)
 + clean/smudge: allow clean filters to process extremely large files
 + odb: guard against data loss checking out a huge file
 + git-compat-util: introduce more size_t helpers
 + odb: teach read_blob_entry to use size_t
 + t1051: introduce a smudge filter test for extremely large files
 + test-lib: add prerequisite for 64-bit platforms
 + test-tool genzeros: generate large amounts of data more efficiently
 + test-genzeros: allow more than 2G zeros in Windows
 The clean/smudge conversion code path has been prepared to better
 work on platforms where ulong is narrower than size_t.
 Will cook in 'next'.
* pw/diff-color-moved-fix (2021-10-27) 15 commits
 - diff --color-moved: intern strings
 - diff: use designated initializers for emitted_diff_symbol
 - diff --color-moved-ws=allow-indentation-change: improve hash lookups
 - diff --color-moved: stop clearing potential moved blocks
 - diff --color-moved: shrink potential moved blocks as we go
 - diff --color-moved: unify moved block growth functions
 - diff --color-moved: call comparison function directly
 - diff --color-moved-ws=allow-indentation-change: simplify and optimize
 - diff: simplify allow-indentation-change delta calculation
 - diff --color-moved: avoid false short line matches and bad zerba coloring
 - diff --color-moved=zebra: fix alternate coloring
 - diff --color-moved: rewind when discarding pmb
 - diff --color-moved: factor out function
 - diff --color-moved: clear all flags on blocks that are too short
 - diff --color-moved: add perf tests
 Long-overdue correctness and performance update to "diff
 --color-moved" feature.
* ab/generate-command-list (2021-11-05) 10 commits
 - generate-cmdlist.sh: don't parse command-list.txt thrice
 - generate-cmdlist.sh: replace "grep' invocation with a shell version
 - generate-cmdlist.sh: do not shell out to "sed"
 - generate-cmdlist.sh: stop sorting category lines
 - generate-cmdlist.sh: replace for loop by printf's auto-repeat feature
 - generate-cmdlist.sh: run "grep | sort", not "sort | grep"
 - generate-cmdlist.sh: don't call get_categories() from category_list()
 - generate-cmdlist.sh: spawn fewer processes
 - generate-cmdlist.sh: trivial whitespace change
 - command-list.txt: sort with "LC_ALL=C sort"
 Build optimization.
* jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
  (merged to 'next' on 2021-10-29 at ad4753e668)
 + pull: --ff-only should make it a noop when already-up-to-date
 "git pull --ff-only" and "git pull --rebase --ff-only" should make
 it a no-op to attempt pulling from a remote that is behind us, but
 instead the command errored out by saying it was impossible to
 fast-forward, which may technically be true, but not a useful thing
 to diagnose as an error.  This has been corrected.
 Will cook in 'next'.
* ab/sh-retire-helper-functions (2021-10-21) 6 commits
  (merged to 'next' on 2021-11-03 at 4b49d9f4be)
 + git-sh-setup: remove "sane_grep", it's not needed anymore
 + git-sh-setup: remove unused sane_egrep() function
 + git-instaweb: unconditionally assume that gitweb is mod_perl capable
 + Makefile: remove $(NO_CURL) from $(SCRIPT_DEFINES)
 + Makefile: remove $(GIT_VERSION) from $(SCRIPT_DEFINES)
 + Makefile: move git-SCRIPT-DEFINES adjacent to $(SCRIPT_DEFINES)
 Make a few helper functions unused and then lose them.
 Will cook in 'next'.
* ow/stash-count-in-status-porcelain-output (2021-10-21) 2 commits
  (merged to 'next' on 2021-10-29 at 1a01b886e5)
 + status: print stash info with --porcelain=v2 --show-stash
 + status: count stash entries in separate function
 Allow "git status --porcelain=v2" to show the number of stash
 entries with --show-stash like the normal output does.
 Will cook in 'next'.
* tb/plug-pack-bitmap-leaks (2021-10-28) 9 commits
  (merged to 'next' on 2021-11-01 at 47d218862b)
 + pack-bitmap.c: more aggressively free in free_bitmap_index()
 + pack-bitmap.c: don't leak type-level bitmaps
 + midx.c: write MIDX filenames to strbuf
 + builtin/multi-pack-index.c: don't leak concatenated options
 + builtin/repack.c: avoid leaking child arguments
 + builtin/pack-objects.c: don't leak memory via arguments
 + t/helper/test-read-midx.c: free MIDX within read_midx_file()
 + midx.c: don't leak MIDX from verify_midx_file
 + midx.c: clean up chunkfile after reading the MIDX
 Leakfix.
 Will cook in 'next'.
* es/pretty-describe-more (2021-11-01) 3 commits
 - pretty: add abbrev option to %(describe)
 - pretty: add tag option to %(describe)
 - pretty.c: rework describe options parsing for better extensibility
 Extend "git log --format=%(describe)" placeholder to allow passing
 selected command-line options to the underlying "git describe"
 command.
* fs/ssh-signing-key-lifetime (2021-10-27) 8 commits
 - ssh signing: make fmt-merge-msg consider key lifetime
 - ssh signing: make verify-tag consider key lifetime
 - ssh signing: make git log verify key lifetime
 - ssh signing: make verify-commit consider key lifetime
 - ssh signing: add key lifetime test prereqs
 - ssh signing: use sigc struct to pass payload
 - Merge branch 'fs/ssh-signing-fix' into fs/ssh-signing-key-lifetime
 - Merge branch 'fs/ssh-signing' into fs/ssh-signing-key-lifetime
 Extend the signing of objects with SSH keys and learn to pay
 attention to the key validity time range when verifying.
* jc/doc-submitting-patches-choice-of-base (2021-10-25) 2 commits
 - (wip) reword the final review part
 - SubmittingPatchs: clarify choice of base and testing
 Extend the guidance to choose the base commit to build your work
 on, and hint/nudge contributors to read others' changes.
* gc/remote-with-fewer-static-global-variables (2021-10-28) 6 commits
 - remote: add struct repository parameter to external functions
 - remote: die if branch is not found in repository
 - remote: remove the_repository->remote_state from static methods
 - remote: use remote_state parameter internally
 - remote: move static variables into per-repository struct
 - t5516: add test case for pushing remote refspecs
 Code clean-up to eventually allow information on remotes defined
 for an arbitrary repository to be read.
 Will merge to 'next'?
* jk/loosen-urlmatch (2021-10-12) 1 commit
  (merged to 'next' on 2021-10-25 at f66ca39ebe)
 + urlmatch: add underscore to URL_HOST_CHARS
 Treat "_" as any other URL-valid characters in an URL when matching
 the per-URL configuration variable names.
 Will cook in 'next'.
* ab/config-based-hooks-2 (2021-11-01) 18 commits
 - run-command: remove old run_hook_{le,ve}() hook API
 - receive-pack: convert push-to-checkout hook to hook.h
 - read-cache: convert post-index-change to use hook.h
 - commit: convert {pre-commit,prepare-commit-msg} hook to hook.h
 - git-p4: use 'git hook' to run hooks
 - send-email: use 'git hook run' for 'sendemail-validate'
 - git hook run: add an --ignore-missing flag
 - hooks: convert worktree 'post-checkout' hook to hook library
 - hooks: convert non-worktree 'post-checkout' hook to hook library
 - merge: convert post-merge to use hook.h
 - am: convert applypatch-msg to use hook.h
 - rebase: convert pre-rebase to use hook.h
 - hook API: add a run_hooks_l() wrapper
 - am: convert {pre,post}-applypatch to use hook.h
 - gc: use hook library for pre-auto-gc hook
 - hook API: add a run_hooks() wrapper
 - hook: add 'run' subcommand
 - Merge branch 'ab/config-based-hooks-1' into ab/config-based-hooks-2
 More "config-based hooks".
* so/stash-staged (2021-10-28) 2 commits
  (merged to 'next' on 2021-10-29 at 50335e8eeb)
 + stash: get rid of unused argument in stash_staged()
  (merged to 'next' on 2021-10-25 at 68b88e35c4)
 + stash: implement '--staged' option for 'push' and 'save'
 "git stash" learned the "--staged" option to stash away what has
 been added to the index (and nothing else).
 Will cook in 'next'.
* vd/sparse-sparsity-fix-on-read (2021-10-27) 3 commits
 - sparse-index: update do_read_index to ensure correct sparsity
 - sparse-index: add ensure_correct_sparsity function
 - test-read-cache.c: prepare_repo_settings after config init
 Ensure that the sparseness of the in-core index matches the
 index.sparse configuration specified by the repository immediately
 after the on-disk index file is read.
 Will merge to 'next'?
* jc/fix-ref-sorting-parse (2021-10-20) 2 commits
  (merged to 'next' on 2021-10-29 at e3ec6e8e77)
 + for-each-ref: delay parsing of --sort=<atom> options
 + Merge branch 'ab/ref-filter-leakfix' into jc/fix-ref-sorting-parse
 Things like "git -c branch.sort=bogus branch new HEAD", i.e. the
 operation modes of the "git branch" command that do not need the
 sort key information, no longer errors out by seeing a bogus sort
 key.
 Will cook in 'next'.
* jc/tutorial-format-patch-base (2021-10-23) 1 commit
  (merged to 'next' on 2021-10-29 at 67ff1a5a77)
 + MyFirstContribution: teach to use "format-patch --base=auto"
 Teach and encourage first-time contributors to this project to
 state the base commit when they submit their topic.
 Will cook in 'next'.
* js/branch-track-inherit (2021-10-18) 1 commit
 - branch: add flags and config to inherit tracking
 "git -c branch.autosetupmerge=inherit branch new old" makes "new"
 to have the same upstream as the "old" branch, instead of marking
 "old" itself as its upstream.
 Under discussion.
 cf. <87a6j6tbsv.fsf@gmgdl.gmail.com>
* jh/builtin-fsmonitor-part2 (2021-10-21) 29 commits
 - t7527: test status with untracked-cache and fsmonitor--daemon
 - fsmonitor: force update index after large responses
 - fsmonitor--daemon: use a cookie file to sync with file system
 - fsmonitor--daemon: periodically truncate list of modified files
 - t/perf/p7519: add fsmonitor--daemon test cases
 - t/perf/p7519: speed up test on Windows
 - t/helper/test-chmtime: skip directories on Windows
 - t/perf: avoid copying builtin fsmonitor files into test repo
 - t7527: create test for fsmonitor--daemon
 - t/helper/fsmonitor-client: create IPC client to talk to FSMonitor Daemon
 - help: include fsmonitor--daemon feature flag in version info
 - fsmonitor--daemon: implement handle_client callback
 - compat/fsmonitor/fsm-listen-darwin: implement FSEvent listener on MacOS
 - compat/fsmonitor/fsm-listen-darwin: add macos header files for FSEvent
 - compat/fsmonitor/fsm-listen-win32: implement FSMonitor backend on Windows
 - fsmonitor--daemon: create token-based changed path cache
 - fsmonitor--daemon: define token-ids
 - fsmonitor--daemon: add pathname classification
 - fsmonitor--daemon: implement 'start' command
 - fsmonitor--daemon: implement 'run' command
 - compat/fsmonitor/fsm-listen-darwin: stub in backend for Darwin
 - compat/fsmonitor/fsm-listen-win32: stub in backend for Windows
 - fsmonitor--daemon: implement 'stop' and 'status' commands
 - fsmonitor--daemon: add a built-in fsmonitor daemon
 - fsmonitor: document builtin fsmonitor
 - fsmonitor: use IPC to query the builtin FSMonitor daemon
 - fsmonitor: config settings are repository-specific
 - fsmonitor-ipc: create client routines for git-fsmonitor--daemon
 - fsmonitor: enhance existing comments
 Built-in fsmonitor (part 2).
* ld/sparse-diff-blame (2021-10-27) 3 commits
 - blame: enable and test the sparse index
 - diff: enable and test the sparse index
 - Merge branch 'vd/sparse-reset' into ld/sparse-diff-blame
 (this branch uses vd/sparse-reset.)
 Teach diff and blame to work well with sparse index.
 Expecting a reroll.
 cf. <YXgpqJIS2OgOgS+k@nand.local>
* ns/remerge-diff (2021-10-27) 9 commits
 - doc/diff-options: explain the new --remerge-diff option
 - show, log: adapt Elijah Newren's changes to common tmp-objdir API
 - show, log: provide a --remerge-diff capability
 - merge-ort: capture and print ll-merge warnings in our preferred fashion
 - ll-merge: add API for capturing warnings in a strbuf instead of stderr
 - merge-ort: add ability to record conflict messages in a file
 - merge-ort: mark a few more conflict messages as omittable
 - Merge branch 'ns/tmp-objdir' into ns/remerge-diff
 - Merge branch 'ns/tmp-objdir' into ns/remerge-diff
 (this branch uses ns/tmp-objdir.)
 A new presentation for two-parent merge "--remerge-diff" can be
 used to show the difference between mechanical (and possibly
 conflicted) merge results and the recorded resolution.
 On hold.
 This is Elijah's remerge-diff rebased on ns/tmp-objdir to share the
 "create objects temporarily, only to discard without committing
 them to longer-term storage" infrastructure with another topic.
* ns/tmp-objdir (2021-10-27) 4 commits
  (merged to 'next' on 2021-10-27 at 001a18c0e1)
 + fixup! tmp-objdir: new API for creating temporary writable databases
 + fixup! tmp-objdir: new API for creating temporary writable databases
  (merged to 'next' on 2021-10-23 at 358d376f61)
 + tmp-objdir: disable ref updates when replacing the primary odb
 + tmp-objdir: new API for creating temporary writable databases
 (this branch is used by ns/batched-fsync and ns/remerge-diff.)
 New interface into the tmp-objdir API to help in-core use of the
 quarantine feature.
 On hold.
 cf. <xmqqo87auqda.fsf@gitster.g>
* vd/sparse-reset (2021-10-27) 8 commits
 - unpack-trees: improve performance of next_cache_entry
 - reset: make --mixed sparse-aware
 - reset: make sparse-aware (except --mixed)
 - reset: integrate with sparse index
 - reset: expand test coverage for sparse checkouts
 - sparse-index: update command for expand/collapse test
 - reset: preserve skip-worktree bit in mixed reset
 - reset: rename is_missing to !is_in_reset_tree
 (this branch is used by ld/sparse-diff-blame.)
 Various operating modes of "git reset" have been made to work
 better with the sparse index.
 Will merge to 'next'?
* pw/fix-some-issues-in-reset-head (2021-10-01) 12 commits
 - rebase -m: don't fork git checkout
 - rebase --apply: set ORIG_HEAD correctly
 - rebase --apply: fix reflog
 - reset_head(): take struct rebase_head_opts
 - rebase: cleanup reset_head() calls
 - reset_head(): make default_reflog_action optional
 - reset_head(): factor out ref updates
 - reset_head(): remove action parameter
 - reset_head(): don't run checkout hook if there is an error
 - reset_head(): fix checkout
 - rebase: factor out checkout for up to date branch
 - Merge branch 'pw/rebase-of-a-tag-fix' into pw/fix-some-issues-in-reset-head
 Fix "some issues" in a helper function reset_head().
 Expecting a reroll.
 Needs a lot better explanation, including what the issues are,
 which codepaths the helper is used and to do what, and tests to
 protect the fixes.
* es/superproject-aware-submodules (2021-11-04) 4 commits
 - submodule: record superproject gitdir during 'update'
 - submodule: record superproject gitdir during absorbgitdirs
 - introduce submodule.superprojectGitDir record
 - t7400-submodule-basic: modernize inspect() helper
 A configuration variable in a submodule points at the location of
 the superproject it is bound to (RFC).
* tp/send-email-completion (2021-10-28) 2 commits
  (merged to 'next' on 2021-11-01 at 7104356cc0)
 + send-email docs: add format-patch options
 + send-email: programmatically generate bash completions
 The command line complation for "git send-email" options have been
 tweaked to make it easier to keep it in sync with the command itself.
 Will cook in 'next'.
* ns/batched-fsync (2021-10-27) 9 commits
  (merged to 'next' on 2021-10-27 at eb2a3afdd1)
 + Merge branch 'ns/tmp-objdir' into ns/batched-fsync
  (merged to 'next' on 2021-10-25 at e45c907d41)
 + core.fsyncobjectfiles: performance tests for add and stash
 + core.fsyncobjectfiles: tests for batch mode
 + unpack-objects: use the bulk-checkin infrastructure
 + update-index: use the bulk-checkin infrastructure
 + core.fsyncobjectfiles: add windows support for batch mode
 + core.fsyncobjectfiles: batched disk flushes
 + bulk-checkin: rename 'state' variable and separate 'plugged' boolean
 + Merge branch 'ns/tmp-objdir' into ns/batched-fsync
 (this branch uses ns/tmp-objdir.)
 The "core.fsyncobjectfiles" configuration variable can now be set
 to "batch" for improved performance.
 On hold.
 cf. <xmqqo87auqda.fsf@gitster.g>
* en/zdiff3 (2021-09-20) 2 commits
 - update documentation for new zdiff3 conflictStyle
 - xdiff: implement a zealous diff3, or "zdiff3"
 "Zealous diff3" style of merge conflict presentation has been added.
* js/scalar (2021-10-27) 15 commits
 - scalar: accept -C and -c options before the subcommand
 - scalar: implement the `version` command
 - scalar: implement the `delete` command
 - scalar: teach 'reconfigure' to optionally handle all registered enlistments
 - scalar: allow reconfiguring an existing enlistment
 - scalar: implement the `run` command
 - scalar: teach 'clone' to support the --single-branch option
 - scalar: implement the `clone` subcommand
 - scalar: implement 'scalar list'
 - scalar: let 'unregister' handle a deleted enlistment directory gracefully
 - scalar: 'unregister' stops background maintenance
 - scalar: 'register' sets recommended config and starts maintenance
 - scalar: create test infrastructure
 - scalar: start documenting the command
 - scalar: create a rudimentary executable
 Add pieces from "scalar" to contrib/.
 What's the status of this thing?
* ms/customizable-ident-expansion (2021-09-01) 1 commit
 - keyword expansion: make "$Id$" string configurable
 Instead of "$Id$", user-specified string (like $FreeBSD$) can be
 used as an in-blob placeholder for keyword expansion.
 What's the status of this one?  Meh?
* ab/refs-errno-cleanup (2021-10-16) 21 commits
  (merged to 'next' on 2021-10-29 at 3f57147176)
 + refs API: post-migration API renaming [2/2]
 + refs API: post-migration API renaming [1/2]
 + refs API: don't expose "errno" in run_transaction_hook()
 + refs API: make expand_ref() & repo_dwim_log() not set errno
 + refs API: make resolve_ref_unsafe() not set errno
 + refs API: make refs_ref_exists() not set errno
 + refs API: make refs_resolve_refdup() not set errno
 + refs tests: ignore ignore errno in test-ref-store helper
 + refs API: ignore errno in worktree.c's find_shared_symref()
 + refs API: ignore errno in worktree.c's add_head_info()
 + refs API: make files_copy_or_rename_ref() et al not set errno
 + refs API: make loose_fill_ref_dir() not set errno
 + refs API: make resolve_gitlink_ref() not set errno
 + refs API: remove refs_read_ref_full() wrapper
 + refs/files: remove "name exist?" check in lock_ref_oid_basic()
 + reflog tests: add --updateref tests
 + refs API: make refs_rename_ref_available() static
 + refs API: make parse_loose_ref_contents() not set errno
 + refs API: make refs_read_raw_ref() not set errno
 + refs API: add a version of refs_resolve_ref_unsafe() with "errno"
 + branch tests: test for errno propagating on failing read
 The "remainder" of hn/refs-errno-cleanup topic.
 Will cook in 'next'.
* ab/only-single-progress-at-once (2021-11-03) 8 commits
 - progress.c: add & assert a "global_progress" variable
 - various *.c: use isatty(0|2), not isatty(STDIN_FILENO|STDERR_FILENO)
 - pack-bitmap-write.c: don't return without stop_progress()
 - progress.c: add temporary variable from progress struct
 - progress.c tests: test some invalid usage
 - progress.c tests: make start/stop commands on stdin
 - progress.c test helper: add missing braces
 - leak tests: fix a memory leaks in "test-progress" helper
 Further tweaks on progress API.
* hn/reftable (2021-10-08) 19 commits
 - Add "test-tool dump-reftable" command.
 - reftable: add dump utility
 - reftable: implement stack, a mutable database of reftable files.
 - reftable: implement refname validation
 - reftable: add merged table view
 - reftable: add a heap-based priority queue for reftable records
 - reftable: reftable file level tests
 - reftable: read reftable files
 - reftable: generic interface to tables
 - reftable: write reftable files
 - reftable: a generic binary tree implementation
 - reftable: reading/writing blocks
 - Provide zlib's uncompress2 from compat/zlib-compat.c
 - reftable: (de)serialization for the polymorphic record type.
 - reftable: add blocksource, an abstraction for random access reads
 - reftable: utility functions
 - reftable: add error related functionality
 - reftable: add LICENSE
 - hash.h: provide constants for the hash IDs
 The "reftable" backend for the refs API, without integrating into
 the refs subsystem.
Johannes Schindelin· Nov 10, 2021, 12:47 UTC · re: Junio C Hamano · lore

js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Hi Junio,
On Tue, 9 Nov 2021, Junio C Hamano wrote:
Show 20 quoted lines
> * js/scalar (2021-10-27) 15 commits
>  - scalar: accept -C and -c options before the subcommand
>  - scalar: implement the `version` command
>  - scalar: implement the `delete` command
>  - scalar: teach 'reconfigure' to optionally handle all registered enlistments
>  - scalar: allow reconfiguring an existing enlistment
>  - scalar: implement the `run` command
>  - scalar: teach 'clone' to support the --single-branch option
>  - scalar: implement the `clone` subcommand
>  - scalar: implement 'scalar list'
>  - scalar: let 'unregister' handle a deleted enlistment directory gracefully
>  - scalar: 'unregister' stops background maintenance
>  - scalar: 'register' sets recommended config and starts maintenance
>  - scalar: create test infrastructure
>  - scalar: start documenting the command
>  - scalar: create a rudimentary executable
>
>  Add pieces from "scalar" to contrib/.
>
>  What's the status of this thing?

It is on hold, for two reasons: we're in the -rc phase now, and I think we all need to focus on it.

Ciao, Dscho

P.S.: The second reason is that I was uncertain as to your decision regarding Stolee's thread about the optimal final location for Scalar. Since it seems that we can actually go forward with `contrib/scalar/` even if you eventually decide you prefer another place, I plan on submitting a new iteration with adjustments for v2.34.0, after that release.

Ævar Arnfjörð Bjarmason· Nov 10, 2021, 13:42 UTC · re: Johannes Schindelin · lore

Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

On Wed, Nov 10 2021, Johannes Schindelin wrote:
Show 36 quoted lines
> Hi Junio,
>
> On Tue, 9 Nov 2021, Junio C Hamano wrote:
>
>> * js/scalar (2021-10-27) 15 commits
>>  - scalar: accept -C and -c options before the subcommand
>>  - scalar: implement the `version` command
>>  - scalar: implement the `delete` command
>>  - scalar: teach 'reconfigure' to optionally handle all registered enlistments
>>  - scalar: allow reconfiguring an existing enlistment
>>  - scalar: implement the `run` command
>>  - scalar: teach 'clone' to support the --single-branch option
>>  - scalar: implement the `clone` subcommand
>>  - scalar: implement 'scalar list'
>>  - scalar: let 'unregister' handle a deleted enlistment directory gracefully
>>  - scalar: 'unregister' stops background maintenance
>>  - scalar: 'register' sets recommended config and starts maintenance
>>  - scalar: create test infrastructure
>>  - scalar: start documenting the command
>>  - scalar: create a rudimentary executable
>>
>>  Add pieces from "scalar" to contrib/.
>>
>>  What's the status of this thing?
>
> It is on hold, for two reasons: we're in the -rc phase now, and I think we
> all need to focus on it.
>
> Ciao,
> Dscho
>
> P.S.: The second reason is that I was uncertain as to your decision
> regarding Stolee's thread about the optimal final location for Scalar.
> Since it seems that we can actually go forward with `contrib/scalar/` even
> if you eventually decide you prefer another place, I plan on submitting a
> new iteration with adjustments for v2.34.0, after that release.

Whatever anyone thinks about Stolee's thread/proposal (https://lore.kernel.org/git/b67bbef4-e4c3-b6a7-1c7f-7d405902ef8b@gmail.com/) it's clear that the proposals outlined there describe an entirely theoretical end-state for scalar that don't line up with the state of these patches.

That's not just my opinion, here's Stolee agreeing with that: https://lore.kernel.org/git/9eb8fd45-c8a5-0320-6d38-56389bef193d@gmail.com/

Re: the "status of this thing" I think it's the same it's been for the
last two months:

I've been pointing out things that are objectively broken, and the response has been pretty much everything except inline commentary on proposed fixups I've suggested to fix those observed bugs.

The latest being this patch ready to apply on top of js/scalar with no response for almost 2 weeks now: https://lore.kernel.org/git/patch-1.1-86fb8d56307-20211028T185016Z-avarab@gmail.com

I'll be the first to admit that *parts* of that are definitely an opinionated change-on-top.

I also think anyone who'd look at it would agree that it raises issues that I think could most generously be described as a disconnect between your commit messages & patches.

Up to and including them making suggestions of running certain commands either can't work, or don't work as described.

I'll let this be my last word on this whole scalar series saga. I'll hedge that & say that if you'd like to meaningfully respond to the fixups I've been suggesting I'm happy to re-engage with you.

"Meaningfully" as in inline commentary on the patch I'm suggesting explaining why certain things are not OK, don't provide an example of specific things that don't work/work before/after etc.

That being said no E-Mail like this would be complete without a plainly worded last few paragraphs, so here goes:

I find it hard to square your comments in other areas about inclusivity & assuming good faith from other contributors with my experience in trying to help in moving this scalar thing along.

My honest intentions in this area are just to help what I see as a useful feature in need of some fixes along.

I've really not been obstinately insisting that you take all my suggestions. I'd have been fine with most of the points I've raised just being addressed with something to the effect of "we know <X> is broken, but that's OK due to <Y>" in relevant commit messages.

But getting even something terse like that in reply has taken a lot of time & energy on my part.

No hard feelings on my side, although admittedly some baffled frustration. I do respect you and the work you do, I suspect that on your side (at least on this topic) that's now closer to "routing the E-Mails to /dev/null", at least it seems that way from my side.

If you'd like to talk about it (even privately, or over other media) I'd be happy to. Right now it feel like I've done something to end up your your shitlist, and I honestly don't know what that could be.

Junio C Hamano· Nov 11, 2021, 18:25 UTC · re: Johannes Schindelin · lore

Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 5 quoted lines
> P.S.: The second reason is that I was uncertain as to your decision
> regarding Stolee's thread about the optimal final location for Scalar.
> Since it seems that we can actually go forward with `contrib/scalar/` even
> if you eventually decide you prefer another place, I plan on submitting a
> new iteration with adjustments for v2.34.0, after that release.

When "make install" at the top-level of the tree starts installing "scalar", I'd prefer to see it outside contrib/. That is the only preference I can think of right now. Before that happens, if there is a way to install it, e.g. "cd contrib/scalar && make install", as long as it is clear that it is not yet official, I have no problems with.

There is no hard rule that "git" has to be the only top-level command the end-user interacts with. We already ship "gitk" and "git-gui" with us, and adding "scalar" to the mix is OK. Some people may love it, and others may hate its design choices with passion, but that is the same for "gitk" and "git-gui" already.

Johannes Schindelin· Nov 12, 2021, 09:32 UTC · re: Junio C Hamano · lore

Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Hi Junio,
On Thu, 11 Nov 2021, Junio C Hamano wrote:
Show 14 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > P.S.: The second reason is that I was uncertain as to your decision
> > regarding Stolee's thread about the optimal final location for Scalar.
> > Since it seems that we can actually go forward with `contrib/scalar/`
> > even if you eventually decide you prefer another place, I plan on
> > submitting a new iteration with adjustments for v2.34.0, after that
> > release.
>
> When "make install" at the top-level of the tree starts installing
> "scalar", I'd prefer to see it outside contrib/.  That is the only
> preference I can think of right now.  Before that happens, if there is a
> way to install it, e.g. "cd contrib/scalar && make install", as long as
> it is clear that it is not yet official, I have no problems with.

Okay, I will rework the patch series so that you can call `make -C contrib/scalar install`. It is a bit premature, but might help users try it out.

Show 5 quoted lines
> There is no hard rule that "git" has to be the only top-level
> command the end-user interacts with.  We already ship "gitk" and
> "git-gui" with us, and adding "scalar" to the mix is OK.  Some
> people may love it, and others may hate its design choices with
> passion, but that is the same for "gitk" and "git-gui" already.
True.

Thanks, Dscho

Johannes Schindelin· Nov 10, 2021, 13:04 UTC · re: Junio C Hamano · lore

jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Hi Junio,
On Tue, 9 Nov 2021, Junio C Hamano wrote:
Show 11 quoted lines
> * jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
>   (merged to 'next' on 2021-10-29 at ad4753e668)
>  + pull: --ff-only should make it a noop when already-up-to-date
>
>  "git pull --ff-only" and "git pull --rebase --ff-only" should make
>  it a no-op to attempt pulling from a remote that is behind us, but
>  instead the command errored out by saying it was impossible to
>  fast-forward, which may technically be true, but not a useful thing
>  to diagnose as an error.  This has been corrected.
>
>  Will cook in 'next'.

I would like to register a vote for advancing this into v2.34.0, still. It is not only technically a regression, it bit me in Git for Windows' automation. If my experience is any indication, that change of behavior would not be welcome among Git users, and it would be preferable to publish v2.34.0 without this regression.

Ciao, Dscho

Junio C Hamano· Nov 10, 2021, 17:20 UTC · re: Johannes Schindelin · lore

Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 16 quoted lines
> On Tue, 9 Nov 2021, Junio C Hamano wrote:
>
>> * jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
>>   (merged to 'next' on 2021-10-29 at ad4753e668)
>>  + pull: --ff-only should make it a noop when already-up-to-date
>>
>>  "git pull --ff-only" and "git pull --rebase --ff-only" should make
>>  it a no-op to attempt pulling from a remote that is behind us, but
>>  instead the command errored out by saying it was impossible to
>>  fast-forward, which may technically be true, but not a useful thing
>>  to diagnose as an error.  This has been corrected.
>>
>>  Will cook in 'next'.
>
> I would like to register a vote for advancing this into v2.34.0,
> still.

I didn't recall I did it as a regression fix, but as a fix for relatively old change that is already in released version(s) in the field. If the breakage is new between 2.33.0 and 'master', I think it is a good idea to merge it down.

Thanks.
Alex Henrie· Nov 10, 2021, 19:00 UTC · re: Junio C Hamano · lore

Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

On Wed, Nov 10, 2021 at 10:21 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 24 quoted lines
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 9 Nov 2021, Junio C Hamano wrote:
> >
> >> * jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
> >>   (merged to 'next' on 2021-10-29 at ad4753e668)
> >>  + pull: --ff-only should make it a noop when already-up-to-date
> >>
> >>  "git pull --ff-only" and "git pull --rebase --ff-only" should make
> >>  it a no-op to attempt pulling from a remote that is behind us, but
> >>  instead the command errored out by saying it was impossible to
> >>  fast-forward, which may technically be true, but not a useful thing
> >>  to diagnose as an error.  This has been corrected.
> >>
> >>  Will cook in 'next'.
> >
> > I would like to register a vote for advancing this into v2.34.0,
> > still.
>
> I didn't recall I did it as a regression fix, but as a fix for
> relatively old change that is already in released version(s) in the
> field.  If the breakage is new between 2.33.0 and 'master', I think
> it is a good idea to merge it down.

For what it's worth, I also consider this to be a (small) regression introduced in 2.33.0. So I'd also like to vote for fixing it in 2.34.

-Alex
Johannes Schindelin· Nov 10, 2021, 19:09 UTC · re: Junio C Hamano · lore

Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Hi Junio,
On Wed, 10 Nov 2021, Junio C Hamano wrote:
Show 23 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 9 Nov 2021, Junio C Hamano wrote:
> >
> >> * jc/fix-pull-ff-only-when-already-up-to-date (2021-10-29) 1 commit
> >>   (merged to 'next' on 2021-10-29 at ad4753e668)
> >>  + pull: --ff-only should make it a noop when already-up-to-date
> >>
> >>  "git pull --ff-only" and "git pull --rebase --ff-only" should make
> >>  it a no-op to attempt pulling from a remote that is behind us, but
> >>  instead the command errored out by saying it was impossible to
> >>  fast-forward, which may technically be true, but not a useful thing
> >>  to diagnose as an error.  This has been corrected.
> >>
> >>  Will cook in 'next'.
> >
> > I would like to register a vote for advancing this into v2.34.0,
> > still.
>
> I didn't recall I did it as a regression fix, but as a fix for
> relatively old change that is already in released version(s) in the
> field.  If the breakage is new between 2.33.0 and 'master', I think
> it is a good idea to merge it down.

I can say with conviction that this is a very recent change of behavior, as I needed this quick-fix on Oct 30: https://github.com/git-for-windows/build-extra/commit/fb311a97cf82243ea1fe4036f1b180f5a3e6bc7f

I don't recall the particular details how this fix came about, as it was the day of -rc0 (and I don't remember whether I needed this _before_ or _after_ Git for Windows -rc0 was released). All I remember is that an automated build broke because it created a local commit and then expected `git pull --ff-only` to succeed (because the remote was not ahead, but it necessarily was behind the local HEAD).

The change of behavior might have been introduced by v2.33.1, or by v2.34.0-rc0.

So yeah, I would argue that it is a regression introduced in this cycle.

Ciao, Dscho

Junio C Hamano· Nov 10, 2021, 19:17 UTC · re: Johannes Schindelin · lore

Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 20 quoted lines
>> I didn't recall I did it as a regression fix, but as a fix for
>> relatively old change that is already in released version(s) in the
>> field.  If the breakage is new between 2.33.0 and 'master', I think
>> it is a good idea to merge it down.
>
> I can say with conviction that this is a very recent change of behavior,
> as I needed this quick-fix on Oct 30:
> https://github.com/git-for-windows/build-extra/commit/fb311a97cf82243ea1fe4036f1b180f5a3e6bc7f
>
> I don't recall the particular details how this fix came about, as it was
> the day of -rc0 (and I don't remember whether I needed this _before_ or
> _after_ Git for Windows -rc0 was released). All I remember is that an
> automated build broke because it created a local commit and then expected
> `git pull --ff-only` to succeed (because the remote was not ahead, but it
> necessarily was behind the local HEAD).
>
> The change of behavior might have been introduced by v2.33.1, or by
> v2.34.0-rc0.
>
> So yeah, I would argue that it is a regression introduced in this cycle.

Yeah, I was agreeing with you. Together with the simple-ipc thing, we will have two fixes in the final one on top of -rc2; hopefully these would be the last ones ;-)

Thanks.
Emily Shaffer· Nov 11, 2021, 22:19 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Once more, updates to submodule-UX-overhaul related work.
On Tue, Nov 09, 2021 at 04:59:31PM -0800, Junio C Hamano wrote:
Show 18 quoted lines
> --------------------------------------------------
> [Stalled]
> 
> * ar/submodule-update (2021-10-13) 9 commits
>  . submodule--helper: rename helper functions
>  . submodule--helper: remove unused helpers
>  . submodule: move core cmd_update() logic to C
>  . submodule--helper: run update using child process struct
>  . submodule--helper: allow setting superprefix for init_submodule()
>  . submodule--helper: refactor get_submodule_displaypath()
>  . submodule--helper: rename helpers for update-clone
>  . submodule--helper: get remote names from any repository
>  . submodule--helper: split up ensure_core_worktree()
> 
>  Rewrite of "git submodule update" in C.
> 
>  Kicked out of 'seen' to make room for es/superproject-aware-submodules
>  which is among the topics this topic stomps on.

There is some discussion on es/superproject-aware-submodules, and whether it is still needed. I think it is, but I'll say more downthread, instead of next to this topic.

Show 15 quoted lines
> --------------------------------------------------
> [Cooking]
> 
> * gc/remote-with-fewer-static-global-variables (2021-10-28) 6 commits
>  - remote: add struct repository parameter to external functions
>  - remote: die if branch is not found in repository
>  - remote: remove the_repository->remote_state from static methods
>  - remote: use remote_state parameter internally
>  - remote: move static variables into per-repository struct
>  - t5516: add test case for pushing remote refspecs
> 
>  Code clean-up to eventually allow information on remotes defined
>  for an arbitrary repository to be read.
> 
>  Will merge to 'next'?

What's still blocking this from being merged? Anything? Release schedule?

Show 9 quoted lines
> * js/branch-track-inherit (2021-10-18) 1 commit
>  - branch: add flags and config to inherit tracking
> 
>  "git -c branch.autosetupmerge=inherit branch new old" makes "new"
>  to have the same upstream as the "old" branch, instead of marking
>  "old" itself as its upstream.
> 
>  Under discussion.
>  cf. <87a6j6tbsv.fsf@gmgdl.gmail.com>
Got confirmation this week that Josh is actively working on the next reroll.
Show 21 quoted lines
> * ab/config-based-hooks-2 (2021-11-01) 18 commits
>  - run-command: remove old run_hook_{le,ve}() hook API
>  - receive-pack: convert push-to-checkout hook to hook.h
>  - read-cache: convert post-index-change to use hook.h
>  - commit: convert {pre-commit,prepare-commit-msg} hook to hook.h
>  - git-p4: use 'git hook' to run hooks
>  - send-email: use 'git hook run' for 'sendemail-validate'
>  - git hook run: add an --ignore-missing flag
>  - hooks: convert worktree 'post-checkout' hook to hook library
>  - hooks: convert non-worktree 'post-checkout' hook to hook library
>  - merge: convert post-merge to use hook.h
>  - am: convert applypatch-msg to use hook.h
>  - rebase: convert pre-rebase to use hook.h
>  - hook API: add a run_hooks_l() wrapper
>  - am: convert {pre,post}-applypatch to use hook.h
>  - gc: use hook library for pre-auto-gc hook
>  - hook API: add a run_hooks() wrapper
>  - hook: add 'run' subcommand
>  - Merge branch 'ab/config-based-hooks-1' into ab/config-based-hooks-2
> 
>  More "config-based hooks".

I think I owe another review, but as always with these topics, I wrote a lot of the code so I'm not sure how much I can really help. Other eyes appreciated.

Show 8 quoted lines
> * es/superproject-aware-submodules (2021-11-04) 4 commits
>  - submodule: record superproject gitdir during 'update'
>  - submodule: record superproject gitdir during absorbgitdirs
>  - introduce submodule.superprojectGitDir record
>  - t7400-submodule-basic: modernize inspect() helper
> 
>  A configuration variable in a submodule points at the location of
>  the superproject it is bound to (RFC).

To summarize the discussion from here: Ævar suggested this topic might not be necessary anymore, and that we should rely on in-process discovery of the superproject's gitdir. However, after some more thought, I think it's valuable to strive for a definitive way to tell "yes, I am a submodule" - and I'd like for this topic to be it. I'm planning a reroll (and an explanation in the cover letter), and to drop language referring to that as a "cache" (because it isn't a cheap version of an operation the submodule would be doing otherwise). I will also add another patch to demonstrate how we can use that new information as a point of truth, instead of a performance shim.

---

Jonathan Tan: WIP v2 Conditional config includes remotes based on remote URL https://lore.kernel.org/git/cover.1635527389.git.jonathantanmy%40google.com

Additional discussion ongoing, Jonathan is working on another reroll, with a substantially different implementation but same user-facing feature. I think this discussion can benefit from reviews with an open mind - this is another effort to solve "how can a team ship configs for anybody developing their project, in the least painful (to the user) way possible?" In other words, this is a spiritual successor to the "remote-suggested hooks" topic, in that we are still trying to solve the same problem.

 - Emily
Emily Shaffer· Nov 11, 2021, 22:40 UTC · re: Emily Shaffer · lore

Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

On Thu, Nov 11, 2021 at 02:19:20PM -0800, Emily Shaffer wrote:
> 
> Once more, updates to submodule-UX-overhaul related work.
[...]
Show 12 quoted lines
> 
> Jonathan Tan: WIP v2 Conditional config includes remotes based on remote URL
> https://lore.kernel.org/git/cover.1635527389.git.jonathantanmy%40google.com
> 
> Additional discussion ongoing, Jonathan is working on another reroll,
> with a substantially different implementation but same user-facing
> feature. I think this discussion can benefit from reviews with an open
> mind - this is another effort to solve "how can a team ship configs for
> anybody developing their project, in the least painful (to the user) way
> possible?" In other words, this is a spiritual successor to the
> "remote-suggested hooks" topic, in that we are still trying to solve the
> same problem.
Seems I slipped and missed a few others too.

Glen Choo: make create_branch accept any repository https://lore.kernel.org/git/20211111171643.13805-1-chooglen@google.com/

More cleanup of implicit the_repository, this time in create_branch().

Glen Choo: RFC: Branches with --recurse-submodules https://lore.kernel.org/git/kl6lv912uvjv.fsf%40chooglen-macbookpro.roam.corp.google.com

Some deeper discussion of branching strategy with regard to recursing into submodules. This would be a really good one to follow and weigh in on, because it is an unusual case where Git will need to be opinionated about workflow in order to be useful, so we'd better be sure our opinion is a good one.

 - Emily
Junio C Hamano· Nov 11, 2021, 22:58 UTC · re: Emily Shaffer · lore

Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Emily Shaffer <emilyshaffer@google.com> writes:
Show 15 quoted lines
>> * gc/remote-with-fewer-static-global-variables (2021-10-28) 6 commits
>>  - remote: add struct repository parameter to external functions
>>  - remote: die if branch is not found in repository
>>  - remote: remove the_repository->remote_state from static methods
>>  - remote: use remote_state parameter internally
>>  - remote: move static variables into per-repository struct
>>  - t5516: add test case for pushing remote refspecs
>> 
>>  Code clean-up to eventually allow information on remotes defined
>>  for an arbitrary repository to be read.
>> 
>>  Will merge to 'next'?
>
> What's still blocking this from being merged? Anything? Release
> schedule?

I do not think I saw anybody giving sufficient review on any previous rounds or the latest round. I did read some part and commented on earlier rounds, during the -rc period, I don't have enough concentration to judge a new design properly myself.

So, in short, these patches are unreviewed yet, if I am not mistaken.

Thanks.
Glen Choo· Nov 11, 2021, 23:44 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)

Junio C Hamano <gitster@pobox.com> writes:
Show 25 quoted lines
> Emily Shaffer <emilyshaffer@google.com> writes:
>
>>> * gc/remote-with-fewer-static-global-variables (2021-10-28) 6 commits
>>>  - remote: add struct repository parameter to external functions
>>>  - remote: die if branch is not found in repository
>>>  - remote: remove the_repository->remote_state from static methods
>>>  - remote: use remote_state parameter internally
>>>  - remote: move static variables into per-repository struct
>>>  - t5516: add test case for pushing remote refspecs
>>> 
>>>  Code clean-up to eventually allow information on remotes defined
>>>  for an arbitrary repository to be read.
>>> 
>>>  Will merge to 'next'?
>>
>> What's still blocking this from being merged? Anything? Release
>> schedule?
>
> I do not think I saw anybody giving sufficient review on any
> previous rounds or the latest round.  I did read some part and
> commented on earlier rounds, during the -rc period, I don't have
> enough concentration to judge a new design properly myself.
>
> So, in short, these patches are unreviewed yet, if I am not
> mistaken.

Thanks for clarifying, Emily and I were under the impression that this would be merged soon. I'll ask for more reviews.

Ævar Arnfjörð Bjarmason· Nov 13, 2021, 09:17 UTC · re: Emily Shaffer · lore

ab/config-based-hooks-2 etc. (was: What's cooking in git.git (Nov 2021, #03; Tue, 9))

On Thu, Nov 11 2021, Emily Shaffer wrote:
> Once more, updates to submodule-UX-overhaul related work.
>
> On Tue, Nov 09, 2021 at 04:59:31PM -0800, Junio C Hamano wrote:
[...]
Show 26 quoted lines
>
>> * ab/config-based-hooks-2 (2021-11-01) 18 commits
>>  - run-command: remove old run_hook_{le,ve}() hook API
>>  - receive-pack: convert push-to-checkout hook to hook.h
>>  - read-cache: convert post-index-change to use hook.h
>>  - commit: convert {pre-commit,prepare-commit-msg} hook to hook.h
>>  - git-p4: use 'git hook' to run hooks
>>  - send-email: use 'git hook run' for 'sendemail-validate'
>>  - git hook run: add an --ignore-missing flag
>>  - hooks: convert worktree 'post-checkout' hook to hook library
>>  - hooks: convert non-worktree 'post-checkout' hook to hook library
>>  - merge: convert post-merge to use hook.h
>>  - am: convert applypatch-msg to use hook.h
>>  - rebase: convert pre-rebase to use hook.h
>>  - hook API: add a run_hooks_l() wrapper
>>  - am: convert {pre,post}-applypatch to use hook.h
>>  - gc: use hook library for pre-auto-gc hook
>>  - hook API: add a run_hooks() wrapper
>>  - hook: add 'run' subcommand
>>  - Merge branch 'ab/config-based-hooks-1' into ab/config-based-hooks-2
>> 
>>  More "config-based hooks".
>
> I think I owe another review, but as always with these topics, I wrote a
> lot of the code so I'm not sure how much I can really help. Other eyes
> appreciated.

It's quite a bit of work, but one bit of valuable independent verification would be to take your version of the eventual patches that you've got and try to keep a version rebased on top of these submissions.

As a spoiler my version is (you'll need gitster's and my github
remotes):
    
    git range-diff \
        gitster/ab/config-based-hooks-base..gitster/es/config-based-hooks \
        avar/es-avar/config-based-hooks-7..avar/avar-nasamuffin/config-based-hooks-restart-5

I.e. that's the difference between "your" https://lore.kernel.org/git/cover-v4-0.5-00000000000-20210909T122802Z-avarab@gmail.com/ and what I've currently got. I was intending to find the last version you'd submitted, but I either missed it or I'd have to apply it from the ML.

In any case, I've found that when I've made changes to the re-rolled "base" topic based on on-list feedback that needing to roll those changes forward can inform whether changes in the "base" are good ideas or not. I.e. whether subsequent changes on top are just cosmetic, or would require rewrites or a changed design.

That range-diff above doesn't represent any sort of "good" or ready state, I've just been making the bare minimal set of changes to keep the "really config-based" topic compiling and passing tests.

Show 19 quoted lines
>> * es/superproject-aware-submodules (2021-11-04) 4 commits
>>  - submodule: record superproject gitdir during 'update'
>>  - submodule: record superproject gitdir during absorbgitdirs
>>  - introduce submodule.superprojectGitDir record
>>  - t7400-submodule-basic: modernize inspect() helper
>> 
>>  A configuration variable in a submodule points at the location of
>>  the superproject it is bound to (RFC).
>
> To summarize the discussion from here: Ævar suggested this topic might
> not be necessary anymore, and that we should rely on in-process
> discovery of the superproject's gitdir. However, after some more
> thought, I think it's valuable to strive for a definitive way to tell
> "yes, I am a submodule" - and I'd like for this topic to be it. I'm
> planning a reroll (and an explanation in the cover letter), and to drop
> language referring to that as a "cache" (because it isn't a cheap
> version of an operation the submodule would be doing otherwise). I will
> also add another patch to demonstrate how we can use that new
> information as a point of truth, instead of a performance shim.

Hopefully it's clear from the feedback I had there, but my opinion in this topic is not that I don't think it's unnecessary, I honestly don't know enough about submodules to say.

Rather that per [1] and [2] for someone who's got that ignorance on the topic it would be really helpful if we clearly delineate what's a cache and what's changed behavior.

And even if something is much slower non-cached having a canonical "slow but correct" path is really valuable, because it may be the case that we can drop (parts of?) the caching in the future/soon/now if we take the *.sh<->*.c boundary out of the equation, and at that point being able to test against the "canonical but slow" version is really helpful.

Especially as a "canonical cache" always runs the risk of what was assumed to be mere caching becoming changed semantics inadvertently, and then we'd be stuck with it. Maybe it's good that we'd be stuck with it (the "point of truth" you mention above), but then let's go into that behavior change with eyes wide open

1. https://lore.kernel.org/git/211109.86r1bqdsmu.gmgdl@evledraar.gmail.com/
2. https://lore.kernel.org/git/211109.86v912dtfw.gmgdl@evledraar.gmail.com/

← back to recent threads