What's cooking in git.git (May 2019, #05; Thu, 30)

What's cooking in git.git (May 2019, #05; Thu, 30)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.  The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.

The second round of release candidate has been tagged, after
slipping for several days to merge a handful of last-minute
regression fixes.

You can find the changes described here in the integration branches
of the repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[Graduated to "master"]

* es/doc-gitsubmodules-markup (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 695bb51514)
 + gitsubmodules: align html and nroff lists

 Doc markup fix.


* ja/diff-opt-typofix (2019-05-19) 1 commit
  (merged to 'next' on 2019-05-19 at fedb594191)
 + diff: fix mistake in translatable strings

 Typofix.


* jh/trace2 (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 849c4916ac)
 + trace2: fix tracing when NO_PTHREADS is defined

 Will merge to 'master'.


* js/rebase-config-bitfix (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 77de6e31b6)
 + rebase: replace incorrect logical negation by correct bitwise one

 Will merge to 'master'.


* js/rebase-deprecate-preserve-merges (2019-05-28) 3 commits
  (merged to 'next' on 2019-05-29 at d153fc0d44)
 + rebase docs: recommend `-r` over `-p`
 + docs: say that `--rebase=preserve` is deprecated
 + tests: mark a couple more test cases as requiring `rebase -p`

 A bit more leftover clean-up to deprepcate "rebase -p".


* jt/clone-server-option (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 30eb487077)
 + fetch-pack: send server options after command

 A brown-paper-bag bugfix to a change already in 'master'.


* nd/diff-parseopt (2019-05-29) 3 commits
  (merged to 'next' on 2019-05-29 at f9eedc21e3)
 + parse-options: check empty value in OPT_INTEGER and OPT_ABBREV
 + diff-parseopt: restore -U (no argument) behavior
 + diff-parseopt: correct variable types that are used by parseopt

 A brown-paper-bag bugfix to a change already in 'master'.

 Reducing the noise of the bottom-most patch may be desirable, although
 the change itself is not wrong per-se.


* sg/progress-off-by-one-fix (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 13ea8cc5a5)
 + progress: avoid empty line when breaking the progress line

 A brown-paper-bag bugfix to a change already in 'master'.


* sg/trace2-rename (2019-05-28) 2 commits
  (merged to 'next' on 2019-05-29 at ae7aa4b417)
 + trace2: document the supported values of GIT_TRACE2* env variables
 + trace2: rename environment variables to GIT_TRACE2*

 Rename environment variables that are used to control the "trace2"
 mechanism to a more readable name.

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

* po/doc-branch (2019-05-29) 1 commit
 - doc branch: provide examples for listing remote tracking branches

 RFC


* bb/unicode-12.1-reiwa (2019-05-29) 1 commit
  (merged to 'next' on 2019-05-30 at 016465335c)
 + unicode: update the width tables to Unicode 12.1
<<
* bb/unicode-12.1-reiwa (2019-05-29) 1 commit
 - unicode: update the width tables to Unicode 12.1
>>

 Update to Unicode 12.1 width table.

 Will cook in 'next'.

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

* jn/unknown-index-extensions (2018-11-21) 2 commits
 - index: offer advice for unknown index extensions
 - index: do not warn about unrecognized extensions

 A bit too alarming warning given when unknown index extensions
 exist is getting revamped.

 Expecting a reroll.


* jc/format-patch-delay-message-id (2019-04-05) 1 commit
 - format-patch: move message-id and related headers to the end

 The location "git format-patch --thread" adds the Message-Id:
 header in the series of header fields has been moved down, which
 may help working around a suspected bug in GMail MSA, reported at
 <CAHk-=whP1stFZNAaJiMi5eZ9rj0MRt20Y_yHVczZPH+O01d+sA@mail.gmail.com>

 Waiting for feedback to see if it truly helps.
 Needs tests.


* jt/fetch-cdn-offload (2019-03-12) 9 commits
 - SQUASH???
 - upload-pack: send part of packfile response as uri
 - fetch-pack: support more than one pack lockfile
 - upload-pack: refactor reading of pack-objects out
 - Documentation: add Packfile URIs design doc
 - Documentation: order protocol v2 sections
 - http-fetch: support fetching packfiles by URL
 - http: improve documentation of http_pack_request
 - http: use --stdin when getting dumb HTTP pack

 WIP for allowing a response to "git fetch" to instruct the bulk of
 the pack contents to be instead taken from elsewhere (aka CDN).

 Stalled


* js/add-i-coalesce-after-editing-hunk (2018-08-28) 1 commit
 - add -p: coalesce hunks before testing applicability

 Applicability check after a patch is edited in a "git add -i/p"
 session has been improved.

 Will drop as "add -i in C" topic seems to be getting ready to test.


* js/protocol-advertise-multi (2018-12-28) 1 commit
 - protocol: advertise multiple supported versions

 The transport layer has been updated so that the protocol version
 used can be negotiated between the parties, by the initiator
 listing the protocol versions it is willing to talk, and the other
 side choosing from one of them.

 Expecting a reroll.
 cf. <CANq=j3u-zdb_FvNJGPCmygNMScseav63GhVvBX3NcVS4f7TejA@mail.gmail.com>


* mk/use-size-t-in-zlib (2018-10-15) 1 commit
 - zlib.c: use size_t for size

 The wrapper to call into zlib followed our long tradition to use
 "unsigned long" for sizes of regions in memory, which have been
 updated to use "size_t".


* dl/remote-save-to-push (2018-12-11) 1 commit
 - remote: add --save-to-push option to git remote set-url

 "git remote set-url" learned a new option that moves existing value
 of the URL field to pushURL field of the remote before replacing
 the URL field with a new value.

 Anybody who wants to champion this topic?
 I am personally not yet quite convinced if this is worth pursuing.

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

* ab/hash-object-doc (2019-05-28) 1 commit
 - hash-object doc: stop mentioning git-cvsimport

 Doc update.

 Will merge to 'next'.


* cc/list-objects-filter-wo-sparse-path (2019-05-29) 1 commit
  (merged to 'next' on 2019-05-30 at 5a294203ad)
 + list-objects-filter: disable 'sparse:path' filters

 Disable "--filter=sparse:path=<path>" that would allow reading from
 paths on the filesystem.

 Will cook in 'next'.


* ds/object-info-for-prefetch-fix (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at ee0055b276)
 + sha1-file: split OBJECT_INFO_FOR_PREFETCH

 Code cleanup and futureproof.

 Will cook in 'next'.


* ds/topo-traversal-using-commit-graph (2019-05-28) 2 commits
  (merged to 'next' on 2019-05-30 at 590527995e)
 + revision: keep topo-walk free of unintersting commits
 + revision: use generation for A..B --topo-order queries

 Prepare use of reachability index in topological walker that works
 on a range (A..B).

 Will cook in 'next'.


* es/git-debugger-doc (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 449ba4ae6c)
 + doc: hint about GIT_DEBUGGER in CodingGuidelines

 Doc update.

 Will cook in 'next'.


* es/grep-require-name-when-needed (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at e1ec57894a)
 + grep: fail if call could output and name is null

 More parameter validation.

 Will cook in 'next'.


* ew/server-info-remove-crufts (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 655ba18f30)
 + server-info: do not list unlinked packs

 "git update-server-info" used to leave stale packfiles in its
 output, which has been corrected.

 Will cook in 'next'.


* jk/HEAD-symref-in-xfer-namespaces (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at c2cfe38955)
 + upload-pack: strip namespace from symref data

 The server side support for "git fetch" used to show incorrect
 value for the HEAD symbolic ref when the namespace feature is in
 use, which has been corrected.

 Will cook in 'next'.


* jk/am-i-resolved-fix (2019-05-28) 4 commits
  (merged to 'next' on 2019-05-29 at e711103b1a)
 + am: fix --interactive HEAD tree resolution
 + am: drop tty requirement for --interactive
 + am: read interactive input from stdin
 + am: simplify prompt response handling

 "git am -i --resolved" segfaulted after trying to see a commit as
 if it were a tree, which has been corrected.

 Will cook in 'next'.


* js/bisect-helper-check-get-oid-return-value (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 24125b3bc0)
 + bisect--helper: verify HEAD could be parsed before continuing

 Code cleanup.

 Will cook in 'next'.


* js/bundle-verify-require-object-store (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 747fbbaf11)
 + bundle verify: error out if called without an object database

 "git bundle verify" needs to see if prerequisite objects exist in
 the receiving repository, but the command did not check if we are
 in a repository upfront, which has been corrected.

 Will cook in 'next'.


* js/fsmonitor-unflake (2019-05-28) 2 commits
  (merged to 'next' on 2019-05-30 at 1aa850bc59)
 + mark_fsmonitor_valid(): mark the index as changed if needed
 + fill_stat_cache_info(): prepare for an fsmonitor fix

 The data collected by fsmonitor was not properly written back to
 the on-disk index file, breaking t7519 tests occasionally, which
 has been corrected.

 Will cook in 'next'.


* mm/p4-unshelve-windows-fix (2019-05-28) 1 commit
 - p4 unshelve: fix "Not a valid object name HEAD0" on Windows

 The command line to invoke a "git cat-file" command from inside
 "git p4" was not properly quoted to protect a caret and running a
 broken command on Windows, which has been corrected.

 Will merge to 'next'.


