What's cooking in git.git (Oct 2019, #02; Mon, 7)

What's cooking in git.git (Oct 2019, #02; Mon, 7)

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

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"]

* ah/doc-submodule-ignore-submodules (2019-09-18) 1 commit
  (merged to 'next' on 2019-09-30 at 9eb3de8d1b)
 + doc: fix reference to --ignore-submodules

 Docfix.


* am/mailmap-andrey-mazo (2019-09-20) 1 commit
  (merged to 'next' on 2019-09-30 at 5e373b3cba)
 + .mailmap: update email address of Andrey Mazo


* bc/doc-use-docbook-5 (2019-09-16) 1 commit
  (merged to 'next' on 2019-09-30 at 31c4cf70ae)
 + Documentation: fix build with Asciidoctor 2

 Start using DocBook 5 (instead of DocBook 4.5) as Asciidoctor 2.0
 no longer works with the older one.


* bw/submodule-helper-usage-fix (2019-09-29) 1 commit
  (merged to 'next' on 2019-09-30 at 78d2f28ef7)
 + builtin/submodule--helper: fix usage string for 'update-clone'

 Typofix.


* cb/do-not-use-test-cmp-with-a (2019-09-28) 1 commit
  (merged to 'next' on 2019-09-30 at 273ff0e62d)
 + t4038: Remove non-portable '-a' option passed to test_cmp

 Test portability fix.


* cb/skip-utf8-check-with-pcre1 (2019-09-09) 1 commit
  (merged to 'next' on 2019-09-30 at f6113b33cf)
 + grep: skip UTF8 checks explicitly

 Make sure the grep machinery does not abort when seeing a payload
 that is not UTF-8 even when JIT is not in use with PCRE1.


* cc/multi-promisor (2019-10-02) 2 commits
  (merged to 'next' on 2019-10-03 at a0a8ea56a9)
 + promisor-remote: skip move_to_tail when no-op
  (merged to 'next' on 2019-09-30 at c4826f5a08)
 + promisor-remote.h: drop extern from function declaration

 Cleanup.


* cc/svn-fe-py-shebang (2019-09-18) 1 commit
  (merged to 'next' on 2019-09-30 at 27c8457202)
 + contrib/svn-fe: fix shebang for svnrdump_sim.py


* cs/pretty-formats-doc-typofix (2019-09-12) 1 commit
  (merged to 'next' on 2019-09-30 at a29a425208)
 + doc: minor formatting fix

 Doc fix.


* dl/cocci-everywhere (2019-09-17) 4 commits
  (merged to 'next' on 2019-09-30 at 1bb1c0846f)
 + Makefile: run coccicheck on more source files
 + Makefile: strip leading ./ in $(FIND_SOURCE_FILES)
 + Makefile: define THIRD_PARTY_SOURCES
 + Makefile: strip leading ./ in $(LIB_H)

 Coccinelle checks are done on more source files than before now.


* dl/complete-rebase-and-archive (2019-09-12) 2 commits
  (merged to 'next' on 2019-09-30 at ddeb81ff41)
 + completion: teach archive to use __gitcomp_builtin
 + completion: teach rebase to use __gitcomp_builtin

 The command line completion for "git archive" and "git rebase" are
 now made less prone to go out of sync with the binary.


* dl/honor-cflags-in-hdr-check (2019-10-03) 5 commits
  (merged to 'next' on 2019-10-03 at a346b79a78)
 + ci: run `hdr-check` as part of the `Static Analysis` job
  (merged to 'next' on 2019-09-30 at 708fb8988e)
 + Makefile: emulate compile in $(HCO) target better
 + pack-bitmap.h: remove magic number
 + promisor-remote.h: include missing header
 + apply.h: include missing header

 Dev support.


* dl/submodule-set-branch (2019-09-16) 1 commit
  (merged to 'next' on 2019-09-30 at c66b398cc1)
 + git-submodule.txt: fix AsciiDoc formatting error

 Docfix.


* gs/commit-graph-progress (2019-09-18) 1 commit
  (merged to 'next' on 2019-09-30 at 7c03eac969)
 + commit-graph: add --[no-]progress to write and verify


* hb/hg-to-git-py3 (2019-09-18) 1 commit
  (merged to 'next' on 2019-09-30 at 28f7e9bae3)
 + hg-to-git: make it compatible with both python3 and python2

 The hg-to-git script (in contrib/) has been updated to work with
 Python 3.


* jc/git-gui-has-maintainer (2019-09-18) 1 commit
  (merged to 'next' on 2019-09-30 at dfe61e947c)
 + SubmittingPatches: git-gui has a new maintainer


* jk/commit-graph-cleanup (2019-09-09) 2 commits
  (merged to 'next' on 2019-09-30 at f78e24d14b)
 + commit-graph: turn off save_commit_buffer
 + commit-graph: don't show progress percentages while expanding reachable commits

 A pair of small fixups to "git commit-graph" have been applied.


* jk/disable-commit-graph-during-upload-pack (2019-09-12) 2 commits
  (merged to 'next' on 2019-09-30 at 87dae76fb7)
 + upload-pack: disable commit graph more gently for shallow traversal
 + commit-graph: bump DIE_ON_LOAD check to actual load-time

 The "upload-pack" (the counterpart of "git fetch") needs to disable
 commit-graph when responding to a shallow clone/fetch request, but
 the way this was done made Git panic, which has been corrected.


* jk/list-objects-optim-wo-trees (2019-09-12) 1 commit
  (merged to 'next' on 2019-09-30 at 9ef098d07f)
 + list-objects: don't queue root trees unless revs->tree_objects is set

 The object traversal machinery has been optimized not to load tree
 objects when we are only interested in commit history.


* jk/partial-clone-sparse-blob (2019-09-16) 4 commits
  (merged to 'next' on 2019-09-30 at 44b33488ea)
 + list-objects-filter: use empty string instead of NULL for sparse "base"
 + list-objects-filter: give a more specific error sparse parsing error
 + list-objects-filter: delay parsing of sparse oid
 + t5616: test cloning/fetching with sparse:oid=<oid> filter

 The name of the blob object that stores the filter specification
 for sparse cloning/fetching was interpreted in a wrong place in the
 code, causing Git to abort.


* js/doc-patch-text (2019-09-17) 2 commits
  (merged to 'next' on 2019-09-30 at f9b391a66b)
 + diff, log doc: small grammer, format, and language fixes
 + diff, log doc: say "patch text" instead of "patches"

 Docfix.


* jt/cache-tree-avoid-lazy-fetch-during-merge (2019-09-09) 1 commit
  (merged to 'next' on 2019-09-30 at 5d8ffc2e0f)
 + cache-tree: do not lazy-fetch tentative tree

 The cache-tree code has been taught to be less aggressive in
 attempting to see if a tree object it computed already exists in
 the repository.


* jt/merge-recursive-symlink-is-not-a-dir-in-way (2019-09-20) 1 commit
  (merged to 'next' on 2019-09-30 at a5d6788e2e)
 + merge-recursive: symlink's descendants not in way

 A bug in merge-recursive code that triggers when a branch with a
 symbolic link is merged with a branch that replaces it with a
 directory has been fixed.


* ma/asciidoctor-more-fixes (2019-09-09) 7 commits
  (merged to 'next' on 2019-09-30 at 4937cac46f)
 + gitweb.conf.txt: switch pluses to backticks to help Asciidoctor
 + git-merge-index.txt: wrap shell listing in "----"
 + git-receive-pack.txt: wrap shell [script] listing in "----"
 + git-ls-remote.txt: wrap shell listing in "----"
 + Documentation: wrap config listings in "----"
 + git-merge-base.txt: render indentations correctly under Asciidoctor
 + Documentation: wrap blocks with "--"

 Doc formatting updates.


* ma/asciidoctor-refmiscinfo (2019-09-16) 3 commits
  (merged to 'next' on 2019-09-30 at e5d13aceb8)
 + doc-diff: replace --cut-header-footer with --cut-footer
 + asciidoctor-extensions: provide `<refmiscinfo/>`
 + Doc/Makefile: give mansource/-version/-manual attributes

 Update support for Asciidoctor documentation toolchain.


