All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (Nov 2021, #03; Tue, 9)
@ 2021-11-10  0:59 Junio C Hamano
  2021-11-10 12:47 ` js/scalar, was " Johannes Schindelin
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-11-10  0:59 UTC (permalink / raw)
  To: git

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10  0:59 What's cooking in git.git (Nov 2021, #03; Tue, 9) Junio C Hamano
@ 2021-11-10 12:47 ` Johannes Schindelin
  2021-11-10 13:42   ` Ævar Arnfjörð Bjarmason
  2021-11-11 18:25   ` Junio C Hamano
  2021-11-10 13:04 ` jc/fix-pull-ff-only-when-already-up-to-date, " Johannes Schindelin
  2021-11-11 22:19 ` Emily Shaffer
  2 siblings, 2 replies; 15+ messages in thread
From: Johannes Schindelin @ 2021-11-10 12:47 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10  0:59 What's cooking in git.git (Nov 2021, #03; Tue, 9) Junio C Hamano
  2021-11-10 12:47 ` js/scalar, was " Johannes Schindelin
@ 2021-11-10 13:04 ` Johannes Schindelin
  2021-11-10 17:20   ` Junio C Hamano
  2021-11-11 22:19 ` Emily Shaffer
  2 siblings, 1 reply; 15+ messages in thread
From: Johannes Schindelin @ 2021-11-10 13:04 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi Junio,

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10 12:47 ` js/scalar, was " Johannes Schindelin
@ 2021-11-10 13:42   ` Ævar Arnfjörð Bjarmason
  2021-11-11 18:25   ` Junio C Hamano
  1 sibling, 0 replies; 15+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-11-10 13:42 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git, Derrick Stolee


On Wed, Nov 10 2021, Johannes Schindelin wrote:

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10 13:04 ` jc/fix-pull-ff-only-when-already-up-to-date, " Johannes Schindelin
@ 2021-11-10 17:20   ` Junio C Hamano
  2021-11-10 19:00     ` Alex Henrie
  2021-11-10 19:09     ` Johannes Schindelin
  0 siblings, 2 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-11-10 17:20 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

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.

Thanks.


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10 17:20   ` Junio C Hamano
@ 2021-11-10 19:00     ` Alex Henrie
  2021-11-10 19:09     ` Johannes Schindelin
  1 sibling, 0 replies; 15+ messages in thread
From: Alex Henrie @ 2021-11-10 19:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Johannes Schindelin, Git mailing list

On Wed, Nov 10, 2021 at 10:21 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10 17:20   ` Junio C Hamano
  2021-11-10 19:00     ` Alex Henrie
@ 2021-11-10 19:09     ` Johannes Schindelin
  2021-11-10 19:17       ` Junio C Hamano
  1 sibling, 1 reply; 15+ messages in thread
From: Johannes Schindelin @ 2021-11-10 19:09 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi Junio,

On Wed, 10 Nov 2021, Junio C Hamano wrote:

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: jc/fix-pull-ff-only-when-already-up-to-date, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10 19:09     ` Johannes Schindelin
@ 2021-11-10 19:17       ` Junio C Hamano
  0 siblings, 0 replies; 15+ messages in thread
From: Junio C Hamano @ 2021-11-10 19:17 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10 12:47 ` js/scalar, was " Johannes Schindelin
  2021-11-10 13:42   ` Ævar Arnfjörð Bjarmason
@ 2021-11-11 18:25   ` Junio C Hamano
  2021-11-12  9:32     ` Johannes Schindelin
  1 sibling, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2021-11-11 18:25 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git

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.

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-10  0:59 What's cooking in git.git (Nov 2021, #03; Tue, 9) Junio C Hamano
  2021-11-10 12:47 ` js/scalar, was " Johannes Schindelin
  2021-11-10 13:04 ` jc/fix-pull-ff-only-when-already-up-to-date, " Johannes Schindelin
@ 2021-11-11 22:19 ` Emily Shaffer
  2021-11-11 22:40   ` Emily Shaffer
                     ` (2 more replies)
  2 siblings, 3 replies; 15+ messages in thread
From: Emily Shaffer @ 2021-11-11 22:19 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Once more, updates to submodule-UX-overhaul related work.

On Tue, Nov 09, 2021 at 04:59:31PM -0800, Junio C Hamano wrote:
> --------------------------------------------------
> [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.

> --------------------------------------------------
> [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?

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

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

> * 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-11 22:19 ` Emily Shaffer
@ 2021-11-11 22:40   ` Emily Shaffer
  2021-11-11 22:58   ` Junio C Hamano
  2021-11-13  9:17   ` ab/config-based-hooks-2 etc. (was: What's cooking in git.git (Nov 2021, #03; Tue, 9)) Ævar Arnfjörð Bjarmason
  2 siblings, 0 replies; 15+ messages in thread
From: Emily Shaffer @ 2021-11-11 22:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Thu, Nov 11, 2021 at 02:19:20PM -0800, Emily Shaffer wrote:
> 
> Once more, updates to submodule-UX-overhaul related work.
[...]
> 
> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-11 22:19 ` Emily Shaffer
  2021-11-11 22:40   ` Emily Shaffer
@ 2021-11-11 22:58   ` Junio C Hamano
  2021-11-11 23:44     ` Glen Choo
  2021-11-13  9:17   ` ab/config-based-hooks-2 etc. (was: What's cooking in git.git (Nov 2021, #03; Tue, 9)) Ævar Arnfjörð Bjarmason
  2 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2021-11-11 22:58 UTC (permalink / raw)
  To: Emily Shaffer; +Cc: git

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-11 22:58   ` Junio C Hamano
@ 2021-11-11 23:44     ` Glen Choo
  0 siblings, 0 replies; 15+ messages in thread
From: Glen Choo @ 2021-11-11 23:44 UTC (permalink / raw)
  To: Junio C Hamano, Emily Shaffer; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: js/scalar, was Re: What's cooking in git.git (Nov 2021, #03; Tue, 9)
  2021-11-11 18:25   ` Junio C Hamano
@ 2021-11-12  9:32     ` Johannes Schindelin
  0 siblings, 0 replies; 15+ messages in thread
From: Johannes Schindelin @ 2021-11-12  9:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Hi Junio,

On Thu, 11 Nov 2021, Junio C Hamano wrote:

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

> 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* ab/config-based-hooks-2 etc. (was: What's cooking in git.git (Nov 2021, #03; Tue, 9))
  2021-11-11 22:19 ` Emily Shaffer
  2021-11-11 22:40   ` Emily Shaffer
  2021-11-11 22:58   ` Junio C Hamano
@ 2021-11-13  9:17   ` Ævar Arnfjörð Bjarmason
  2 siblings, 0 replies; 15+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2021-11-13  9:17 UTC (permalink / raw)
  To: Emily Shaffer; +Cc: Junio C Hamano, git


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:
[...]
>
>> * 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.

>> * 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/

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2021-11-13  9:39 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-10  0:59 What's cooking in git.git (Nov 2021, #03; Tue, 9) Junio C Hamano
2021-11-10 12:47 ` js/scalar, was " Johannes Schindelin
2021-11-10 13:42   ` Ævar Arnfjörð Bjarmason
2021-11-11 18:25   ` Junio C Hamano
2021-11-12  9:32     ` Johannes Schindelin
2021-11-10 13:04 ` jc/fix-pull-ff-only-when-already-up-to-date, " Johannes Schindelin
2021-11-10 17:20   ` Junio C Hamano
2021-11-10 19:00     ` Alex Henrie
2021-11-10 19:09     ` Johannes Schindelin
2021-11-10 19:17       ` Junio C Hamano
2021-11-11 22:19 ` Emily Shaffer
2021-11-11 22:40   ` Emily Shaffer
2021-11-11 22:58   ` Junio C Hamano
2021-11-11 23:44     ` Glen Choo
2021-11-13  9:17   ` ab/config-based-hooks-2 etc. (was: What's cooking in git.git (Nov 2021, #03; Tue, 9)) Ævar Arnfjörð Bjarmason

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.