* pb/request-pull-verify-remote-ref (2019-05-28) 2 commits
 - request-pull: warn if the remote object is not the same as the local one
 - request-pull: quote regex metacharacters in local ref

 "git request-pull" learned to warn when the ref we ask them to pull
 from in the local repository and in the published repository are
 different.

 Will merge to 'next'.


* po/git-help-on-git-itself (2019-05-16) 2 commits
 - Doc: git.txt: remove backticks from link and add git-scm.com/docs
 - git.c: show usage for accessing the git(1) help page

 "git help git" was hard to discover (well, at least for some
 people).

 Will merge to 'next'.


* sw/git-p4-unshelve-branched-files (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-30 at e1985f61fc)
 + git-p4: allow unshelving of branched files

 "git p4" update.

 Will cook in 'next'.


* vv/merge-squash-with-explicit-commit (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 209baa3e55)
 + merge: refuse --commit with --squash

 "git merge --squash" is designed to update the working tree and the
 index without creating the commit, and this cannot be countermanded
 by adding the "--commit" option; the command now refuses to work
 when both options are given.

 Will cook in 'next'.


* xl/record-partial-clone-origin (2019-05-29) 1 commit
 - clone: respect user supplied origin name when setting up partial clone

 When creating a partial clone, the object filtering criteria is
 recorded for the origin of the clone, but this incorrectly used a
 hardcoded name "origin" to name that remote; it has been corrected
 to honor the "--origin <name>" option.

 Will merge to 'next'.


* ab/fail-prereqs-in-test (2019-05-14) 1 commit
  (merged to 'next' on 2019-05-16 at d1be55f485)
 + tests: add a special setup where prerequisites fail

 Developer support to emulate unsatisfied prerequisites in tests to
 ensure that the remainer of the tests still succeeds when tests
 with prerequisites are skipped.

 Will cook in 'next'.


* jk/help-unknown-ref-fix (2019-05-15) 2 commits
  (merged to 'next' on 2019-05-19 at e3e01160f7)
 + help_unknown_ref(): check for refname ambiguity
 + help_unknown_ref(): duplicate collected refnames

 Improve the code to show args with potential typo that cannot be
 interpreted as a commit-ish.

 Will cook in 'next'.


* js/rebase-cleanup (2019-05-15) 5 commits
  (merged to 'next' on 2019-05-16 at ccfed8f263)
 + rebase: fold git-rebase--common into the -p backend
 + sequencer: the `am` and `rebase--interactive` scripts are gone
 + .gitignore: there is no longer a built-in `git-rebase--interactive`
 + t3400: stop referring to the scripted rebase
 + Drop unused git-rebase--am.sh

 Update supporting parts of "git rebase" to remove code that should
 no longer be used.

 Will cook in 'next'.


* jt/partial-clone-missing-ref-delta-base (2019-05-15) 2 commits
  (merged to 'next' on 2019-05-29 at 5d7573a151)
 + index-pack: prefetch missing REF_DELTA bases
 + t5616: refactor packfile replacement

 "git fetch" into a lazy clone forgot to fetch base objects that are
 necessary to complete delta in a thin packfile, which has been
 corrected.

 Will cook in 'next'.


* bl/userdiff-octave (2019-05-29) 2 commits
  (merged to 'next' on 2019-05-29 at 6ed07afc89)
 + userdiff: fix grammar and style issues
  (merged to 'next' on 2019-05-19 at 9ea1180d6c)
 + userdiff: add Octave

 The pattern "git diff/grep" use to extract funcname and words
 boundary for Matlab has been extend to cover Octave, which is more
 or less equivalent.

 Will cook in 'next'.


* ew/update-server-info (2019-05-15) 1 commit
  (merged to 'next' on 2019-05-19 at bf4f2871ab)
 + update-server-info: avoid needless overwrites

 "git update-server-info" learned not to rewrite the file with the
 same contents.

 Will cook in 'next'.


* nd/corrupt-worktrees (2019-05-15) 1 commit
  (merged to 'next' on 2019-05-16 at d92c25f800)
 + worktree add: be tolerant of corrupt worktrees

 "git worktree add" used to fail when another worktree connected to
 the same repository was corrupt, which has been corrected.

 Will cook in 'next'.


* mh/import-transport-fd-fix (2019-05-16) 2 commits
  (merged to 'next' on 2019-05-19 at 5e86f92f7a)
 + Use xmmap_gently instead of xmmap in use_pack
 + dup() the input fd for fast-import used for remote helpers

 The ownership rule for the file descriptor to fast-import remote
 backend was mixed up, leading to unrelated file descriptor getting
 closed, which has been fixed.

 Will cook in 'next'.


* ab/deprecate-R-for-dynpath (2019-05-19) 1 commit
  (merged to 'next' on 2019-05-19 at 944976e981)
 + Makefile: remove the NO_R_TO_GCC_LINKER flag

 The way of specifying the path to find dynamic libraries at runtime
 has been simplified.  The old default to pass -R/path/to/dir has been
 replaced with the new default to pass -Wl,-rpath,/path/to/dir,
 which is the more recent GCC uses.  Those who need to build with an
 old GCC can still use "CC_LD_DYNPATH=-R"

 Will cook in 'next'.


* ba/clone-remote-submodules (2019-05-28) 1 commit
  (merged to 'next' on 2019-05-29 at 71972f94c2)
 + clone: add `--remote-submodules` flag

 "git clone --recurse-submodules" learned to set up the submodules
 to ignore commit object names recorded in the superproject gitlink
 and instead use the commits that happen to be at the tip of the
 remote-tracking branches from the get-go, by passing the new
 "--remote-submodules" option.

 Will cook in 'next'.


* ds/close-object-store (2019-05-28) 3 commits
 - packfile: rename close_all_packs to close_object_store
 - packfile: close commit-graph in close_all_packs
 - commit-graph: use raw_object_store when closing
 (this branch uses ds/commit-graph-write-refactor.)

 The commit-graph file is now part of the "files that the runtime
 may keep open file descriptors on, all of which would need to be
 closed when done with the object store", and the file descriptor to
 an existing commit-graph file now is closed before "gc" finializes
 a new instance to replace it.

 Waiting on ds/commit-graph-write-refactor to stabilize.


* ml/userdiff-rust (2019-05-30) 2 commits
 - userdiff: two simplifications of patterns for rust
  (merged to 'next' on 2019-05-19 at 1266fddce5)
 + userdiff: add built-in pattern for rust

 The pattern "git diff/grep" use to extract funcname and words
 boundary for Rust has been added.

 Will cook in 'next'.


* pw/rebase-edit-message-for-replayed-merge (2019-05-19) 1 commit
  (merged to 'next' on 2019-05-19 at dc3e30641c)
 + rebase -r: always reword merge -c

 A "merge -c" instruction during "git rebase --rebase-merges" should
 give the user a chance to edit the log message, even when there is
 otherwise no need to create a new merge and replace the existing
 one (i.e. fast-forward instead), but did not.  Which has been
 corrected.

 Will cook in 'next'.


* sb/format-patch-base-patch-id-fix (2019-05-08) 2 commits
  (merged to 'next' on 2019-05-15 at 1ab7d2b71c)
 + format-patch: make --base patch-id output stable
 + format-patch: inform user that patch-id generation is unstable

 The recently added "--base" option of "format-patch" computed the
 patch-ids for prerequisite patches in an unstable way, which has
 been updated to compute in a way that is compatible with "git
 patch-id --stable".

 Will cook in 'next'.


* ab/send-email-transferencoding-fix (2019-05-29) 7 commits
  (merged to 'next' on 2019-05-29 at c8a99d18c0)
 + send-email: fix regression in sendemail.identity parsing
 + send-email: document --no-[to|cc|bcc]
 + send-email: fix broken transferEncoding tests
 + send-email: remove cargo-culted multi-patch pattern in tests
  (merged to 'next' on 2019-05-13 at 38c6a1e7e0)
 + send-email: do defaults -> config -> getopt in that order
 + send-email: rename the @bcclist variable for consistency
 + send-email: move the read_config() function above getopts

 Since "git send-email" learned to take 'auto' as the value for the
 transfer-encoding, it by mistake stopped honoring the values given
 to the configuration variables sendemail.transferencoding and/or
 sendemail.<ident>.transferencoding.  This has been corrected to
 (finally) redoing the order of setting the default, reading the
 configuration and command line options.

 Will cook in 'next'.


* dl/format-patch-notes-config (2019-05-17) 2 commits
  (merged to 'next' on 2019-05-19 at d3f6f1872b)
 + format-patch: teach format.notes config option
 + git-format-patch.txt: document --no-notes option

 "git format-patch" learns a configuration to set the default for
 its --notes=<ref> option.

 Will cook in 'next'.