* ma/user-manual-markup-update (2019-09-28) 4 commits
  (merged to 'next' on 2019-09-30 at 822fa2ed99)
 + user-manual.txt: render ASCII art correctly under Asciidoctor
 + asciidoctor-extensions.rb: handle "book" doctype in linkgit
 + user-manual.txt: change header notation
 + user-manual.txt: add missing section label

 The markup used in user-manual has been updated to work better with
 asciidoctor.


* mr/complete-more-for-log-etc (2019-09-12) 1 commit
  (merged to 'next' on 2019-09-30 at b2507b21cb)
 + completion: add missing completions for log, diff, show

 Completion updates.


* ms/fetch-follow-tag-optim (2019-09-16) 1 commit
  (merged to 'next' on 2019-09-30 at 97ec83d2a2)
 + fetch: use oidset to keep the want OIDs for faster lookup

 The code used in following tags in "git fetch" has been optimized.


* ps/my-first-contribution-alphasort (2019-09-28) 1 commit
  (merged to 'next' on 2019-09-30 at 729e6dc708)
 + doc: MyFirstContribution: fix cmd placement instructions

 Docfix.


* rs/alias-use-copy-array (2019-09-20) 1 commit
  (merged to 'next' on 2019-09-30 at 4d90f4ba93)
 + git: use COPY_ARRAY and MOVE_ARRAY in handle_alias()

 Code cleanup.


* rs/commit-graph-use-list-count (2019-09-16) 1 commit
  (merged to 'next' on 2019-09-30 at 8986e5537f)
 + commit-graph: use commit_list_count()

 Code cleanup.


* rs/nth-parent-parse (2019-09-16) 2 commits
  (merged to 'next' on 2019-09-30 at 5bdfeacdff)
 + sha1-name: check for overflow of N in "foo^N" and "foo~N"
 + rev-parse: demonstrate overflow of N for "foo^N" and "foo~N"

 The object name parser for "Nth parent" syntax has been made more
 robust against integer overflows.


* rs/nth-switch-code-simplification (2019-09-18) 1 commit
  (merged to 'next' on 2019-09-30 at 4233f54a72)
 + sha1_name: simplify strbuf handling in interpret_nth_prior_checkout()

 Code simplification.


* rs/simplify-by-deco-with-deco-refs-exclude (2019-09-09) 2 commits
  (merged to 'next' on 2019-09-30 at 3c155bbd24)
 + log-tree: call load_ref_decorations() in get_name_decoration()
 + log: test --decorate-refs-exclude with --simplify-by-decoration

 "git log --decorate-refs-exclude=<pattern>" was incorrectly
 overruled when the "--simplify-by-decoration" option is used, which
 has been corrected.


* sg/progress-fix (2019-09-17) 2 commits
  (merged to 'next' on 2019-09-30 at d352332810)
 + Test the progress display
 + Revert "progress: use term_clear_line()"

 Regression fix for progress output.


* sg/t-helper-gitignore (2019-09-20) 1 commit
  (merged to 'next' on 2019-09-30 at 8e319a2eae)
 + t/helper: ignore only executable files

 Update the way build artifacts in t/helper/ directory are ignored.


* sg/travis-help-debug (2019-09-28) 1 commit
  (merged to 'next' on 2019-09-30 at 054a66bb75)
 + travis-ci: do not skip successfully tested trees in debug mode

 Dev support update.


* ss/get-time-cleanup (2019-09-18) 2 commits
  (merged to 'next' on 2019-09-30 at 21a0dced8f)
 + test_date.c: remove reference to GIT_TEST_DATE_NOW
 + Quit passing 'now' to date code

 Code simplification.


* tb/commit-graph-harden (2019-09-09) 3 commits
  (merged to 'next' on 2019-09-30 at b9350a562d)
 + commit-graph.c: handle corrupt/missing trees
 + commit-graph.c: handle commit parsing errors
 + t/t5318: introduce failing 'git commit-graph write' tests

 The code to parse and use the commit-graph file has been made more
 robust against corrupted input.


* tg/stash-refresh-index (2019-09-20) 3 commits
  (merged to 'next' on 2019-09-30 at de7759ad1d)
 + stash: make sure to write refreshed cache
 + merge: use refresh_and_write_cache
 + factor out refresh_and_write_cache function

 "git stash" learned to write refreshed index back to disk.

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

* dl/octopus-graph-bug (2019-10-04) 5 commits
  (merged to 'next' on 2019-10-07 at c6bc2fe4a0)
 + t4214: demonstrate octopus graph coloring failure
 + t4214: explicitly list tags in log
 + t4214: generate expect in their own test cases
 + t4214: use test_merge
 + test-lib: let test_merge() perform octopus merges

 "git log --graph" for an octopus merge is sometimes colored
 incorrectly, which is demonstrated and documented but not yet
 fixed.

 Will merge to 'master'.


* js/azure-pipelines-msvc (2019-10-06) 13 commits
  (merged to 'next' on 2019-10-07 at d5a3604dc6)
 + ci: also build and test with MS Visual Studio on Azure Pipelines
 + ci: really use shallow clones on Azure Pipelines
 + tests: let --immediate and --write-junit-xml play well together
 + test-tool run-command: learn to run (parts of) the testsuite
 + vcxproj: include more generated files
 + vcxproj: only copy `git-remote-http.exe` once it was built
 + msvc: work around a bug in GetEnvironmentVariable()
 + msvc: handle DEVELOPER=1
 + msvc: ignore some libraries when linking
 + compat/win32/path-utils.h: add #include guards
 + winansi: use FLEX_ARRAY to avoid compiler warning
 + msvc: avoid using minus operator on unsigned types
 + push: do not pretend to return `int` from `die_push_simple()`

 CI updates.

 Will merge to 'master'.


* js/stash-apply-in-secondary-worktree (2019-10-06) 1 commit
  (merged to 'next' on 2019-10-07 at b3474c9c3d)
 + stash apply: report status correctly even in a worktree's subdirectory

 "git stash apply" in a subdirectory of a secondary worktree failed
 to access the worktree correctly, which has been corrected.

 Will merge to 'master'.


* js/trace2-cap-max-output-files (2019-10-05) 4 commits
 - trace2: write discard message to sentinel files
 - trace2: discard new traces if target directory has too many files
 - docs: clarify trace2 version invariants
 - docs: mention trace2 target-dir mode in git-config

 The trace2 output, when sending them to files in a designated
 directory, can populate the directory with too many files; a
 mechanism is introduced to set the maximum number of files and
 discard further logs when the maximum is reached.

 Will merge to 'next'.


* kt/add-i-progress (2019-10-04) 1 commit
  (merged to 'next' on 2019-10-07 at 00cf8fe076)
 + add -i: show progress counter in the prompt

 "git add -i" has been taught to show the total number of hunks and
 the hunks that has been processed so far when showing prompts.

 Will merge to 'master'.


* rs/dedup-includes (2019-10-04) 1 commit
  (merged to 'next' on 2019-10-07 at 5a4fc44657)
 + treewide: remove duplicate #include directives

 Code cleanup.

 Will merge to 'master'.


* bc/hash-independent-tests-part-6 (2019-10-06) 15 commits
 - t4048: abstract away SHA-1-specific constants
 - t4045: make hash-size independent
 - t4044: update test to work with SHA-256
 - t4039: abstract away SHA-1-specific constants
 - t4038: abstract away SHA-1 specific constants
 - t4034: abstract away SHA-1-specific constants
 - t4027: make hash-size independent
 - t4015: abstract away SHA-1-specific constants
 - t4011: abstract away SHA-1-specific constants
 - t4010: abstract away SHA-1-specific constants
 - t3429: remove SHA1 annotation
 - t1305: avoid comparing extensions
 - rev-parse: add an --object-format option
 - t/oid-info: add empty tree and empty blob values
 - t/oid-info: allow looking up hash algorithm name

 Test updates to prepare for SHA-2 transition continues.

 Will merge to 'next'.