* jk/unused-params-final-batch (2019-05-13) 14 commits
  (merged to 'next' on 2019-05-15 at ef7435264c)
 + verify-commit: simplify parameters to run_gpg_verify()
 + show-branch: drop unused parameter from show_independent()
 + rev-list: drop unused void pointer from finish_commit()
 + remove_all_fetch_refspecs(): drop unused "remote" parameter
 + receive-pack: drop unused "commands" from prepare_shallow_update()
 + pack-objects: drop unused rev_info parameters
 + name-rev: drop unused parameters from is_better_name()
 + mktree: drop unused length parameter
 + wt-status: drop unused status parameter
 + read-cache: drop unused parameter from threaded load
 + clone: drop dest parameter from copy_alternates()
 + submodule: drop unused prefix parameter from some functions
 + builtin: consistently pass cmd_* prefix to parse_options
 + cmd_{read,write}_tree: rename "unused" variable that is used

 Remove many unused parameters throughout the codebase, with the
 ultimate aim to allow us compile with -Wunused-parameter cleanly.

 Will cook in 'next'.


* nd/init-relative-template-fix (2019-05-13) 1 commit
  (merged to 'next' on 2019-05-15 at 4d5b17f712)
 + init: make --template path relative to $CWD

 A relative pathname given to "git init --template=<path> <repo>"
 ought to be relative to the directory "git init" gets invoked in,
 but it instead was made relative to the repository, which has been
 corrected.

 Will cook in 'next'.


* an/ignore-doc-update (2019-05-08) 1 commit
 - gitignore.txt: make slash-rules more readable

 The description about slashes in gitignore patterns (used to
 indicate things like "anchored to this level only" and "only
 matches directories") has been revamped.

 Almost there.
 cf. <20190507104507.18735-1-admin@in-ici.net>


* en/fast-export-encoding (2019-05-14) 5 commits
  (merged to 'next' on 2019-05-16 at c88bd3edb5)
 + fast-export: do automatic reencoding of commit messages only if requested
 + fast-export: differentiate between explicitly UTF-8 and implicitly UTF-8
 + fast-export: avoid stripping encoding header if we cannot reencode
 + fast-import: support 'encoding' commit header
 + t9350: fix encoding test to actually test reencoding

 The "git fast-export/import" pair has been taught to handle commits
 with log messages in encoding other than UTF-8 better.

 Will cook in 'next'.


* nd/merge-quit (2019-05-19) 2 commits
  (merged to 'next' on 2019-05-19 at 9880e7ee4e)
 + merge: add --quit
 + merge: remove drop_save() in favor of remove_merge_branch_state()

 "git merge" learned "--quit" option that cleans up the in-progress
 merge while leaving the working tree and the index still in a mess.

 Will cook in 'next'.


* pw/rebase-abort-clean-rewritten (2019-05-15) 4 commits
 - rebase --abort/--quit: cleanup refs/rewritten
 - sequencer: return errors from sequencer_remove_state()
 - rebase: warn if state directory cannot be removed
 - rebase: fix a memory leak

 "git rebase --abort" used to leave refs/rewritten/ when concluding
 "git rebase -r", which has been corrected.

 On hold.
 cf. <20190514180349.17245-1-phillip.wood123@gmail.com>


* nb/branch-show-other-worktrees-head (2019-05-07) 3 commits
 - branch: add worktree info on verbose output
 - branch: update output to include worktree info
 - ref-filter: add worktreepath atom

 "git branch --list" learned to show branches that are checked out
 in other worktrees connected to the same repository prefixed with
 '+', similar to the way the currently checked out branch is shown
 with '*' in front.


* es/first-contrib-tutorial (2019-05-29) 3 commits
  (merged to 'next' on 2019-05-30 at 96317960ab)
 + doc: add some nit fixes to MyFirstContribution
  (merged to 'next' on 2019-05-19 at 9ddfae82bf)
 + documentation: add anchors to MyFirstContribution
 + documentation: add tutorial for first contribution

 A new tutorial targetting specifically aspiring git-core
 developers.

 Will cook in 'next'.


* cc/multi-promisor (2019-04-15) 17 commits
 - Move core_partial_clone_filter_default to promisor-remote.c
 - Move repository_format_partial_clone to promisor-remote.c
 - Remove fetch-object.{c,h} in favor of promisor-remote.{c,h}
 - remote: add promisor and partial clone config to the doc
 - partial-clone: add multiple remotes in the doc
 - t0410: test fetching from many promisor remotes
 - builtin/fetch: remove unique promisor remote limitation
 - promisor-remote: parse remote.*.partialclonefilter
 - diff: use promisor-remote.h instead of fetch-object.h
 - Use promisor_remote_get_direct() and has_promisor_remote()
 - promisor-remote: use repository_format_partial_clone
 - promisor-remote: add promisor_remote_reinit()
 - promisor-remote: implement promisor_remote_get_direct()
 - Add initial support for many promisor remotes
 - fetch-object: make functions return an error code
 - t0410: remove pipes after git commands
 - Merge branch 'jt/batch-fetch-blobs-in-diff' into cc/multi-promisor

 Teach the lazy clone machinery that there can be more than one
 promisor remote and consult them in order when downloading missing
 objects on demand.

 Needs review.


* nd/switch-and-restore (2019-05-07) 43 commits
 - Declare both git-switch and git-restore experimental
 - help: move git-diff and git-reset to different groups
 - doc: promote "git restore"
 - user-manual.txt: prefer 'merge --abort' over 'reset --hard'
 - completion: support restore
 - t: add tests for restore
 - restore: support --patch
 - restore: replace --force with --ignore-unmerged
 - restore: default to --source=HEAD when only --staged is specified
 - restore: reject invalid combinations with --staged
 - restore: add --worktree and --staged
 - checkout: factor out worktree checkout code
 - restore: disable overlay mode by default
 - restore: make pathspec mandatory
 - restore: take tree-ish from --source option instead
 - checkout: split part of it to new command 'restore'
 - doc: promote "git switch"
 - completion: support switch
 - t: add tests for switch
 - switch: make --orphan switch to an empty tree
 - switch: reject if some operation is in progress
 - switch: no worktree status unless real branch switch happens
 - switch: implicit dwim, use --no-guess to disable it
 - switch: add short option for --detach
 - switch: only allow explicit detached HEAD
 - switch: reject "do nothing" case
 - switch: stop accepting pathspec
 - switch: remove -l
 - switch: add --discard-changes
 - switch: better names for -b and -B
 - checkout: split part of it to new command 'switch'
 - checkout: split options[] array in three pieces
 - checkout: move 'confict_style' and 'dwim_..' to checkout_opts
 - checkout: make "opts" in cmd_checkout() a pointer
 - checkout: factor out some code in parse_branchname_arg()
 - checkout: keep most #include sorted
 - checkout: inform the user when removing branch state
 - checkout: advice how to get out of detached HEAD mode
 - t: rename t2014-switch.sh to t2014-checkout-switch.sh
 - git-checkout.txt: fix monospace typeset
 - doc: document --overwrite-ignore
 - git-checkout.txt: fix one syntax line
 - git-checkout.txt: spell out --no-option

 Two new commands "git switch" and "git restore" are introduced to
 split "checking out a branch to work on advancing its history" and
 "checking out paths out of the index and/or a tree-ish to work on
 advancing the current history" out of the single "git checkout"
 command.

 The "switch" part seems more or less ready for testing.  Perhaps
 we should split this back into two topics and merge it to 'next'.
 cf. <20190329103919.15642-1-pclouds@gmail.com> (switch v6)
 cf. <20190425094600.15673-1-pclouds@gmail.com> (restore v3)


* jc/format-patch-noclobber (2019-02-22) 1 commit
 - format-patch: --no-clobber refrains from overwriting output files

 "git format-patch" used to overwrite an existing patch/cover-letter
 file.  A new "--no-clobber" option stops it.

 Undecided but inclined to discard.


* am/p4-branches-excludes (2019-04-02) 8 commits
 - git-p4: respect excluded paths when detecting branches
 - git-p4: add failing test for "git-p4: respect excluded paths when detecting branches"
 - git-p4: don't exclude other files with same prefix
 - git-p4: add failing test for "don't exclude other files with same prefix"
 - git-p4: don't groom exclude path list on every commit
 - git-p4: match branches case insensitively if configured
 - git-p4: add failing test for "git-p4: match branches case insensitively if configured"
 - git-p4: detect/prevent infinite loop in gitCommitByP4Change()

 "git p4" update.

 Is this ready for 'next'?


* dl/rebase-i-keep-base (2019-04-25) 6 commits
 - rebase: teach rebase --keep-base
 - rebase: fast-forward --fork-point in more cases
 - rebase: fast-forward --onto in more cases
 - rebase: refactor can_fast_forward into goto tower
 - t3432: test rebase fast-forward behavior
 - t3431: add rebase --fork-point tests

 "git rebase --keep-base <upstream>" tries to find the original base
 of the topic being rebased and rebase on top of that same base,
 which is useful when running the "git rebase -i" (and its limited
 variant "git rebase -x").

 The command also has learned to fast-forward in more cases where it
 can instead of replaying to recreate identical commits.

 On hold.
 cf. <20190508001252.15752-1-avarab@gmail.com>
 cf. <xmqqa7fxionx.fsf@gitster-ct.c.googlers.com>


* nd/worktree-name-sanitization (2019-05-15) 1 commit
  (merged to 'next' on 2019-05-16 at 9a2dd33122)
 + worktree add: sanitize worktree names

 In recent versions of Git, per-worktree refs are exposed in
 refs/worktrees/<wtname>/ hierarchy, which means that worktree names
 must be a valid refname component.  The code now sanitizes the names
 given to worktrees, to make sure these refs are well-formed.

 Will cook in 'next'.


* ds/commit-graph-write-refactor (2019-05-13) 11 commits
 - commit-graph: extract write_commit_graph_file()
 - commit-graph: extract copy_oids_to_commits()
 - commit-graph: extract count_distinct_commits()
 - commit-graph: extract fill_oids_from_all_packs()
 - commit-graph: extract fill_oids_from_commit_hex()
 - commit-graph: extract fill_oids_from_packs()
 - commit-graph: create write_commit_graph_context
 - commit-graph: remove Future Work section
 - commit-graph: collapse parameters into flags
 - commit-graph: return with errors during write
 - commit-graph: fix the_repository reference
 (this branch is used by ds/close-object-store.)

 Renamed from commit-graph-format-v2 and changed scope.

 Expecting a reroll.
 I think it is almost there, modulo a few internal API details..
 cf. <pull.112.v4.git.gitgitgadget@gmail.com> (v4)
 cf. <17829620-1084-74e5-54ad-aa95990f4dbd@gmail.com>


* br/blame-ignore (2019-05-17) 10 commits
 - SQUASH??? test-lint -- seq not portable
 - SQUASH??? error: decl-after-stmt
 - blame: use the fingerprint heuristic to match ignored lines
 - blame: add a fingerprint heuristic to match ignored lines
 - blame: optionally track line fingerprints during fill_blame_origin()
 - blame: add config options for the output of ignored or unblamable lines
 - blame: add the ability to ignore commits and their changes
 - blame: use a helper function in blame_chunk()
 - Move oidset_parse_file() to oidset.c
 - fsck: rename and touch up init_skiplist()

 "git blame" learned to "ignore" commits in the history, whose
 effects (as well as their presence) get ignored.

 cf. <20190515214503.77162-1-brho@google.com> (v7)

--------------------------------------------------
[Discarded]

* nd/precious (2019-04-09) 1 commit
 . Introduce "precious" file concept

 "git clean" learned to pay attention to the 'precious' attributes
 and keep untracked paths with the attribute instead of removing
 when the "--keep-precious" is given.

 Retracted.
 cf. <CACsJy8AEZ-Lz6zgEsuNukvphB9TTa9FAC1gK05fhnie2xtfc9w@mail.gmail.com>

 I am not sure what aspect of this longer-term "precious" vision,
 which gets taught to various commands and use cases individually
 and incrementally, Ævar finds problematic, which I understand is
 the reason of redtraction.


* jc/send-email-transferencoding-fix (2019-05-09) 2 commits
 . send-email: honor transferencoding config option again
 . send-email: update the mechanism to set default configuration values

 Replaced by  Ævar's "do the default in the right order" approach.
 cf. <20190508105607.178244-1-gitster@pobox.com> (v2)

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Johannes Schindelin]

Hi Junio,

On Thu, 30 May 2019, Junio C Hamano wrote:

> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
>
> The second round of release candidate has been tagged, after
> slipping for several days to merge a handful of last-minute
> regression fixes.

You hinted in an earlier "What's cooking" that you'd maybe go for an -rc3.
Is that still the case?

Or for that matter: do you plan on releasing a v2.21.1 before v2.22.0?

Ciao,
Dscho

P.S.: As you might have guessed, I would like to know in order to
determine how to proceed with Git for Windows' `master`: whether to hop on
the v2.22.x train or whether to stay on the v2.21.x train just a little
longer.

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Johannes Schindelin]

Hi Junio,

On Thu, 30 May 2019, Junio C Hamano wrote:

> * bb/unicode-12.1-reiwa (2019-05-29) 1 commit
>   (merged to 'next' on 2019-05-30 at 016465335c)
>  + unicode: update the width tables to Unicode 12.1
> <<
> * bb/unicode-12.1-reiwa (2019-05-29) 1 commit
>  - unicode: update the width tables to Unicode 12.1
> >>
>
>  Update to Unicode 12.1 width table.
>
>  Will cook in 'next'.

I would actually be in favor of merging this before v2.22.0. It's not like
this is a feature we need to perfect, we just integrate upstream changes.

> * ab/hash-object-doc (2019-05-28) 1 commit
>  - hash-object doc: stop mentioning git-cvsimport
>
>  Doc update.
>
>  Will merge to 'next'.

Similarly, I think it would not hurt to merge this before v2.22.0.

Granted, it does not fix a regression, but it's not like it will introduce
a regression, either.

> * cc/list-objects-filter-wo-sparse-path (2019-05-29) 1 commit
>   (merged to 'next' on 2019-05-30 at 5a294203ad)
>  + list-objects-filter: disable 'sparse:path' filters
>
>  Disable "--filter=sparse:path=<path>" that would allow reading from
>  paths on the filesystem.
>
>  Will cook in 'next'.

Not sure whether we want to fast-track this into v2.22.0. There is a risk.

But then, the longer we ship with `--filter=sparse:path` *enabled*, the
more we invite users to actually try and use it.

> * ds/object-info-for-prefetch-fix (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at ee0055b276)
>  + sha1-file: split OBJECT_INFO_FOR_PREFETCH
>
>  Code cleanup and futureproof.
>
>  Will cook in 'next'.

As agreed previously, I'd be in favor of keeping this out of v2.22.0.

> * ds/topo-traversal-using-commit-graph (2019-05-28) 2 commits
>   (merged to 'next' on 2019-05-30 at 590527995e)
>  + revision: keep topo-walk free of unintersting commits
>  + revision: use generation for A..B --topo-order queries
>
>  Prepare use of reachability index in topological walker that works
>  on a range (A..B).
>
>  Will cook in 'next'.

Same here, this can cook a bit longer.

> * es/git-debugger-doc (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at 449ba4ae6c)
>  + doc: hint about GIT_DEBUGGER in CodingGuidelines
>
>  Doc update.
>
>  Will cook in 'next'.

I actually do not see any benefit of this documentation change cooking.
The most likely people to "cook" this is new contributors, and they will
not see anything that is in `next` in my experience.

But it does not *need* to be in v2.22.0, either.

> * es/grep-require-name-when-needed (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at e1ec57894a)
>  + grep: fail if call could output and name is null
>
>  More parameter validation.
>
>  Will cook in 'next'.

This is not a new regression, so by your standard it should not get into
v2.22.0 this late in the game (and I agree with this standard, as there is
a risk of regressions here).

> * ew/server-info-remove-crufts (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at 655ba18f30)
>  + server-info: do not list unlinked packs
>
>  "git update-server-info" used to leave stale packfiles in its
>  output, which has been corrected.
>
>  Will cook in 'next'.

I do dream of the day when we can just get rid of the entire non-smart
HTTP stuff.

And I do dream of the day when we can switch `git daemon` to serve via
smart HTTP, i.e. run `http-backend` internally. And then we could get rid
of the git:// protocol, too.

But I digress.

If anyone wants to have my opinion on whether to merge this before
v2.22.0: I don't think so, it is not critical enough, in my mind.

> * jk/HEAD-symref-in-xfer-namespaces (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at c2cfe38955)
>  + upload-pack: strip namespace from symref data
>
>  The server side support for "git fetch" used to show incorrect
>  value for the HEAD symbolic ref when the namespace feature is in
>  use, which has been corrected.
>
>  Will cook in 'next'.

This is an older regression, so it should probably be kept in `next` for
now.

> * jk/am-i-resolved-fix (2019-05-28) 4 commits
>   (merged to 'next' on 2019-05-29 at e711103b1a)
>  + am: fix --interactive HEAD tree resolution
>  + am: drop tty requirement for --interactive
>  + am: read interactive input from stdin
>  + am: simplify prompt response handling
>
>  "git am -i --resolved" segfaulted after trying to see a commit as
>  if it were a tree, which has been corrected.
>
>  Will cook in 'next'.

Likewise.

> * js/bisect-helper-check-get-oid-return-value (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at 24125b3bc0)
>  + bisect--helper: verify HEAD could be parsed before continuing
>
>  Code cleanup.
>
>  Will cook in 'next'.

And here, too: it is safe to keep it in `next`.

> * js/bundle-verify-require-object-store (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at 747fbbaf11)
>  + bundle verify: error out if called without an object database
>
>  "git bundle verify" needs to see if prerequisite objects exist in
>  the receiving repository, but the command did not check if we are
>  in a repository upfront, which has been corrected.
>
>  Will cook in 'next'.

Yes, this topic should actually cook for a while.

> * js/fsmonitor-unflake (2019-05-28) 2 commits
>   (merged to 'next' on 2019-05-30 at 1aa850bc59)
>  + mark_fsmonitor_valid(): mark the index as changed if needed
>  + fill_stat_cache_info(): prepare for an fsmonitor fix
>
>  The data collected by fsmonitor was not properly written back to
>  the on-disk index file, breaking t7519 tests occasionally, which
>  has been corrected.
>
>  Will cook in 'next'.

Makes sense.

> * mm/p4-unshelve-windows-fix (2019-05-28) 1 commit
>  - p4 unshelve: fix "Not a valid object name HEAD0" on Windows
>
>  The command line to invoke a "git cat-file" command from inside
>  "git p4" was not properly quoted to protect a caret and running a
>  broken command on Windows, which has been corrected.
>
>  Will merge to 'next'.