* bw/format-patch-o-create-leading-dirs (2019-10-06) 1 commit
 - format-patch: create leading components of output directory

 "git format-patch -o <outdir>" did an equivalent of "mkdir <outdir>"
 not "mkdir -p <outdir>", which is being corrected.

 Use of adjust shared perm on the leading directory may have
 security implictions.


* dl/rev-list-doc-cleanup (2019-10-06) 1 commit
  (merged to 'next' on 2019-10-07 at 712594feb1)
 + git-rev-list.txt: prune options in synopsis

 Doc update.

 Will merge to 'master'.


* py/git-gui-has-maintainer (2019-10-06) 1 commit
  (merged to 'next' on 2019-10-07 at 0945190c4c)
 + Documentation: update the location of the git-gui repo

 Doc update.

 Will merge to 'master'.


* rs/convert-fix-utf-without-dash (2019-10-06) 1 commit
  (merged to 'next' on 2019-10-07 at 9d0e27b5c3)
 + convert: fix handling of dashless UTF prefix in validate_encoding()

 The code to skip "UTF" and "UTF-" prefix, when computing an advice
 message, did not work correctly when the prefix was "UTF", which
 has been fixed.

 Will merge to 'master'.


* pm/p4-auto-delete-named-temporary (2019-10-06) 1 commit
  (merged to 'next' on 2019-10-07 at 4f45be70f5)
 + git-p4: auto-delete named temporary file

 Will merge to 'master'.


* rs/test-remove-useless-debugging-cat (2019-10-07) 1 commit
  (merged to 'next' on 2019-10-07 at 6d8cb22a4f)
 + tests: remove "cat foo" before "test_i18ngrep bar foo"

 Code cleanup.

 Will merge to 'master'.

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

* cb/pcre2-chartables-leakfix (2019-08-06) 3 commits
 - grep: avoid leak of chartables in PCRE2
 - grep: make PCRE2 aware of custom allocator
 - grep: make PCRE1 aware of custom allocator

 WIP (this is v3 which is rather old, where the last message in the
 discussion talks about v6 that has never been sent to the list).
 cf. <CAPUEspjJNSrJQT7xV2fsdp2t5odW5fzzPdDxuar_5x_JPUtf6Q@mail.gmail.com>


* es/walken-tutorial (2019-08-07) 1 commit
 - documentation: add tutorial for revision walking

 A tutorial on object enumeration.

 Perhaps take the thing with as little tweaks as possible, retitling
 it to "my first object enumeration" or something?
 cf. <20190814183328.GA40797@google.com>


* dl/format-patch-cover-letter-subject (2019-09-05) 1 commit
 - format-patch: learn --infer-cover-subject option

 "git format-patch --cover-letter" learned to optionally use the
 first paragraph (typically a single-liner) of branch.*.description
 as the subject of the cover letter.

 Reroll with a redesign with less emphasis on "subject" coming?


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


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

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