Same here, this is a super old regression, and it will not hurt to cook it
a bit longer.

> * pb/request-pull-verify-remote-ref (2019-05-28) 2 commits
>  - request-pull: warn if the remote object is not the same as the local one
>  - request-pull: quote regex metacharacters in local ref
>
>  "git request-pull" learned to warn when the ref we ask them to pull
>  from in the local repository and in the published repository are
>  different.
>
>  Will merge to 'next'.

Quite honestly, I don't care about `request-pull`, for what I know, this
is shipped in Git for the exclusive use of the Linux kernel project, which
is a bit funny.

In any case: very old bug, so its best home is `next` for now.

> * po/git-help-on-git-itself (2019-05-16) 2 commits
>  - Doc: git.txt: remove backticks from link and add git-scm.com/docs
>  - git.c: show usage for accessing the git(1) help page
>
>  "git help git" was hard to discover (well, at least for some
>  people).
>
>  Will merge to 'next'.

I guess it would not hurt anybody (and get a bit more exposure) if it was
merged before v2.22.0, but it does not fix a problem introduced in this
cycle, so...

> * sw/git-p4-unshelve-branched-files (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-30 at e1985f61fc)
>  + git-p4: allow unshelving of branched files
>
>  "git p4" update.
>
>  Will cook in 'next'.

Agree.

> * vv/merge-squash-with-explicit-commit (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at 209baa3e55)
>  + merge: refuse --commit with --squash
>
>  "git merge --squash" is designed to update the working tree and the
>  index without creating the commit, and this cannot be countermanded
>  by adding the "--commit" option; the command now refuses to work
>  when both options are given.
>
>  Will cook in 'next'.

Makes sense to me.

> * xl/record-partial-clone-origin (2019-05-29) 1 commit
>  - clone: respect user supplied origin name when setting up partial clone
>
>  When creating a partial clone, the object filtering criteria is
>  recorded for the origin of the clone, but this incorrectly used a
>  hardcoded name "origin" to name that remote; it has been corrected
>  to honor the "--origin <name>" option.
>
>  Will merge to 'next'.

I am of two minds here: as far as I can tell, this fixes a regression that
has been introduced in 548719fbdc4c (clone: partial clone, 2017-12-08), so
it is super old.

On the other hand, the partial clone is a young feature and *just* picking
up steam, so I'd wish we could have this patch in an official version
rather earlier than later.

But I can live with it living in `next` for now.

> * ab/fail-prereqs-in-test (2019-05-14) 1 commit
>   (merged to 'next' on 2019-05-16 at d1be55f485)
>  + tests: add a special setup where prerequisites fail
>
>  Developer support to emulate unsatisfied prerequisites in tests to
>  ensure that the remainer of the tests still succeeds when tests
>  with prerequisites are skipped.
>
>  Will cook in 'next'.

I am excited to see this in `master` soon after v2.22.0.

> * jk/help-unknown-ref-fix (2019-05-15) 2 commits
>   (merged to 'next' on 2019-05-19 at e3e01160f7)
>  + help_unknown_ref(): check for refname ambiguity
>  + help_unknown_ref(): duplicate collected refnames
>
>  Improve the code to show args with potential typo that cannot be
>  interpreted as a commit-ish.
>
>  Will cook in 'next'.

I agree.

> * js/rebase-cleanup (2019-05-15) 5 commits
>   (merged to 'next' on 2019-05-16 at ccfed8f263)
>  + rebase: fold git-rebase--common into the -p backend
>  + sequencer: the `am` and `rebase--interactive` scripts are gone
>  + .gitignore: there is no longer a built-in `git-rebase--interactive`
>  + t3400: stop referring to the scripted rebase
>  + Drop unused git-rebase--am.sh
>
>  Update supporting parts of "git rebase" to remove code that should
>  no longer be used.
>
>  Will cook in 'next'.

Absolutely, there is no need to force this into v2.22.0.

Having said that, I already integrated this into Git fo Windows
v2.22.0-rc2... So I guess users on Windows will tell us if that broke
anything ;-)

> * jt/partial-clone-missing-ref-delta-base (2019-05-15) 2 commits
>   (merged to 'next' on 2019-05-29 at 5d7573a151)
>  + index-pack: prefetch missing REF_DELTA bases
>  + t5616: refactor packfile replacement
>
>  "git fetch" into a lazy clone forgot to fetch base objects that are
>  necessary to complete delta in a thin packfile, which has been
>  corrected.
>
>  Will cook in 'next'.

As with all things partial clone, I am of my usual two minds: I consider
it an experimental feature, still, so I'd love to move faster on it than
on other features. On the other hand, every such change risks introducing
regressions late in the game.

> * bl/userdiff-octave (2019-05-29) 2 commits
>   (merged to 'next' on 2019-05-29 at 6ed07afc89)
>  + userdiff: fix grammar and style issues
>   (merged to 'next' on 2019-05-19 at 9ea1180d6c)
>  + userdiff: add Octave
>
>  The pattern "git diff/grep" use to extract funcname and words
>  boundary for Matlab has been extend to cover Octave, which is more
>  or less equivalent.
>
>  Will cook in 'next'.

With userdiffs, I am pretty convinced that the only way we can cook them
really effectively is in official versions. I don't think that I know of
any Octave user who builds Git themselves (and yes, I know a couple of
Octave users, came even close to work with the group who started it in
Madison WI).

So I'd be fine with this still making it into v2.22.0.

> * ew/update-server-info (2019-05-15) 1 commit
>   (merged to 'next' on 2019-05-19 at bf4f2871ab)
>  + update-server-info: avoid needless overwrites
>
>  "git update-server-info" learned not to rewrite the file with the
>  same contents.
>
>  Will cook in 'next'.

Yep. Same rationale as with the other `update-server-info` topic.

> * nd/corrupt-worktrees (2019-05-15) 1 commit
>   (merged to 'next' on 2019-05-16 at d92c25f800)
>  + worktree add: be tolerant of corrupt worktrees
>
>  "git worktree add" used to fail when another worktree connected to
>  the same repository was corrupt, which has been corrected.
>
>  Will cook in 'next'.

While not an old regression, it was not introduced in *this* cycle. So I'm
fine with keeping it out of v2.22.0.

> * mh/import-transport-fd-fix (2019-05-16) 2 commits
>   (merged to 'next' on 2019-05-19 at 5e86f92f7a)
>  + Use xmmap_gently instead of xmmap in use_pack
>  + dup() the input fd for fast-import used for remote helpers
>
>  The ownership rule for the file descriptor to fast-import remote
>  backend was mixed up, leading to unrelated file descriptor getting
>  closed, which has been fixed.
>
>  Will cook in 'next'.

Makes sense, too. That's an old regression if I'm not mistaken.

> * ab/deprecate-R-for-dynpath (2019-05-19) 1 commit
>   (merged to 'next' on 2019-05-19 at 944976e981)
>  + Makefile: remove the NO_R_TO_GCC_LINKER flag
>
>  The way of specifying the path to find dynamic libraries at runtime
>  has been simplified.  The old default to pass -R/path/to/dir has been
>  replaced with the new default to pass -Wl,-rpath,/path/to/dir,
>  which is the more recent GCC uses.  Those who need to build with an
>  old GCC can still use "CC_LD_DYNPATH=-R"
>
>  Will cook in 'next'.

Yep.

> * ba/clone-remote-submodules (2019-05-28) 1 commit
>   (merged to 'next' on 2019-05-29 at 71972f94c2)
>  + clone: add `--remote-submodules` flag
>
>  "git clone --recurse-submodules" learned to set up the submodules
>  to ignore commit object names recorded in the superproject gitlink
>  and instead use the commits that happen to be at the tip of the
>  remote-tracking branches from the get-go, by passing the new
>  "--remote-submodules" option.
>
>  Will cook in 'next'.

Are we really sure that this is a good option name? With that description,
I would have expected `--recurse-submodules=follow-tips` or some such.

In other words, I would have been in favor of keeping this in `pu` for a
little while longer. But it's already in `next`...

> * ds/close-object-store (2019-05-28) 3 commits
>  - packfile: rename close_all_packs to close_object_store
>  - packfile: close commit-graph in close_all_packs
>  - commit-graph: use raw_object_store when closing
>  (this branch uses ds/commit-graph-write-refactor.)
>
>  The commit-graph file is now part of the "files that the runtime
>  may keep open file descriptors on, all of which would need to be
>  closed when done with the object store", and the file descriptor to
>  an existing commit-graph file now is closed before "gc" finializes
>  a new instance to replace it.
>
>  Waiting on ds/commit-graph-write-refactor to stabilize.

FWIW I backported this to Git for Windows, as the underlying bug would
prevent an auto gc from working as intended (iff the commit graph feature
is turned on, of course).

> * ml/userdiff-rust (2019-05-30) 2 commits
>  - userdiff: two simplifications of patterns for rust
>   (merged to 'next' on 2019-05-19 at 1266fddce5)
>  + userdiff: add built-in pattern for rust
>
>  The pattern "git diff/grep" use to extract funcname and words
>  boundary for Rust has been added.
>
>  Will cook in 'next'.

The same comment as for Octave applies (modulo me knowing anybody on the
team who started the project).

> * pw/rebase-edit-message-for-replayed-merge (2019-05-19) 1 commit
>   (merged to 'next' on 2019-05-19 at dc3e30641c)
>  + rebase -r: always reword merge -c
>
>  A "merge -c" instruction during "git rebase --rebase-merges" should
>  give the user a chance to edit the log message, even when there is
>  otherwise no need to create a new merge and replace the existing
>  one (i.e. fast-forward instead), but did not.  Which has been
>  corrected.
>
>  Will cook in 'next'.

I backported this also, mainly for my own convenience :-)

It really is a pretty obvious bug fix, but the bug has been with us for
quite a while.

> * sb/format-patch-base-patch-id-fix (2019-05-08) 2 commits
>   (merged to 'next' on 2019-05-15 at 1ab7d2b71c)
>  + format-patch: make --base patch-id output stable
>  + format-patch: inform user that patch-id generation is unstable
>
>  The recently added "--base" option of "format-patch" computed the

Was it not included in v2.9.0? That's not recent. Or maybe my Git fu
deserts me?

$ git tag --contains fa2ab86d18f16ab5e6d2f2cd6e8cc00460bada17
...
v2.9.0
...

(I think that the feature was introduced in fa2ab86d18f1 (format-patch:
add '--base' option to record base tree info, 2016-04-26)).

>  patch-ids for prerequisite patches in an unstable way, which has
>  been updated to compute in a way that is compatible with "git
>  patch-id --stable".
>
>  Will cook in 'next'.

Yes, this can cook for a bit.

> * ab/send-email-transferencoding-fix (2019-05-29) 7 commits
>   (merged to 'next' on 2019-05-29 at c8a99d18c0)
>  + send-email: fix regression in sendemail.identity parsing
>  + send-email: document --no-[to|cc|bcc]
>  + send-email: fix broken transferEncoding tests
>  + send-email: remove cargo-culted multi-patch pattern in tests
>   (merged to 'next' on 2019-05-13 at 38c6a1e7e0)
>  + send-email: do defaults -> config -> getopt in that order
>  + send-email: rename the @bcclist variable for consistency
>  + send-email: move the read_config() function above getopts
>
>  Since "git send-email" learned to take 'auto' as the value for the
>  transfer-encoding, it by mistake stopped honoring the values given
>  to the configuration variables sendemail.transferencoding and/or
>  sendemail.<ident>.transferencoding.  This has been corrected to
>  (finally) redoing the order of setting the default, reading the
>  configuration and command line options.
>
>  Will cook in 'next'.

I guess many users of `git send-email` actually build their Git
themselves, so cooking it in `next` should give this patch series some
good exposure.

> * dl/format-patch-notes-config (2019-05-17) 2 commits
>   (merged to 'next' on 2019-05-19 at d3f6f1872b)
>  + format-patch: teach format.notes config option
>  + git-format-patch.txt: document --no-notes option
>
>  "git format-patch" learns a configuration to set the default for
>  its --notes=<ref> option.
>
>  Will cook in 'next'.

Sounds good to me.

> * jk/unused-params-final-batch (2019-05-13) 14 commits
>   (merged to 'next' on 2019-05-15 at ef7435264c)
>  + verify-commit: simplify parameters to run_gpg_verify()
>  + show-branch: drop unused parameter from show_independent()
>  + rev-list: drop unused void pointer from finish_commit()
>  + remove_all_fetch_refspecs(): drop unused "remote" parameter
>  + receive-pack: drop unused "commands" from prepare_shallow_update()
>  + pack-objects: drop unused rev_info parameters
>  + name-rev: drop unused parameters from is_better_name()
>  + mktree: drop unused length parameter
>  + wt-status: drop unused status parameter
>  + read-cache: drop unused parameter from threaded load
>  + clone: drop dest parameter from copy_alternates()
>  + submodule: drop unused prefix parameter from some functions
>  + builtin: consistently pass cmd_* prefix to parse_options
>  + cmd_{read,write}_tree: rename "unused" variable that is used
>
>  Remove many unused parameters throughout the codebase, with the
>  ultimate aim to allow us compile with -Wunused-parameter cleanly.
>
>  Will cook in 'next'.

What a heroic effort. I look forward to having this in `master` short
after v2.22.0.

> * nd/init-relative-template-fix (2019-05-13) 1 commit
>   (merged to 'next' on 2019-05-15 at 4d5b17f712)
>  + init: make --template path relative to $CWD
>
>  A relative pathname given to "git init --template=<path> <repo>"
>  ought to be relative to the directory "git init" gets invoked in,
>  but it instead was made relative to the repository, which has been
>  corrected.
>
>  Will cook in 'next'.

Yep, makes sense, if you ask me.

> * en/fast-export-encoding (2019-05-14) 5 commits
>   (merged to 'next' on 2019-05-16 at c88bd3edb5)
>  + fast-export: do automatic reencoding of commit messages only if requested
>  + fast-export: differentiate between explicitly UTF-8 and implicitly UTF-8
>  + fast-export: avoid stripping encoding header if we cannot reencode
>  + fast-import: support 'encoding' commit header
>  + t9350: fix encoding test to actually test reencoding
>
>  The "git fast-export/import" pair has been taught to handle commits
>  with log messages in encoding other than UTF-8 better.
>
>  Will cook in 'next'.

Yes, please ;-)

> * nd/merge-quit (2019-05-19) 2 commits
>   (merged to 'next' on 2019-05-19 at 9880e7ee4e)
>  + merge: add --quit
>  + merge: remove drop_save() in favor of remove_merge_branch_state()
>
>  "git merge" learned "--quit" option that cleans up the in-progress
>  merge while leaving the working tree and the index still in a mess.
>
>  Will cook in 'next'.

Also: yes, please!

> * es/first-contrib-tutorial (2019-05-29) 3 commits
>   (merged to 'next' on 2019-05-30 at 96317960ab)
>  + doc: add some nit fixes to MyFirstContribution
>   (merged to 'next' on 2019-05-19 at 9ddfae82bf)
>  + documentation: add anchors to MyFirstContribution
>  + documentation: add tutorial for first contribution
>
>  A new tutorial targetting specifically aspiring git-core
>  developers.
>
>  Will cook in 'next'.

As with the `GIT_DEBUGGER` topic, I am not so sure that it makes sense to
cook in `next`, as it will hardly get any exposure, if any at all.

> * nd/worktree-name-sanitization (2019-05-15) 1 commit
>   (merged to 'next' on 2019-05-16 at 9a2dd33122)
>  + worktree add: sanitize worktree names
>
>  In recent versions of Git, per-worktree refs are exposed in
>  refs/worktrees/<wtname>/ hierarchy, which means that worktree names
>  must be a valid refname component.  The code now sanitizes the names
>  given to worktrees, to make sure these refs are well-formed.
>
>  Will cook in 'next'.

I am in favor of cooking this a bit more, too.

Hopefully it is useful for you to hear my thoughts on those branches? If
not, please let me know, I do not want to impose my opinion on you.

Thanks,
Dscho

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Junio C Hamano]

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

>> The second round of release candidate has been tagged, after
>> slipping for several days to merge a handful of last-minute
>> regression fixes.
>
> You hinted in an earlier "What's cooking" that you'd maybe go for an -rc3.
> Is that still the case?

That was back when I did not know exactly what shape the tip of
'master' was.  I agree with what you said in your announcement of
the Windows port of the -rc2; it seems that the release candidates
are in reasonably good shape so far, and perhaps we can do without
another round, even though it may be prudent to slip the final for a
few days to give enough space between -rc2 and the final.

Thanks.

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Johannes Schindelin]

Hi Junio,

On Fri, 31 May 2019, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> The second round of release candidate has been tagged, after slipping
> >> for several days to merge a handful of last-minute regression fixes.
> >
> > You hinted in an earlier "What's cooking" that you'd maybe go for an
> > -rc3. Is that still the case?
>
> That was back when I did not know exactly what shape the tip of 'master'
> was.  I agree with what you said in your announcement of the Windows
> port of the -rc2; it seems that the release candidates are in reasonably
> good shape so far, and perhaps we can do without another round, even
> though it may be prudent to slip the final for a few days to give enough
> space between -rc2 and the final.

Okay! I think we're on the same page.

Thanks,
Dscho

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Junio C Hamano]

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

> On Thu, 30 May 2019, Junio C Hamano wrote:
>
>> * bb/unicode-12.1-reiwa (2019-05-29) 1 commit
>>   (merged to 'next' on 2019-05-30 at 016465335c)
>>  + unicode: update the width tables to Unicode 12.1
>> <<
>> * bb/unicode-12.1-reiwa (2019-05-29) 1 commit
>>  - unicode: update the width tables to Unicode 12.1
>> >>
>>
>>  Update to Unicode 12.1 width table.
>>
>>  Will cook in 'next'.
>
> I would actually be in favor of merging this before v2.22.0. It's not like
> this is a feature we need to perfect, we just integrate upstream changes.

It is not really an import of "upstream change", when it is
expressed in a form of a table that we invent and let our code read.