* ag/sequencer-todo-updates (2019-10-02) 5 commits
 - sequencer: directly call pick_commits() from complete_action()
 - rebase: fill `squash_onto' in get_replay_opts()
 - sequencer: move the code writing total_nr on the disk to a new function
 - sequencer: update `done_nr' when skipping commands in a todo list
 - sequencer: update `total_nr' when adding an item to a todo list

 Expecting a reroll.
 cf. <nycvar.QRO.7.76.6.1910021018360.46@tvgsbejvaqbjf.bet> to clarify log messages.
 there may be others.


* ah/cleanups (2019-10-03) 4 commits
  (merged to 'next' on 2019-10-04 at 1345f09afb)
 + git_mkstemps_mode(): replace magic numbers with computed value
 + wrapper: use a loop instead of repetitive statements
 + diffcore-break: use a goto instead of a redundant if statement
 + commit-graph: remove a duplicate assignment

 Miscellaneous code clean-ups.

 Will merge to 'master'.


* as/shallow-slab-use-fix (2019-10-02) 1 commit
  (merged to 'next' on 2019-10-04 at f3a22d2b18)
 + shallow.c: don't free unallocated slabs

 Correct code that tried to reference all entries in a sparse array
 of pointers by mistake.

 Will merge to 'master'.


* js/fetch-jobs (2019-10-06) 1 commit
  (merged to 'next' on 2019-10-07 at e798bac35d)
 + fetch: let --jobs=<n> parallelize --multiple, too

 "git fetch --jobs=<n>" allowed <n> parallel jobs when fetching
 submodules, but this did not apply to "git fetch --multiple" that
 fetches from multiple remote repositories.  It now does.

 Will merge to 'master'.


* js/mingw-spawn-with-spaces-in-path (2019-10-02) 1 commit
  (merged to 'next' on 2019-10-04 at 0fdb87dd53)
 + t0061: fix test for argv[0] with spaces (MINGW only)

 Test fix.

 Will merge to 'master'.


* gs/commit-graph-trace-with-cmd (2019-10-02) 1 commit
  (merged to 'next' on 2019-10-07 at 369df0e5cd)
 + commit-graph: emit trace2 cmd_mode for each sub-command

 Dev support.

 Will merge to 'master'.


* js/trace2-fetch-push (2019-10-03) 2 commits
  (merged to 'next' on 2019-10-04 at 1d63701064)
 + push: add trace2 instrumentation
 + fetch: add trace2 instrumentation

 Dev support.

 Will merge to 'master'.


* js/range-diff-noprefix (2019-10-03) 1 commit
  (merged to 'next' on 2019-10-04 at 56cf767bdb)
 + range-diff: internally force `diff.noprefix=true`

 "git range-diff" segfaulted when diff.noprefix configuration was
 used, as it blindly expected the patch it internally generates to
 have the standard a/ and b/ prefixes.  The command now forces the
 internal patch to be built without any prefix, not to be affected
 by any end-user configuration.

 Will merge to 'master'.


* mt/threaded-grep-in-object-store (2019-10-02) 11 commits
 - grep: move driver pre-load out of critical section
 - grep: re-enable threads in non-worktree case
 - grep: protect packed_git [re-]initialization
 - grep: allow submodule functions to run in parallel
 - submodule-config: add skip_if_read option to repo_read_gitmodules()
 - grep: replace grep_read_mutex by internal obj read lock
 - object-store: allow threaded access to object reading
 - replace-object: make replace operations thread-safe
 - grep: fix racy calls in grep_objects()
 - grep: fix race conditions at grep_submodule()
 - grep: fix race conditions on userdiff calls

 Traditionally, we avoided threaded grep while searching in objects
 (as opposed to files in the working tree) as accesses to the object
 layer is not thread-safe.  This limitation is getting lifted.


* am/t0028-utf16-tests (2019-09-28) 2 commits
 - t0028: add more tests
 - t0028: fix test for UTF-16-LE-BOM

 Test fixes.

 Will merge to 'next'.


* am/visual-studio-config-fix (2019-09-28) 1 commit
  (merged to 'next' on 2019-10-04 at 135d93143b)
 + contrib/buildsystems: fix Visual Studio Debug configuration

 Dev support.

 Will merge to 'master'.


* en/fast-imexport-nested-tags (2019-10-04) 8 commits
  (merged to 'next' on 2019-10-07 at 3e75779e10)
 + fast-export: handle nested tags
 + t9350: add tests for tags of things other than a commit
 + fast-export: allow user to request tags be marked with --mark-tags
 + fast-export: add support for --import-marks-if-exists
 + fast-import: add support for new 'alias' command
 + fast-import: allow tags to be identified by mark labels
 + fast-import: fix handling of deleted tags
 + fast-export: fix exporting a tag and nothing else

 Updates to fast-import/export.

 Will merge to 'master'.


* js/diff-rename-force-stable-sort (2019-10-02) 2 commits
  (merged to 'next' on 2019-10-04 at e02d882510)
 + diffcore_rename(): use a stable sort
 + Move git_sort(), a stable sort, into into libgit.a

 The rename detection logic sorts a list of rename source candidates
 by similarity to pick the best candidate, which means that a tie
 between sources with the same similarity is broken by the original
 location in the original canidate list (which is sorted by path).
 Force the sorting by similarity done with a stable sort, which is
 not promised by system supplied qsort(3), to ensure consistent
 results across platforms.

 Will merge to 'master'.


* sg/name-rev-cutoff-underflow-fix (2019-09-28) 1 commit
  (merged to 'next' on 2019-10-04 at 25e4436b3d)
 + name-rev: avoid cutoff timestamp underflow

 Integer arith fix.

 Will merge to 'master'.


* tk/git-svn-trim-author-name (2019-09-28) 1 commit
  (merged to 'next' on 2019-10-04 at c1c619f7c4)
 + git-svn: trim leading and trailing whitespaces in author name

 The author names taken from SVN repositories may have extra leading
 or trailing whitespaces, which are now munged away.

 Will merge to 'master'.


* bc/object-id-part17 (2019-08-19) 26 commits
  (merged to 'next' on 2019-10-04 at b0460b0db2)
 + midx: switch to using the_hash_algo
 + builtin/show-index: replace sha1_to_hex
 + rerere: replace sha1_to_hex
 + builtin/receive-pack: replace sha1_to_hex
 + builtin/index-pack: replace sha1_to_hex
 + packfile: replace sha1_to_hex
 + wt-status: convert struct wt_status to object_id
 + cache: remove null_sha1
 + builtin/worktree: switch null_sha1 to null_oid
 + builtin/repack: write object IDs of the proper length
 + pack-write: use hash_to_hex when writing checksums
 + sequencer: convert to use the_hash_algo
 + bisect: switch to using the_hash_algo
 + sha1-lookup: switch hard-coded constants to the_hash_algo
 + config: use the_hash_algo in abbrev comparison
 + combine-diff: replace GIT_SHA1_HEXSZ with the_hash_algo
 + bundle: switch to use the_hash_algo
 + connected: switch GIT_SHA1_HEXSZ to the_hash_algo
 + show-index: switch hard-coded constants to the_hash_algo
 + blame: remove needless comparison with GIT_SHA1_HEXSZ
 + builtin/rev-parse: switch to use the_hash_algo
 + builtin/blame: switch uses of GIT_SHA1_HEXSZ to the_hash_algo
 + builtin/receive-pack: switch to use the_hash_algo
 + fetch-pack: use parse_oid_hex
 + patch-id: convert to use the_hash_algo
 + builtin/replace: make hash size independent

 Preparation for SHA-256 upgrade continues.

 Will merge to 'master'.


* en/clean-nested-with-ignored (2019-10-02) 13 commits
  (merged to 'next' on 2019-10-03 at 969ec06cc7)
 + dir: special case check for the possibility that pathspec is NULL
  (merged to 'next' on 2019-09-30 at 778cc31eac)
 + clean: fix theoretical path corruption
 + clean: rewrap overly long line
 + clean: avoid removing untracked files in a nested git repository
 + clean: disambiguate the definition of -d
 + git-clean.txt: do not claim we will delete files with -n/--dry-run
 + dir: add commentary explaining match_pathspec_item's return value
 + dir: if our pathspec might match files under a dir, recurse into it
 + dir: make the DO_MATCH_SUBMODULE code reusable for a non-submodule case
 + dir: also check directories for matching pathspecs
 + dir: fix off-by-one error in match_pathspec_item
 + dir: fix typo in comment
 + t7300: add testcases showing failure to clean specified pathspecs

 "git clean" fixes.

 Will merge to 'master'.


* jk/packfile-reuse-cleanup (2019-09-13) 10 commits
  (merged to 'next' on 2019-09-30 at dc60b31833)
 + pack-objects: improve partial packfile reuse
 + builtin/pack-objects: introduce obj_is_packed()
 + pack-objects: introduce pack.allowPackReuse
 + csum-file: introduce hashfile_total()
 + pack-bitmap: introduce bitmap_walk_contains()
 + pack-bitmap: don't rely on bitmap_git->reuse_objects
 + ewah/bitmap: always allocate 2 more words
 + ewah/bitmap: introduce bitmap_word_alloc()
 + packfile: expose get_delta_base()
 + builtin/pack-objects: report reused packfile objects

 The way "git pack-objects" reuses objects stored in existing pack
 to generate its result has been improved.

 On hold until we give it a more thorough review.
 cf. <20191002155721.GD6116@sigill.intra.peff.net>


* cb/pcre1-cleanup (2019-08-26) 2 commits
  (merged to 'next' on 2019-10-04 at a2dd896ee8)
 + grep: refactor and simplify PCRE1 support
 + grep: make sure NO_LIBPCRE1_JIT disable JIT in PCRE1
 (this branch uses ab/pcre-jit-fixes.)

 PCRE fixes.

 Will merge to 'master'.


* ew/hashmap (2019-10-07) 20 commits
 - hashmap_entry: remove first member requirement from docs
 - hashmap: remove type arg from hashmap_{get,put,remove}_entry
 - OFFSETOF_VAR macro to simplify hashmap iterators
 - hashmap: introduce hashmap_free_entries
 - hashmap: hashmap_{put,remove} return hashmap_entry *
 - hashmap: use *_entry APIs for iteration
 - hashmap_cmp_fn takes hashmap_entry params
 - hashmap_get{,_from_hash} return "struct hashmap_entry *"
 - hashmap: use *_entry APIs to wrap container_of
 - hashmap_get_next returns "struct hashmap_entry *"
 - introduce container_of macro
 - hashmap_put takes "struct hashmap_entry *"
 - hashmap_remove takes "const struct hashmap_entry *"
 - hashmap_get takes "const struct hashmap_entry *"
 - hashmap_add takes "struct hashmap_entry *"
 - hashmap_get_next takes "const struct hashmap_entry *"
 - hashmap_entry_init takes "struct hashmap_entry *"
 - packfile: use hashmap_entry in delta_base_cache_entry
 - coccicheck: detect hashmap_entry.hash assignment
 - diff: use hashmap_entry_init on moved_entry.ent

 Code clean-up of the hashmap API, both users and implementation.

 Will merge to 'next'.


* js/builtin-add-i (2019-08-30) 11 commits
 . built-in add -i: implement the `help` command
 . built-in add -i: use color in the main loop
 . built-in add -i: support `?` (prompt help)
 . built-in add -i: show unique prefixes of the commands
 . Add a function to determine unique prefixes for a list of strings
 . built-in add -i: implement the main loop
 . built-in add -i: color the header in the `status` command
 . built-in add -i: refresh the index before running `status`
 . built-in add -i: implement the `status` command
 . diff: export diffstat interface
 . Start to implement a built-in version of `git add --interactive`

 The beginning of rewriting "git add -i" in C.

 On hold, waiting for tg/stash-refresh-index to work well with this.


* en/merge-recursive-cleanup (2019-10-02) 25 commits
  (merged to 'next' on 2019-10-03 at 7b5a32726b)
 + merge-recursive: fix the diff3 common ancestor label for virtual commits
  (merged to 'next' on 2019-09-18 at f52cb08a14)
 + merge-recursive: alphabetize include list
 + merge-recursive: add sanity checks for relevant merge_options
 + merge-recursive: rename MERGE_RECURSIVE_* to MERGE_VARIANT_*
 + merge-recursive: split internal fields into a separate struct
 + merge-recursive: avoid losing output and leaking memory holding that output
 + merge-recursive: comment and reorder the merge_options fields
 + merge-recursive: consolidate unnecessary fields in merge_options
 + merge-recursive: move some definitions around to clean up the header
 + merge-recursive: rename merge_options argument to opt in header
 + merge-recursive: rename 'mrtree' to 'result_tree', for clarity
 + merge-recursive: use common name for ancestors/common/base_list
 + merge-recursive: fix some overly long lines
 + cache-tree: share code between functions writing an index as a tree
 + merge-recursive: don't force external callers to do our logging
 + merge-recursive: remove useless parameter in merge_trees()
 + merge-recursive: exit early if index != head
 + Ensure index matches head before invoking merge machinery, round N
 + merge-recursive: remove another implicit dependency on the_repository
 + merge-recursive: future-proof update_file_flags() against memory leaks
 + merge-recursive: introduce an enum for detect_directory_renames values
 + merge-recursive: provide a better label for diff3 common ancestor
 + merge-recursive: enforce opt->ancestor != NULL when calling merge_trees()
 + checkout: provide better conflict hunk description with detached HEAD
 + merge-recursive: be consistent with assert

 The merge-recursive machiery is one of the most complex parts of
 the system that accumulated cruft over time.  This large series
 cleans up the implementation quite a bit.

 Will merge to 'master'.


* pw/rebase-i-show-HEAD-to-reword (2019-08-19) 3 commits
  (merged to 'next' on 2019-10-04 at ab3d7eeb72)
 + sequencer: simplify root commit creation
 + rebase -i: check for updated todo after squash and reword
 + rebase -i: always update HEAD before rewording
 (this branch is used by ra/rebase-i-more-options.)

 "git rebase -i" showed a wrong HEAD while "reword" open the editor.

 Will merge to 'master'.


* vn/reset-deleted-ita (2019-07-26) 1 commit
 - reset: unstage empty deleted ita files

 "git reset HEAD [<pathspec>]" did not reset an empty file that was
 added with the intent-to-add bit.

 Expecting a reroll.


* ra/rebase-i-more-options (2019-09-09) 6 commits
 - rebase: add --reset-author-date
 - rebase -i: support --ignore-date
 - sequencer: rename amend_author to author_to_rename
 - rebase -i: support --committer-date-is-author-date
 - sequencer: allow callers of read_author_script() to ignore fields
 - rebase -i: add --ignore-whitespace flag
 (this branch uses pw/rebase-i-show-HEAD-to-reword.)

 "git rebase -i" learned a few options that are known by "git
 rebase" proper.

 Needs to consider existing GIT_COMMITTER_DATE environment, etc.
 cf. <5adde732-173b-d24d-d23f-bb4d043076d7@gmail.com>


* ab/pcre-jit-fixes (2019-08-19) 18 commits
  (merged to 'next' on 2019-10-04 at 2d55f2b470)
 + grep: under --debug, show whether PCRE JIT is enabled
 + grep: do not enter PCRE2_UTF mode on fixed matching
 + grep: stess test PCRE v2 on invalid UTF-8 data
 + grep: create a "is_fixed" member in "grep_pat"
 + grep: consistently use "p->fixed" in compile_regexp()
 + grep: stop using a custom JIT stack with PCRE v1
 + grep: stop "using" a custom JIT stack with PCRE v2
 + grep: remove overly paranoid BUG(...) code
 + grep: use PCRE v2 for optimized fixed-string search
 + grep: remove the kwset optimization
 + grep: drop support for \0 in --fixed-strings <pattern>
 + grep: make the behavior for NUL-byte in patterns sane
 + grep tests: move binary pattern tests into their own file
 + grep tests: move "grep binary" alongside the rest
 + grep: inline the return value of a function call used only once
 + t4210: skip more command-line encoding tests on MinGW
 + grep: don't use PCRE2?_UTF8 with "log --encoding=<non-utf8>"
 + log tests: test regex backends in "--encode=<enc>" tests
 (this branch is used by cb/pcre1-cleanup.)

 A few simplification and bugfixes to PCRE interface.

 Will merge to 'master'.


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

 Will discard.

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

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


* js/trace2-json-schema (2019-07-25) 3 commits
 . ci: run trace2 schema validation in the CI suite
 . trace2: add a schema validator for trace2 events
 . trace2: add a JSON schema for trace2 events

 The JSON output produced by "trace2" subsystem now has JSON schema
 defined on it, to allow us validate the output and catch deviation.

 Abandoned, at least for now.
 cf. <20190910182305.GA11186@google.com>


* pd/fetch-jobs (2019-08-13) 5 commits
 . fetch: make --jobs control submodules and remotes
 . fetch: add the --submodule-fetch-jobs option
 . fetch: add the fetch.jobs config key
 . fetch: add the "--fetch-jobs" option
 . fetch: rename max_children to max_children_for_submodules

 "git fetch --jobs" is getting taught to also run fetch jobs in
 parallel when fetching from multiple remote repositories.

 cf. <nycvar.QRO.7.76.6.1909111359150.5377@tvgsbejvaqbjf.bet>


* js/honor-cflags-in-hdr-check (2019-08-26) 1 commit
  (merged to 'next' on 2019-09-09 at fcd9ee9f1b)
 + hdr-check: make it work on Windows

 Build fix to make sure hdr-check is run with the same preprocessor
 macros predefined by the $(MAKE) procedure.

 Superseded by dl/honor-cflags-in-hdr-check series.

jk/code-of-conduct, was Re: What's cooking in git.git (Oct 2019, #02; Mon, 7)

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

Hi Junio,

On Mon, 7 Oct 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.
>
> 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
>
> --------------------------------------------------
> [...]
> [New Topics]
>
> [...]

I missed a well-ACKed contribution in here: the code of conduct Peff
kindly submitted, with the add-on that clarifies who is in that group of
potential mediators. See

https://public-inbox.org/git/20190924064454.GA30419@sigill.intra.peff.net/

and

https://public-inbox.org/git/20190926072046.GB20653@sigill.intra.peff.net/

As far as I can tell, there was only one critical voice, Gábor, and when
I responded asking for clarifications which part of the code of conduct
exactly would require any change of behavior, there was no response,
which I took as a silent sign of acquiescence.

René also offered concerns about a part of the code of conduct that they
considered to be too vague, but I think both Peff and I explained why it
should remain as-is (again, there was no response, which I, again, am
forced to interpret, and I interpret it as agreeing to the points made
in particular by Peff).

In contrast, the patch won support from the cURL maintainer
(https://public-inbox.org/git/alpine.DEB.2.20.1909250834220.4757@tvnag.unkk.fr/),
and endorsements (also known as ACKs) from myself
(https://public-inbox.org/git/nycvar.QRO.7.76.6.1909241426580.15067@tvgsbejvaqbjf.bet/),
from Stolee
(https://public-inbox.org/git/6a9fb4c2-6c80-4475-03d3-89bdba73095b@gmail.com/),
from Phillip Wood (although I don't dare to interpet this as a full ACK)
(https://public-inbox.org/git/cc8cc0b3-777c-6ef8-202f-ea1d0518bbd3@gmail.com/),
from Garima
(https://public-inbox.org/git/133b46b2-b2e1-4673-820b-5a5ca6ec0269@gmail.com/),
from Jonathan Tan
(https://public-inbox.org/git/20190924172324.104795-1-jonathantanmy@google.com/),
from Thomas Gummerer
(https://public-inbox.org/git/20190924174056.GA55104@cat/), from
brian
(https://public-inbox.org/git/20190924233728.6iueqaktlhhfwn7k@camp.crustytoothpaste.net/),
and from Elijah
(https://public-inbox.org/git/CABPp-BERhEp2At-ABPrkCHcqLfb32t+S0hPHs=d17QjcZR1wPA@mail.gmail.com/).

In other words, the commit message can be augmented by this:

Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Derrick Stolee <stolee@gmail.com>
Acked-by: Garima Singh <garimasigit@gmail.com>
Acked-by: Jonathan Tan <jonathantanmy@google.com>
Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
Acked-by: Elijah Newren <newren@gmail.com>

Junio, would you mind picking it up, please?

Ciao,
Dscho

Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Junio C Hamano]

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

> In other words, the commit message can be augmented by this:
>
> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Acked-by: Derrick Stolee <stolee@gmail.com>
> Acked-by: Garima Singh <garimasigit@gmail.com>
> Acked-by: Jonathan Tan <jonathantanmy@google.com>
> Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
> Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
> Acked-by: Elijah Newren <newren@gmail.com>
>
> Junio, would you mind picking it up, please?

I trust you enough that I won't go back to the cited messages to
double check that these acks are real, but I'd still wait for a few
days for people who expressed their Acks but your scan missed, or
those who wanted to give their Acks but forgot to do so, to raise
their hands on this thread.

Thanks for starting the concluding move on this topic.

For reference, here is the CoC the patch wants to add (there is no
such topic yet locally, nor a single patch that can be made into
such a topic, so there isn't exactly something people can Ack on
yet. So here is a "preview" of what we would see once such a series
lands).

 CODE_OF_CONDUCT.md | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++++

# Git Code of Conduct

This code of conduct outlines our expectations for participants within
the Git community, as well as steps for reporting unacceptable behavior.
We are committed to providing a welcoming and inspiring community for
all and expect our code of conduct to be honored. Anyone who violates
this code of conduct may be banned from the community.

## Our Pledge

In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to make participation in our project and
our community a harassment-free experience for everyone, regardless of age,
body size, disability, ethnicity, sex characteristics, gender identity and
expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, religion, or sexual identity and
orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment
include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
  advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
  address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
  professional setting

## Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.

## Scope

This Code of Conduct applies within all project spaces, and it also applies
when an individual is representing the project or its community in public
spaces. Examples of representing a project or community include using an
official project e-mail address, posting via an official social media account,
or acting as an appointed representative at an online or offline event.
Representation of a project may be further defined and clarified by project
maintainers.

## Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at git@sfconservancy.org. All
complaints will be reviewed and investigated and will result in a response
that is deemed necessary and appropriate to the circumstances. The project
team is obligated to maintain confidentiality with regard to the reporter of
an incident. Further details of specific enforcement policies may be posted
separately.

Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.

The project leadership team can be contacted by email as a whole at
git@sfconservancy.org, or individually:

  - Ævar Arnfjörð Bjarmason <avarab@gmail.com>
  - Christian Couder <christian.couder@gmail.com>
  - Jeff King <peff@peff.net>
  - Junio C Hamano <gitster@pobox.com>

## Attribution

This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

[homepage]: https://www.contributor-covenant.org

For answers to common questions about this code of conduct, see
https://www.contributor-covenant.org/faq

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Taylor Blau]

On Wed, Oct 09, 2019 at 09:14:59AM +0900, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > In other words, the commit message can be augmented by this:
> >
> > Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Acked-by: Derrick Stolee <stolee@gmail.com>
> > Acked-by: Garima Singh <garimasigit@gmail.com>
> > Acked-by: Jonathan Tan <jonathantanmy@google.com>
> > Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
> > Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
> > Acked-by: Elijah Newren <newren@gmail.com>
> >
> > Junio, would you mind picking it up, please?
>
> I trust you enough that I won't go back to the cited messages to
> double check that these acks are real, but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.

I'd be quite pleased to join those above with my strongest:

  Acked-by: Taylor Blau <me@ttaylorr.com>

I admit to waiting a couple of days before responding to that originally
linked thread, and that by the time I got around to readying a reply,
everything that I wanted to say in favor of a CoC was already well put
by others.

So, I don't think that I have anything more to add than to say that I
think it's great, that we should have it, and that I most certainly
approve of the direction of that patch.

Thanks,
Taylor

Re: jk/code-of-conduct, was Re: What's cooking in git.git (Oct 2019, #02; Mon, 7)

[SZEDER Gábor]

On Tue, Oct 08, 2019 at 09:36:26PM +0200, Johannes Schindelin wrote:
> I missed a well-ACKed contribution in here: the code of conduct Peff
> kindly submitted, with the add-on that clarifies who is in that group of
> potential mediators. See
> 
> https://public-inbox.org/git/20190924064454.GA30419@sigill.intra.peff.net/
> 
> and
> 
> https://public-inbox.org/git/20190926072046.GB20653@sigill.intra.peff.net/
> 
> As far as I can tell, there was only one critical voice, Gábor, and when
> I responded asking for clarifications which part of the code of conduct
> exactly would require any change of behavior, there was no response,
> which I took as a silent sign of acquiescence.

It's merely a sign that I had other things to do, nothing more.

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Emily Shaffer]

On Wed, Oct 09, 2019 at 09:14:59AM +0900, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > In other words, the commit message can be augmented by this:
> >
> > Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Acked-by: Derrick Stolee <stolee@gmail.com>
> > Acked-by: Garima Singh <garimasigit@gmail.com>
> > Acked-by: Jonathan Tan <jonathantanmy@google.com>
> > Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
> > Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
> > Acked-by: Elijah Newren <newren@gmail.com>
> >
> > Junio, would you mind picking it up, please?

Yes, I'd like to join too - I was missed by the scan.

Acked-by: Emily Shaffer <emilyshaffer@google.com>

I'm very excited for us to adopt this document.

 - Emily

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Jonathan Nieder]

Junio C Hamano wrote:

> For reference, here is the CoC the patch wants to add (there is no
> such topic yet locally, nor a single patch that can be made into
> such a topic, so there isn't exactly something people can Ack on
> yet. So here is a "preview" of what we would see once such a series
> lands).

Acked-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks for your thoughtful work.

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Johannes Schindelin]

Hi Emily,

On Tue, 8 Oct 2019, Emily Shaffer wrote:

> On Wed, Oct 09, 2019 at 09:14:59AM +0900, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> > > In other words, the commit message can be augmented by this:
> > >
> > > Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > Acked-by: Derrick Stolee <stolee@gmail.com>
> > > Acked-by: Garima Singh <garimasigit@gmail.com>
> > > Acked-by: Jonathan Tan <jonathantanmy@google.com>
> > > Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
> > > Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
> > > Acked-by: Elijah Newren <newren@gmail.com>
> > >
> > > Junio, would you mind picking it up, please?
>
> Yes, I'd like to join too - I was missed by the scan.

Sorry about that. I only looked through immediate responses to the
original patch, my bad.

Ciao,
Dscho

>
> Acked-by: Emily Shaffer <emilyshaffer@google.com>
>
> I'm very excited for us to adopt this document.
>
>  - Emily
>

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Christian Couder]

On Wed, Oct 9, 2019 at 2:20 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> For reference, here is the CoC the patch wants to add (there is no
> such topic yet locally, nor a single patch that can be made into
> such a topic, so there isn't exactly something people can Ack on
> yet. So here is a "preview" of what we would see once such a series
> lands).

Acked-by: Christian Couder <chriscool@tuxfamily.org>

Thanks to everyone involved,
Christian.

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Phillip Wood]

Hi Junio

On 09/10/2019 01:14, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> In other words, the commit message can be augmented by this:
>>
>> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> Acked-by: Derrick Stolee <stolee@gmail.com>
>> Acked-by: Garima Singh <garimasigit@gmail.com>
>> Acked-by: Jonathan Tan <jonathantanmy@google.com>
>> Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
>> Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
>> Acked-by: Elijah Newren <newren@gmail.com>
>>
>> Junio, would you mind picking it up, please?
> 
> I trust you enough that I won't go back to the cited messages to
> double check that these acks are real, but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.

I forgot to add

Acked-by: Phillip Wood <phillip.wood@dunelm.org.uk>

to my original reply in this thread, could you add it please

Thanks

Phillip
> Thanks for starting the concluding move on this topic.
> 
> For reference, here is the CoC the patch wants to add (there is no
> such topic yet locally, nor a single patch that can be made into
> such a topic, so there isn't exactly something people can Ack on
> yet. So here is a "preview" of what we would see once such a series
> lands).
> 
>   CODE_OF_CONDUCT.md | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> # Git Code of Conduct
> 
> This code of conduct outlines our expectations for participants within
> the Git community, as well as steps for reporting unacceptable behavior.
> We are committed to providing a welcoming and inspiring community for
> all and expect our code of conduct to be honored. Anyone who violates
> this code of conduct may be banned from the community.
> 
> ## Our Pledge
> 
> In the interest of fostering an open and welcoming environment, we as
> contributors and maintainers pledge to make participation in our project and
> our community a harassment-free experience for everyone, regardless of age,
> body size, disability, ethnicity, sex characteristics, gender identity and
> expression, level of experience, education, socio-economic status,
> nationality, personal appearance, race, religion, or sexual identity and
> orientation.
> 
> ## Our Standards
> 
> Examples of behavior that contributes to creating a positive environment
> include:
> 
> * Using welcoming and inclusive language
> * Being respectful of differing viewpoints and experiences
> * Gracefully accepting constructive criticism
> * Focusing on what is best for the community
> * Showing empathy towards other community members
> 
> Examples of unacceptable behavior by participants include:
> 
> * The use of sexualized language or imagery and unwelcome sexual attention or
>    advances
> * Trolling, insulting/derogatory comments, and personal or political attacks
> * Public or private harassment
> * Publishing others' private information, such as a physical or electronic
>    address, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
>    professional setting
> 
> ## Our Responsibilities
> 
> Project maintainers are responsible for clarifying the standards of acceptable
> behavior and are expected to take appropriate and fair corrective action in
> response to any instances of unacceptable behavior.
> 
> Project maintainers have the right and responsibility to remove, edit, or
> reject comments, commits, code, wiki edits, issues, and other contributions
> that are not aligned to this Code of Conduct, or to ban temporarily or
> permanently any contributor for other behaviors that they deem inappropriate,
> threatening, offensive, or harmful.
> 
> ## Scope
> 
> This Code of Conduct applies within all project spaces, and it also applies
> when an individual is representing the project or its community in public
> spaces. Examples of representing a project or community include using an
> official project e-mail address, posting via an official social media account,
> or acting as an appointed representative at an online or offline event.
> Representation of a project may be further defined and clarified by project
> maintainers.
> 
> ## Enforcement
> 
> Instances of abusive, harassing, or otherwise unacceptable behavior may be
> reported by contacting the project team at git@sfconservancy.org. All
> complaints will be reviewed and investigated and will result in a response
> that is deemed necessary and appropriate to the circumstances. The project
> team is obligated to maintain confidentiality with regard to the reporter of
> an incident. Further details of specific enforcement policies may be posted
> separately.
> 
> Project maintainers who do not follow or enforce the Code of Conduct in good
> faith may face temporary or permanent repercussions as determined by other
> members of the project's leadership.
> 
> The project leadership team can be contacted by email as a whole at
> git@sfconservancy.org, or individually:
> 
>    - Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>    - Christian Couder <christian.couder@gmail.com>
>    - Jeff King <peff@peff.net>
>    - Junio C Hamano <gitster@pobox.com>
> 
> ## Attribution
> 
> This Code of Conduct is adapted from the [Contributor Covenant][homepage],
> version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
> 
> [homepage]: https://www.contributor-covenant.org
> 
> For answers to common questions about this code of conduct, see
> https://www.contributor-covenant.org/faq
> 

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Elijah Newren]

On Tue, Oct 8, 2019 at 5:20 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > In other words, the commit message can be augmented by this:
> >
> > Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > Acked-by: Derrick Stolee <stolee@gmail.com>
> > Acked-by: Garima Singh <garimasigit@gmail.com>
> > Acked-by: Jonathan Tan <jonathantanmy@google.com>
> > Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
> > Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
> > Acked-by: Elijah Newren <newren@gmail.com>
> >
> > Junio, would you mind picking it up, please?
>
> I trust you enough that I won't go back to the cited messages to
> double check that these acks are real, but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.
>
> Thanks for starting the concluding move on this topic.

Agreed, thanks.  There is one super minor issue, that I probably
shouldn't even bring up but... Looking at jk/coc, it ends with:

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Emily Shaffer <emilyshaffer@google.com>
Acked-by: Garima Singh <garimasigit@gmail.com>
Acked-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Jonathan Tan <jonathantanmy@google.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Taylor Blau <me@ttaylorr.com>
Acked-by: Elijah Newren <newren@gmail.com>
Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
Acked-by: Derrick Stolee <stolee@gmail.com>
Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Those Acked-by's are nearly in alphabetical order (at least at first
glance) until Brian, Derrick, and me.  I know it's a trivial thing,
but for the OCD among us, could it either be randomized, ordered by
when people acked, or alphabetized?  Sorry if this sounds really
trivial, but it's kind of like trying to hold a conversation with
someone at their office when the cord to their phone was all twisted
up; it's really difficult to pay attention to anything of substance
until that problem is fixed (though, thankfully, a job change in
combination with cell phone prevalence have almost completely
eradicated the phone cord problem years ago).

I'm kinda worried that sending this will result in someone
alphabetizing everyone in the list except me, but oh well...

Elijah

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

> Those Acked-by's are nearly in alphabetical order (at least at first
> glance) until Brian, Derrick, and me.

Sorted in ascii order after the first "<" on the line.

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[William Baker]

On 10/8/19 5:14 PM, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> In other words, the commit message can be augmented by this:
>>
>> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> Acked-by: Derrick Stolee <stolee@gmail.com>
>> Acked-by: Garima Singh <garimasigit@gmail.com>
>> Acked-by: Jonathan Tan <jonathantanmy@google.com>
>> Acked-by: Thomas Gummerer <t.gummerer@gmail.com>
>> Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
>> Acked-by: Elijah Newren <newren@gmail.com>
>>
>> Junio, would you mind picking it up, please?
> 
> I trust you enough that I won't go back to the cited messages to
> double check that these acks are real, but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.
> 

This looks good to me as well:

Acked-by: William Baker <williamtbakeremail@gmail.com>

Thanks,
William

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[CB Bailey]

On Wed, Oct 09, 2019 at 09:14:59AM +0900, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Junio, would you mind picking it up, please?
> 
> I trust you enough that I won't go back to the cited messages to
> double check that these acks are real, but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.

Acked-by: CB Bailey <cb@hashpling.org>

I raise my hand.

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Eric Wong]

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

<snip>

> For reference, here is the CoC the patch wants to add (there is no
> such topic yet locally, nor a single patch that can be made into
> such a topic, so there isn't exactly something people can Ack on
> yet. So here is a "preview" of what we would see once such a series
> lands).
> 
>  CODE_OF_CONDUCT.md | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> # Git Code of Conduct
> 
> This code of conduct outlines our expectations for participants within
> the Git community, as well as steps for reporting unacceptable behavior.
> We are committed to providing a welcoming and inspiring community for
> all and expect our code of conduct to be honored. Anyone who violates
> this code of conduct may be banned from the community.
> 
> ## Our Pledge
> 
> In the interest of fostering an open and welcoming environment, we as
> contributors and maintainers pledge to make participation in our project and
> our community a harassment-free experience for everyone, regardless of age,
> body size, disability, ethnicity, sex characteristics, gender identity and
> expression, level of experience, education, socio-economic status,
> nationality, personal appearance, race, religion, or sexual identity and
> orientation.
> 
> ## Our Standards
> 
> Examples of behavior that contributes to creating a positive environment
> include:
> 
> * Using welcoming and inclusive language

What's welcoming to some is repulsive to others.

For example: vger blocks HTML email.

IMHO it's the right thing to do since it blocks much spam and
phishing while saving precious storage and bandwidth.

However, other folks consider it "gatekeeping", because their
developed-by-a-megacorp mail tool defaults to HTML.  On the
other hand, I consider gatekeeping to be making things more
expensive in terms of computing resources.  Just because
Moore's law exists doesn't mean our contributors have the
socio-economic status to keep up with it.


Another example: "Fork me on GitXYZ!" which is intended to
welcome contributions.  For me, that's repulsive since it
requires:

1) using a Javascript VM (browser) that bogs my system down
2) accepting their Terms of Service (which can change at any time)
3) doing a CAPTCHA
4) contributing via such service(s) implies tacit endorsement of
   a proprietary/open-core SAAS

git remains one of the few projects I'm comfortable contributing
to because of that.

> * Being respectful of differing viewpoints and experiences

Agreed.  And we should not be trying to please everybody.

> * Gracefully accepting constructive criticism
> * Focusing on what is best for the community
> * Showing empathy towards other community members
> 
> Examples of unacceptable behavior by participants include:
> 
> * The use of sexualized language or imagery and unwelcome sexual attention or
>   advances
> * Trolling, insulting/derogatory comments, and personal or political attacks
> * Public or private harassment

> * Publishing others' private information, such as a physical or electronic
>   address, without explicit permission

Very much agreed on keeping private information private.
I honestly wished we'd just allow anonymous contributions since
identity verification is and ought to remain impossible; but
I understand there's legal concerns about GPL enforcement, too.

> * Other conduct which could reasonably be considered inappropriate in a
>   professional setting

I've been sometimes considered "unprofessional" for sticking to
plain-text mail/IRC, refusing to deal with video conferencing,
proprietary/hosted chat, etc.  To me, it's about cost-cutting
and minimizing security risks, but I don't work with some people
because of it.  Outside of open source, it's also about preserving
trade secrets.

> ## Our Responsibilities
> 
> Project maintainers are responsible for clarifying the standards of acceptable
> behavior and are expected to take appropriate and fair corrective action in
> response to any instances of unacceptable behavior.
> 
> Project maintainers have the right and responsibility to remove, edit, or
> reject comments, commits, code, wiki edits, issues, and other contributions
> that are not aligned to this Code of Conduct, or to ban temporarily or
> permanently any contributor for other behaviors that they deem inappropriate,
> threatening, offensive, or harmful.
> 
> ## Scope
> 
> This Code of Conduct applies within all project spaces, and it also applies
> when an individual is representing the project or its community in public
> spaces. Examples of representing a project or community include using an
> official project e-mail address, posting via an official social media account,
> or acting as an appointed representative at an online or offline event.
> Representation of a project may be further defined and clarified by project
> maintainers.
> 
> ## Enforcement
> 
> Instances of abusive, harassing, or otherwise unacceptable behavior may be
> reported by contacting the project team at git@sfconservancy.org. All
> complaints will be reviewed and investigated and will result in a response
> that is deemed necessary and appropriate to the circumstances. The project
> team is obligated to maintain confidentiality with regard to the reporter of
> an incident. Further details of specific enforcement policies may be posted
> separately.

Given the absence of identity verification on the Internet
(which I'm thankful for), enforcement seems toothless.

> Project maintainers who do not follow or enforce the Code of Conduct in good
> faith may face temporary or permanent repercussions as determined by other
> members of the project's leadership.
> 
> The project leadership team can be contacted by email as a whole at
> git@sfconservancy.org, or individually:
> 
>   - Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>   - Christian Couder <christian.couder@gmail.com>
>   - Jeff King <peff@peff.net>
>   - Junio C Hamano <gitster@pobox.com>

All folks that have proven to exhibit good judgement in the past,
and hope they continue to exhibit that in the future.

Though we shouldn't forget unexpected things have happened
in the past, such as SFLC suing SFC...


Just pointing out some concerns of mine.  No ack from me
(but it's not a NACK, either).  I'm pretty ambivalent...

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Junio C Hamano]

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

> ... but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.

Now, two days and four hours have passed, so I'll merge the result
to 'next' (and thusly this poll is now closed).

Thanks, all.

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Jeff King]

On Thu, Oct 10, 2019 at 12:18:53AM +0000, Eric Wong wrote:

> > The project leadership team can be contacted by email as a whole at
> > git@sfconservancy.org, or individually:
> > 
> >   - Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> >   - Christian Couder <christian.couder@gmail.com>
> >   - Jeff King <peff@peff.net>
> >   - Junio C Hamano <gitster@pobox.com>
> 
> All folks that have proven to exhibit good judgement in the past,
> and hope they continue to exhibit that in the future.

I snipped your concerns with some of the language. I do agree with you
that a lot of is open to interpretation. But I also think it's
impossible to get it 100% airtight. My feeling was that it was a good
idea to go with some existing, well-established text, even if it has
some wiggle room. And then rely on the existing community and especially
the people listed above to do that interpretation.

So...

> Just pointing out some concerns of mine.  No ack from me
> (but it's not a NACK, either).  I'm pretty ambivalent...

For me it is obviously an ack, but I wanted to make clear that I think
your concerns (and those of others who spoke up, like René and Gábor)
are certainly _valid_. I just think that adopting this CoC is, while not
perfect, the least-bad option.

I'd also say that we might consider living with it for a while (6
months? a year?) and seeing if people have an interest in revising it
after that point based on experience.

This is the same text used by the kernel, btw.  I think somebody
mentioned to me (but I think it may have been off-list) that the kernel
has an "interpretation" document:

  https://www.kernel.org/doc/html/latest/process/code-of-conduct-interpretation.html

which clarifies a few terms with respect to that specific community. I
didn't feel that we particularly needed to do that for our community,
but if somebody wants to work up a clarifying document, I'd be happy to
review it.

-Peff

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Jeff King]

On Fri, Oct 11, 2019 at 01:39:28PM +0900, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > ... but I'd still wait for a few
> > days for people who expressed their Acks but your scan missed, or
> > those who wanted to give their Acks but forgot to do so, to raise
> > their hands on this thread.
> 
> Now, two days and four hours have passed, so I'll merge the result
> to 'next' (and thusly this poll is now closed).
> 
> Thanks, all.

One final bit we might want to consider: we've heard positively from all
of the people on the project committee whose names are on the document
except Ævar. He's been rather quiet lately overall, so it may be
busyness and not silent disapproval. :) But perhaps it makes sense to
get an ack there, too (+cc).

-Peff

Re: Raise your hand to Ack jk/code-of-conduct if your Ack fell thru cracks

[Philip Oakley]

Hi all,

On 11/10/2019 06:58, Jeff King wrote:
> I snipped your concerns with some of the language. I do agree with you
> that a lot of is open to interpretation. But I also think it's
> impossible to get it 100% airtight. My feeling was that it was a good
> idea to go with some existing, well-established text, even if it has
> some wiggle room. And then rely on the existing community and especially
> the people listed above to do that interpretation.
>
> So...
>
>> Just pointing out some concerns of mine.  No ack from me
>> (but it's not a NACK, either).  I'm pretty ambivalent...
> For me it is obviously an ack, but I wanted to make clear that I think
> your concerns (and those of others who spoke up, like René and Gábor)
> are certainly_valid_. I just think that adopting this CoC is, while not
> perfect, the least-bad option.
>
> I'd also say that we might consider living with it for a while (6
> months? a year?) and seeing if people have an interest in revising it
> after that point based on experience.
  I also didn't positively ack the CoC (code of conduct).

I'm not sure it addresses the broader _underlying_ issues that may need 
to be addressed that are behind the pressure for CoCs. I'd also 
commented [1] on the git-for-windows CoC partly because the CoC didn't 
positively address the need for tolerance.

These CoCs are essentially defensive, rather than forward looking. In 
essence they say:

We are a welcoming and inspiring community, open to anyone and 
everyone(all 2^16 variants).

We list various egregious behaviours that are unwanted and hence 
intolerable.

We list responses to such intolerable behaviour.

However we (in the CoC document) don't really address what we may need 
to do to extend the community to the broader many.

Part of the wider problem is we often don't appreciate our pre-existing 
organisational biases (e.g.[2, 3]) that we fit into within a community. 
For example the implicit gender bias toward independent sole author 
contributions[4], rather than the inclusiveness of co-authorship as a norm.

While following peff's "interpretation" document link [5], I did see, in 
the wider kernel document, that it does have a "Co-developed-by:" option 
[6] but then requires a secondary "Signed-off-by:", thus making those 
who co-author do extra work, which shouldn't be required.

Thus, while the CoC is good, for clarifying the egregious behaviour 
issues, it doesn't really address the wider 'Diversity and Equality' 
*expectations* within the community.

Philip

[1] https://github.com/git-for-windows/git/pull/661#issuecomment-186846113
[2] "institutional racism" 
https://en.wikipedia.org/wiki/Institutional_racism
[3] "institutional sexism" ... no Wikipedia article?
[4] 
https://www.computing.co.uk/ctg/sponsored/3082288/want-to-increase-diversity-it-starts-with-the-job-ad
[5] 
https://www.kernel.org/doc/html/latest/process/code-of-conduct-interpretation.html
[6] https://www.kernel.org/doc/html/latest/process/submitting-patches.html