The patch coalesces two entries that describe two ranges with
1-codepoint gap into one entry that eliminates the gap in the table,
and I did also read the code that uses the table and I am reasonably
certain that there won't be any bug introduced by this change [*1*],
so in that sense "cook in 'next'" is being overly conservative.

	Side note: *1* if the patch were to extend one end of the
	range so that these two entries describe adjacent two ranges
	without any gap, and if the code that uses the table had a
	bug that gets triggered when given two ranges that do not
	have any gap between them, then without such careful
	inspection, we may have said "this is just upstream changes,
	let's fast-track it" and caused regression.

But I am marking it as such, not due to conservativeness, but mostly
out of principle.  Once we start saying "this is trivial enough, so
let's merge straight to 'master'" for one topic, it will lead to
others jumping up and down saying "that other topic is also
trivially correct" to swamp me, and mistakes are bound to happen.

In other words, as I said in "What's cooking" report one issue ago,
the criteria is no longer "this is obviously correct"---it is "this
is obvious and trivial fix for a regression".

>> * ab/hash-object-doc (2019-05-28) 1 commit
>>  - hash-object doc: stop mentioning git-cvsimport
>>
>>  Doc update.
>>
>>  Will merge to 'next'.
>
> Similarly, I think it would not hurt to merge this before v2.22.0.

Likewise.

More importantly, the above is only is 1/3 of the topic, and while I
am in agreement with the reviewer(s) who were negative on the other
two, we haven't heard a response/rebuttal.

>> * ew/server-info-remove-crufts (2019-05-28) 1 commit
>>   (merged to 'next' on 2019-05-29 at 655ba18f30)
>>  + server-info: do not list unlinked packs
>>
>>  "git update-server-info" used to leave stale packfiles in its
>>  output, which has been corrected.
>>
>>  Will cook in 'next'.
>
> I do dream of the day when we can just get rid of the entire non-smart
> HTTP stuff.

;-)

>> * jk/HEAD-symref-in-xfer-namespaces (2019-05-28) 1 commit
>>   (merged to 'next' on 2019-05-29 at c2cfe38955)
>>  + upload-pack: strip namespace from symref data
>>
>>  The server side support for "git fetch" used to show incorrect
>>  value for the HEAD symbolic ref when the namespace feature is in
>>  use, which has been corrected.
>>
>>  Will cook in 'next'.
>
> This is an older regression, so it should probably be kept in `next` for
> now.

I do not think it is even a regression.  Back when I did the "symref
target in capability", I was aware of, but did not bother being
careful not to break, the "separate namespace" stuff ;-).  I think
it was broken from day one.

>> * mm/p4-unshelve-windows-fix (2019-05-28) 1 commit
>>  - p4 unshelve: fix "Not a valid object name HEAD0" on Windows
>>
>>  The command line to invoke a "git cat-file" command from inside
>>  "git p4" was not properly quoted to protect a caret and running a
>>  broken command on Windows, which has been corrected.
>>
>>  Will merge to 'next'.
>
> Same here, this is a super old regression, and it will not hurt to cook it
> a bit longer.

Also, as (I think) you saw my "git grep", we may want to correct all
the problems with the same root, and the above solve only one of the
two.

>> * po/git-help-on-git-itself (2019-05-16) 2 commits
>>  - Doc: git.txt: remove backticks from link and add git-scm.com/docs
>>  - git.c: show usage for accessing the git(1) help page
>>
>>  "git help git" was hard to discover (well, at least for some
>>  people).
>>
>>  Will merge to 'next'.
>
> I guess it would not hurt anybody (and get a bit more exposure) if it was
> merged before v2.22.0, but it does not fix a problem introduced in this
> cycle, so...

Yeah, I think you already know this but my stance towards these
"would never hurt to merge even in -rc period" topics is to merge
them soon after the final.

>> * ba/clone-remote-submodules (2019-05-28) 1 commit
>>   (merged to 'next' on 2019-05-29 at 71972f94c2)
>>  + clone: add `--remote-submodules` flag
>>
>>  "git clone --recurse-submodules" learned to set up the submodules
>>  to ignore commit object names recorded in the superproject gitlink
>>  and instead use the commits that happen to be at the tip of the
>>  remote-tracking branches from the get-go, by passing the new
>>  "--remote-submodules" option.
>>
>>  Will cook in 'next'.
>
> Are we really sure that this is a good option name? With that description,
> I would have expected `--recurse-submodules=follow-tips` or some such.
>
> In other words, I would have been in favor of keeping this in `pu` for a
> little while longer. But it's already in `next`...

As far as I am concerned, ones in 'next' that is not meant to be
fast-tracked to 'master' during the -rc period are like only in
`pu`.  Soon after the final, when 'next' is rewound, any of them can
be kicked out to give it a fresh start, and it is a good time to
think and nominate which ones to boot and reboot, like you just did.

As to your question, I do not have a strong opinion either way.
Input from folks more invested in submodules, and especially from
those who want to use submodules in non-traditional ways, would be
most welcome.  To me, it feels that the "ignore what gitlink entries
say, and use the commits that happen to be pointed at by refs of a
clone of the submodule you happen to follow" is not really a good
match to the way "gitlink" based Git submodules are designed to be
used, but that mode of the operation is not wrong per-se (it was
just that we did not design the system to support well).

>> * ds/close-object-store (2019-05-28) 3 commits
>>  - packfile: rename close_all_packs to close_object_store
>>  - packfile: close commit-graph in close_all_packs
>>  - commit-graph: use raw_object_store when closing
>>  (this branch uses ds/commit-graph-write-refactor.)
>>
>>  The commit-graph file is now part of the "files that the runtime
>>  may keep open file descriptors on, all of which would need to be
>>  closed when done with the object store", and the file descriptor to
>>  an existing commit-graph file now is closed before "gc" finializes
>>  a new instance to replace it.
>>
>>  Waiting on ds/commit-graph-write-refactor to stabilize.
>
> FWIW I backported this to Git for Windows, as the underlying bug would
> prevent an auto gc from working as intended (iff the commit graph feature
> is turned on, of course).

Yes, I can see how a system that does not allow filesystem
operations on a still-open file would need these three patches.  How
ready is the underlying topic?  IIRC there were a few internal API
details still to be reworked?

Thanks for your thoughtful comments.

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Johannes Schindelin]

Hi Junio,

On Fri, 31 May 2019, Junio C Hamano wrote:

> [...] as I said in "What's cooking" report one issue ago, the criteria
> is no longer "this is obviously correct"---it is "this is obvious and
> trivial fix for a regression".

I heard that, just wanted to give you my stance ;-)

In Git for Windows, I am not *quite* as conservative, but then, I do not
have to deal with the onslaught of a gazillion patch series, either.

And of course, Git for Windows caters to *Windows* users, which does
change the perspective quite a bit: file locking issues are no longer just
a nuisance, scripts are too slow to be called production-ready,
repositories tend to be ridiculously large (a lot larger than regular open
source repositories, for sure), etc.

So for example, I did fast-track the experimental built-in `git add -i`,
even if it was tested only by me, and for less than two months: the
benefit is just too great to pass up.

So yeah, I run Git for Windows in a different way than you run Git, and I
think both ways have their merits.

> [...]
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 30 May 2019, Junio C Hamano wrote:
> >
> >> * po/git-help-on-git-itself (2019-05-16) 2 commits
> >>  - Doc: git.txt: remove backticks from link and add git-scm.com/docs
> >>  - git.c: show usage for accessing the git(1) help page
> >>
> >>  "git help git" was hard to discover (well, at least for some
> >>  people).
> >>
> >>  Will merge to 'next'.
> >
> > I guess it would not hurt anybody (and get a bit more exposure) if it was
> > merged before v2.22.0, but it does not fix a problem introduced in this
> > cycle, so...
>
> Yeah, I think you already know this but my stance towards these
> "would never hurt to merge even in -rc period" topics is to merge
> them soon after the final.

Fair enough.

> >> * ba/clone-remote-submodules (2019-05-28) 1 commit
> >>   (merged to 'next' on 2019-05-29 at 71972f94c2)
> >>  + clone: add `--remote-submodules` flag
> >>
> >>  "git clone --recurse-submodules" learned to set up the submodules
> >>  to ignore commit object names recorded in the superproject gitlink
> >>  and instead use the commits that happen to be at the tip of the
> >>  remote-tracking branches from the get-go, by passing the new
> >>  "--remote-submodules" option.
> >>
> >>  Will cook in 'next'.
> >
> > Are we really sure that this is a good option name? With that
> > description, I would have expected `--recurse-submodules=follow-tips`
> > or some such.
> >
> > In other words, I would have been in favor of keeping this in `pu` for
> > a little while longer. But it's already in `next`...
>
> As far as I am concerned, ones in 'next' that is not meant to be
> fast-tracked to 'master' during the -rc period are like only in `pu`.
> Soon after the final, when 'next' is rewound, any of them can be kicked
> out to give it a fresh start, and it is a good time to think and
> nominate which ones to boot and reboot, like you just did.
>
> As to your question, I do not have a strong opinion either way. Input
> from folks more invested in submodules, and especially from those who
> want to use submodules in non-traditional ways, would be most welcome.
> To me, it feels that the "ignore what gitlink entries say, and use the
> commits that happen to be pointed at by refs of a clone of the submodule
> you happen to follow" is not really a good match to the way "gitlink"
> based Git submodules are designed to be used, but that mode of the
> operation is not wrong per-se (it was just that we did not design the
> system to support well).

I am probably a terrible person to ask about submodules, as I am of the
firm opinion that friends don't let friends use submodules. And people who
suggest to their enememies to use submodules are just awful people that I
don't want to talk to, like, ever.

And it is no secret that I believe that the submodule feature was just
pushed through for no other reason than to shut up the people who wanted
to discuss a Git feature that would reflect the svn:externals (something
for which there are real scenarios out there, and they were just
steamrollered by the push for submodules).

Nevertheless, I still think that even a feature as unwise as submodules
*can* be the best solution under certain circumstances, at least for now.

And those circumstances deserve really good naming. Just like all other
Git use cases.

> >> * ds/close-object-store (2019-05-28) 3 commits
> >>  - packfile: rename close_all_packs to close_object_store
> >>  - packfile: close commit-graph in close_all_packs
> >>  - commit-graph: use raw_object_store when closing
> >>  (this branch uses ds/commit-graph-write-refactor.)
> >>
> >>  The commit-graph file is now part of the "files that the runtime
> >>  may keep open file descriptors on, all of which would need to be
> >>  closed when done with the object store", and the file descriptor to
> >>  an existing commit-graph file now is closed before "gc" finializes
> >>  a new instance to replace it.
> >>
> >>  Waiting on ds/commit-graph-write-refactor to stabilize.
> >
> > FWIW I backported this to Git for Windows, as the underlying bug would
> > prevent an auto gc from working as intended (iff the commit graph feature
> > is turned on, of course).
>
> Yes, I can see how a system that does not allow filesystem
> operations on a still-open file would need these three patches.  How
> ready is the underlying topic?  IIRC there were a few internal API
> details still to be reworked?

Well, what can I say: I cheated. I rebased these three patches to Git for
Windows' `master` *excluding* `ds/commit-graph-write-refactor`.

Because even I am conservative, at times ;-)

AFAICT even Stolee is on board with giving that refactoring effort a bit
more time.

Ciao,
Dscho

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Junio C Hamano]

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

>> * cc/list-objects-filter-wo-sparse-path (2019-05-29) 1 commit
>>   (merged to 'next' on 2019-05-30 at 5a294203ad)
>>  + list-objects-filter: disable 'sparse:path' filters
>>
>>  Disable "--filter=sparse:path=<path>" that would allow reading from
>>  paths on the filesystem.
>>
>>  Will cook in 'next'.
>
> Not sure whether we want to fast-track this into v2.22.0. There is a risk.
>
> But then, the longer we ship with `--filter=sparse:path` *enabled*, the
> more we invite users to actually try and use it.

This one I wasn't quite decided on, for exactly the same reason why
you said "Not sure".  I am inclined to merge it to 'master' at this
point, as it indeed is a risk to keep it enabled.

The only remaining question it raises is if it makes it worthwhile
to add another rc; it introduces one new localizable string, too.

Thanks.

cc/list-objects-filter-wo-sparse-path, was Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Johannes Schindelin]

Hi Junio,

On Fri, 31 May 2019, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> * cc/list-objects-filter-wo-sparse-path (2019-05-29) 1 commit
> >>   (merged to 'next' on 2019-05-30 at 5a294203ad)
> >>  + list-objects-filter: disable 'sparse:path' filters
> >>
> >>  Disable "--filter=sparse:path=<path>" that would allow reading from
> >>  paths on the filesystem.
> >>
> >>  Will cook in 'next'.
> >
> > Not sure whether we want to fast-track this into v2.22.0. There is a risk.
> >
> > But then, the longer we ship with `--filter=sparse:path` *enabled*, the
> > more we invite users to actually try and use it.
>
> This one I wasn't quite decided on, for exactly the same reason why
> you said "Not sure".  I am inclined to merge it to 'master' at this
> point, as it indeed is a risk to keep it enabled.
>
> The only remaining question it raises is if it makes it worthwhile
> to add another rc; it introduces one new localizable string, too.

That'd be more a question to the L10N coordinator (who you Cc:ed)... Jiang
Lin? Would that require another -rc?

Ciao,
Dscho

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Kaartic Sivaraam]

Hi Junio,



On 31 May 2019 23:04:38 GMT+05:30, Junio C Hamano <gitster@pobox.com> wrote:
>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Thu, 30 May 2019, Junio C Hamano wrote:
>>> * ds/close-object-store (2019-05-28) 3 commits
>>>  - packfile: rename close_all_packs to close_object_store
>>>  - packfile: close commit-graph in close_all_packs
>>>  - commit-graph: use raw_object_store when closing
>>>  (this branch uses ds/commit-graph-write-refactor.)
>>>
>>>  The commit-graph file is now part of the "files that the runtime
>>>  may keep open file descriptors on, all of which would need to be
>>>  closed when done with the object store", and the file descriptor to
>>>  an existing commit-graph file now is closed before "gc" finializes
>>>  a new instance to replace it.
>>>
>>>  Waiting on ds/commit-graph-write-refactor to stabilize.
>>

A typo which has possibly been overlooked:

s/finializes/finalizes/


-- 
Sivaraam

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: cc/list-objects-filter-wo-sparse-path, was Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Jiang Xin]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 于2019年6月1日周六 上午4:26写道：
>
> Hi Junio,
>
> On Fri, 31 May 2019, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > >> * cc/list-objects-filter-wo-sparse-path (2019-05-29) 1 commit
> > >>   (merged to 'next' on 2019-05-30 at 5a294203ad)
> > >>  + list-objects-filter: disable 'sparse:path' filters
> > >>
> > >>  Disable "--filter=sparse:path=<path>" that would allow reading from
> > >>  paths on the filesystem.
> > >>
> > >>  Will cook in 'next'.
> > >
> > > Not sure whether we want to fast-track this into v2.22.0. There is a risk.
> > >
> > > But then, the longer we ship with `--filter=sparse:path` *enabled*, the
> > > more we invite users to actually try and use it.
> >
> > This one I wasn't quite decided on, for exactly the same reason why
> > you said "Not sure".  I am inclined to merge it to 'master' at this
> > point, as it indeed is a risk to keep it enabled.
> >
> > The only remaining question it raises is if it makes it worthwhile
> > to add another rc; it introduces one new localizable string, too.
>
> That'd be more a question to the L10N coordinator (who you Cc:ed)... Jiang
> Lin? Would that require another -rc?

Current l10n round 2 is based on v2.22.0-rc2, and only 5 days left for the
final release. If merge the topic "cc/list-objects-filter-wo-sparse-path" to
master, a -rc3 is needed for the new message introduced:

    +#: list-objects-filter-options.c:84
    +msgid "sparse:path filters support has been dropped"
    +msgstr ""

--
Jiang Xin

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Philip Oakley]

On 31/05/2019 18:34, Junio C Hamano wrote:
>>> * po/git-help-on-git-itself (2019-05-16) 2 commits
>>>   - Doc: git.txt: remove backticks from link and add git-scm.com/docs
>>>   - git.c: show usage for accessing the git(1) help page
>>>
>>>   "git help git" was hard to discover (well, at least for some
>>>   people).
>>>
>>>   Will merge to 'next'.
>> I guess it would not hurt anybody (and get a bit more exposure) if it was
>> merged before v2.22.0, but it does not fix a problem introduced in this
>> cycle, so...
> Yeah, I think you already know this but my stance towards these
> "would never hurt to merge even in -rc period" topics is to merge
> them soon after the final.
>
I'm perfectly happy with this. As a small patch I thought it worth 
'getting started promptly', even if it was in the early rc period, and 
I'm happy to wait and let the wheels turn steadily.
--
Philip

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Nickolai Belakovski]

On Thu, May 30, 2019 at 5:20 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> * nb/branch-show-other-worktrees-head (2019-05-07) 3 commits
>  - branch: add worktree info on verbose output
>  - branch: update output to include worktree info
>  - ref-filter: add worktreepath atom
>
>  "git branch --list" learned to show branches that are checked out
>  in other worktrees connected to the same repository prefixed with
>  '+', similar to the way the currently checked out branch is shown
>  with '*' in front.
>

I see that this has been in 'pu' for some time now. Is there something
holding it up from going into 'next'?

Re: What's cooking in git.git (May 2019, #05; Thu, 30)

[Johannes Schindelin]

Hi,

On Wed, 5 Jun 2019, Nickolai Belakovski wrote:

> On Thu, May 30, 2019 at 5:20 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > * nb/branch-show-other-worktrees-head (2019-05-07) 3 commits
> >  - branch: add worktree info on verbose output
> >  - branch: update output to include worktree info
> >  - ref-filter: add worktreepath atom
> >
> >  "git branch --list" learned to show branches that are checked out
> >  in other worktrees connected to the same repository prefixed with
> >  '+', similar to the way the currently checked out branch is shown
> >  with '*' in front.
> >
>
> I see that this has been in 'pu' for some time now. Is there something
> holding it up from going into 'next'?

If all that is needed is a vote in favor of this feature: Here is my
"yay!". I am a heavy user of worktrees, and this strikes me as something I
want to see in the output of `git branch --list`.

Thanks,
Johannes