{"thread":{"id":"46650","subject":"What's cooking in git.git (Aug 2017, #05; Tue, 22)","startedAt":"2017-08-22T19:56:54Z","lastAt":"2017-09-29T12:15:53Z","messageCount":16,"participants":["Junio C Hamano","Brandon Williams","Lars Schneider","Johannes Schindelin","Jonathan Nieder","Nicolas Morey-Chaisemartin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"326962","messageId":"xmqq4lsz2x6r.fsf@gitster.mtv.corp.google.com","threadId":"46650","inReplyTo":null,"subject":"What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-22T19:56:44Z","receivedAt":"2017-08-22T19:56:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed with\n'-' are only in 'pu' (proposed updates) while commits prefixed with\n'+' are in 'next'.  The ones marked with '.' do not appear in any of\nthe integration branches, but I am still holding onto them.\n\nThe second batch of topics are in.  This cycle is going a bit slower\nthan the previous one (as of mid-week #3 of this cycle, we have\nabout 200 patches on 'master' since v2.14, compared to about 300\npatches in the cycle towards v2.14 at a similar point in the cycle),\nbut hopefully we can catch up eventually.  \n\nI am planning to be offline most of the next week, by the way.\n\nYou can find the changes described here in the integration branches\nof the repositories listed at\n\n    http://git-blame.blogspot.com/p/git-public-repositories.html\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ab/ref-filter-no-contains (2017-08-07) 1 commit\n  (merged to 'next' on 2017-08-18 at 7ec9d3d3a2)\n + tests: don't give unportable \">\" to \"test\" built-in, use -gt\n\n A test fix.\n\n\n* bw/clone-recursive-quiet (2017-08-04) 1 commit\n  (merged to 'next' on 2017-08-14 at fbd4473ce4)\n + clone: teach recursive clones to respect -q\n\n \"git clone --recurse-submodules --quiet\" did not pass the quiet\n option down to submodules.\n\n\n* bw/grep-recurse-submodules (2017-08-02) 10 commits\n  (merged to 'next' on 2017-08-14 at dcfcfc94af)\n + grep: recurse in-process using 'struct repository'\n + submodule: merge repo_read_gitmodules and gitmodules_config\n + submodule: check for unmerged .gitmodules outside of config parsing\n + submodule: check for unstaged .gitmodules outside of config parsing\n + submodule: remove fetch.recursesubmodules from submodule-config parsing\n + submodule: remove submodule.fetchjobs from submodule-config parsing\n + config: add config_from_gitmodules\n + cache.h: add GITMODULES_FILE macro\n + repository: have the_repository use the_index\n + repo_read_index: don't discard the index\n (this branch is used by bw/submodule-config-cleanup.)\n\n \"git grep --recurse-submodules\" has been reworked to give a more\n consistent output across submodule boundary (and do its thing\n without having to fork a separate process).\n\n\n* bw/push-options-recursively-to-submodules (2017-07-20) 1 commit\n  (merged to 'next' on 2017-08-14 at 421dc09fd0)\n + submodule--helper: teach push-check to handle HEAD\n\n \"git push --recurse-submodules $there HEAD:$target\" was not\n propagated down to the submodules, but now it is.\n\n\n* jc/perl-git-comment-typofix (2017-08-07) 1 commit\n  (merged to 'next' on 2017-08-18 at b2ad043e6a)\n + perl/Git.pm: typofix in a comment\n\n A comment fix.\n\n\n* jk/drop-sha1-entry-pos (2017-08-09) 1 commit\n  (merged to 'next' on 2017-08-18 at 3a4d9bcf12)\n + sha1_file: drop experimental GIT_USE_LOOKUP search\n (this branch is used by jt/packmigrate.)\n\n Code clean-up.\n\n\n* jk/hashcmp-memcmp (2017-08-09) 1 commit\n  (merged to 'next' on 2017-08-18 at 27c4aa5520)\n + hashcmp: use memcmp instead of open-coded loop\n\n Code clean-up.\n\n\n* ma/parse-maybe-bool (2017-08-07) 6 commits\n  (merged to 'next' on 2017-08-18 at ba22bb836c)\n + parse_decoration_style: drop unused argument `var`\n + treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool\n + config: make git_{config,parse}_maybe_bool equivalent\n + config: introduce git_parse_maybe_bool_text\n + t5334: document that git push --signed=1 does not work\n + Doc/git-{push,send-pack}: correct --sign= to --signed=\n\n Code clean-up.\n\n\n* mf/no-dashed-subcommands (2017-08-07) 1 commit\n  (merged to 'next' on 2017-08-18 at 05365af2ff)\n + scripts: use \"git foo\" not \"git-foo\"\n\n Code clean-up.\n\n\n* mh/packed-ref-store (2017-08-17) 32 commits\n  (merged to 'next' on 2017-08-18 at 14c58936e1)\n + files-backend: cheapen refname_available check when locking refs\n  (merged to 'next' on 2017-08-14 at 987b76d302)\n + packed_ref_store: handle a packed-refs file that is a symlink\n + read_packed_refs(): die if `packed-refs` contains bogus data\n + t3210: add some tests of bogus packed-refs file contents\n + repack_without_refs(): don't lock or unlock the packed refs\n + commit_packed_refs(): remove call to `packed_refs_unlock()`\n + clear_packed_ref_cache(): don't protest if the lock is held\n + packed_refs_unlock(), packed_refs_is_locked(): new functions\n + packed_refs_lock(): report errors via a `struct strbuf *err`\n + packed_refs_lock(): function renamed from lock_packed_refs()\n + commit_packed_refs(): use a staging file separate from the lockfile\n + commit_packed_refs(): report errors rather than dying\n + packed_ref_store: make class into a subclass of `ref_store`\n + packed-backend: new module for handling packed references\n + packed_read_raw_ref(): new function, replacing `resolve_packed_ref()`\n + packed_ref_store: support iteration\n + packed_peel_ref(): new function, extracted from `files_peel_ref()`\n + repack_without_refs(): take a `packed_ref_store *` parameter\n + get_packed_ref(): take a `packed_ref_store *` parameter\n + rollback_packed_refs(): take a `packed_ref_store *` parameter\n + commit_packed_refs(): take a `packed_ref_store *` parameter\n + lock_packed_refs(): take a `packed_ref_store *` parameter\n + add_packed_ref(): take a `packed_ref_store *` parameter\n + get_packed_refs(): take a `packed_ref_store *` parameter\n + get_packed_ref_cache(): take a `packed_ref_store *` parameter\n + validate_packed_ref_cache(): take a `packed_ref_store *` parameter\n + clear_packed_ref_cache(): take a `packed_ref_store *` parameter\n + packed_ref_store: move `packed_refs_lock` member here\n + packed_ref_store: move `packed_refs_path` here\n + packed_ref_store: new struct\n + add_packed_ref(): teach function to overwrite existing refs\n + t1408: add a test of stale packed refs covered by loose refs\n\n The \"ref-store\" code reorganization continues.\n\n\n* pw/am-signoff (2017-08-08) 1 commit\n  (merged to 'next' on 2017-08-18 at 7678ed822c)\n + am: fix signoff when other trailers are present\n\n \"git am -s\" has been taught that some input may end with a trailer\n block that is not Signed-off-by: and it should refrain from adding\n an extra blank line before adding a new sign-off in such a case.\n\n\n* pw/sequence-rerere-autoupdate (2017-08-02) 6 commits\n  (merged to 'next' on 2017-08-14 at 010cbb0cbe)\n + cherry-pick/revert: reject --rerere-autoupdate when continuing\n + cherry-pick/revert: remember --rerere-autoupdate\n + t3504: use test_commit\n + rebase -i: honor --rerere-autoupdate\n + rebase: honor --rerere-autoupdate\n + am: remember --rerere-autoupdate setting\n\n Commands like \"git rebase\" accepted the --rerere-autoupdate option\n from the command line, but did not always use it.  This has been\n fixed.\n\n\n* rj/add-chmod-error-message (2017-08-09) 1 commit\n  (merged to 'next' on 2017-08-18 at ba2afb696a)\n + builtin/add: add detail to a 'cannot chmod' error message\n\n Message fix.\n\n\n* rs/apply-lose-prefix-length (2017-08-09) 1 commit\n  (merged to 'next' on 2017-08-18 at 6ce0dbb3f0)\n + apply: remove prefix_length member from apply_state\n\n Code clean-up.\n\n\n* rs/find-pack-entry-bisection (2017-08-09) 1 commit\n  (merged to 'next' on 2017-08-18 at b4130177a9)\n + sha1_file: avoid comparison if no packed hash matches the first byte\n (this branch is used by jt/packmigrate.)\n\n Code clean-up.\n\n\n* rs/fsck-obj-leakfix (2017-08-10) 1 commit\n  (merged to 'next' on 2017-08-18 at 77e3d111ef)\n + fsck: free buffers on error in fsck_obj()\n\n Memory leak in an error codepath has been plugged.\n\n\n* rs/in-obsd-basename-dirname-take-const (2017-08-07) 1 commit\n  (merged to 'next' on 2017-08-18 at c739077e3b)\n + test-path-utils: handle const parameter of basename and dirname\n\n Portability fix.\n\n\n* rs/merge-microcleanup (2017-08-10) 1 commit\n  (merged to 'next' on 2017-08-18 at 79ba7d301d)\n + merge: use skip_prefix()\n\n Code clean-up.\n\n\n* rs/obsd-getcwd-workaround (2017-08-07) 1 commit\n  (merged to 'next' on 2017-08-18 at adb98cfe0c)\n + t0001: skip test with restrictive permissions if getpwd(3) respects them\n\n Test portability fix for BSDs.\n\n\n* rs/strbuf-getwholeline-fix (2017-08-10) 1 commit\n  (merged to 'next' on 2017-08-18 at 5f879d8261)\n + strbuf: clear errno before calling getdelim(3)\n\n A helper function to read a single whole line into strbuf\n mistakenly triggered OOM error at EOF under certain conditions,\n which has been fixed.\n\n\n* rs/t3700-clean-leftover (2017-08-08) 1 commit\n  (merged to 'next' on 2017-08-18 at 12232a8cd3)\n + t3700: fix broken test under !POSIXPERM\n\n A test fix.\n\n\n* rs/t4062-obsd (2017-08-09) 1 commit\n  (merged to 'next' on 2017-08-18 at 02bff42d86)\n + t4062: use less than 256 repetitions in regex\n\n Test portability fix.\n\n\n* rs/unpack-entry-leakfix (2017-08-10) 1 commit\n  (merged to 'next' on 2017-08-18 at 1e7d8f54b1)\n + sha1_file: release delta_stack on error in unpack_entry()\n (this branch is used by jt/packmigrate.)\n\n Memory leak in an error codepath has been plugged.\n\n\n* rs/win32-syslog-leakfix (2017-08-10) 1 commit\n  (merged to 'next' on 2017-08-18 at 011eccb7bd)\n + win32: plug memory leak on realloc() failure in syslog()\n\n Memory leak in an error codepath has been plugged.\n\n\n* sb/retire-t1200 (2017-08-10) 1 commit\n  (merged to 'next' on 2017-08-18 at d436f9bbce)\n + t1200: remove t1200-tutorial.sh\n\n A test script that outlived its usefulness has been removed.\n\n\n* ur/svn-local-zone (2017-08-08) 1 commit\n  (merged to 'next' on 2017-08-18 at f222bb6db0)\n + git svn fetch: Create correct commit timestamp when using --localtime\n\n \"git svn\" used with \"--localtime\" option did not compute the tz\n offset for the timestamp in question and instead always used the\n current time, which has been corrected.\n\n--------------------------------------------------\n[New Topics]\n\n* jt/packmigrate (2017-08-19) 27 commits\n - pack: move for_each_packed_object()\n - pack: move has_pack_index()\n - pack: move has_sha1_pack()\n - pack: move find_pack_entry() and make it global\n - pack: move find_sha1_pack()\n - pack: move find_pack_entry_one(), is_pack_valid()\n - pack: move check_pack_index_ptr(), nth_packed_object_offset()\n - pack: move nth_packed_object_{sha1,oid}\n - pack: move clear_delta_base_cache(), packed_object_info(), unpack_entry()\n - pack: move unpack_object_header()\n - pack: move get_size_from_delta()\n - pack: move unpack_object_header_buffer()\n - pack: move {,re}prepare_packed_git and approximate_object_count\n - pack: move install_packed_git()\n - pack: move add_packed_git()\n - pack: move unuse_pack()\n - pack: move use_pack()\n - pack: move pack-closing functions\n - pack: move release_pack_memory()\n - pack: move open_pack_index(), parse_pack_index()\n - pack: move pack_report()\n - pack: move static state variables\n - pack: move pack name-related functions\n - Merge branch 'rs/unpack-entry-leakfix' into HEAD\n - Merge branch 'jt/sha1-file-cleanup' into HEAD\n - Merge branch 'jk/drop-sha1-entry-pos' into HEAD\n - Merge branch 'rs/find-pack-entry-bisection' into HEAD\n (this branch uses jt/sha1-file-cleanup.)\n\n Code movement to make it easier to hack later.\n\n Rebase this on the master after jt/sha1-file-cleanup graduates and\n merge it to 'next' (if reviewers found this a good change, that\n is).\n\n\n* jc/cutoff-config (2017-08-19) 2 commits\n - rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved\n - rerere: represent time duration in timestamp_t internally\n\n \"[gc] rerereResolved = 5.days\" used to be invalid, as the variable\n is defined to take an integer counting the number of days.  It now\n is allowed.\n\n Needs reroll.\n cf. <xmqqa82t7ov1.fsf@gitster.mtv.corp.google.com>\n\n\n* jc/simplify-progress (2017-08-19) 1 commit\n - progress: simplify \"delayed\" progress API\n\n The API to start showing progress meter after a short delay has\n been simplified.\n\n Will merge to 'next'.\n\n\n* jt/stash-tests (2017-08-19) 3 commits\n  (merged to 'next' on 2017-08-22 at 0b022697aa)\n + stash: add a test for stashing in a detached state\n + stash: add a test for when apply fails during stash branch\n + stash: add a test for stash create with no files\n\n Test update to improve coverage for \"git stash\" operations.\n\n Will merge to 'master'.\n\n\n* rs/archive-excluded-directory (2017-08-19) 3 commits\n - archive: don't queue excluded directories\n - archive: factor out helper functions for handling attributes\n - t5001: add tests for export-ignore attributes and exclude pathspecs\n\n \"git archive\" did not work well with pathspecs and the\n export-ignore attribute.\n\n Will merge to 'next'.\n\n We may want to resurrect the \"we don't archive an empty directory\"\n bonus patch, but I do not mind merging the above early to 'next'\n and leave it as a separate follow-up enhancement.\n cf. <20170820090629.tumvqwzkromcykjf@sigill.intra.peff.net>\n\n\n* rs/commit-h-single-parent-cleanup (2017-08-19) 1 commit\n  (merged to 'next' on 2017-08-22 at 7db01c4035)\n + commit: remove unused inline function single_parent()\n\n Code clean-up.\n\n Will merge to 'master'.\n\n\n* bc/hash-algo (2017-08-20) 5 commits\n - hash-algo: switch empty tree and blob lookups to use hash abstraction\n - hash-algo: integrate hash algorithm support with repo setup\n - hash-algo: add structure representing hash algorithm\n - setup: expose enumerated repo info\n - Merge branch 'bc/vcs-svn-cleanup' into bc/hash-algo\n (this branch uses bc/vcs-svn-cleanup.)\n\n\n* bc/vcs-svn-cleanup (2017-08-20) 2 commits\n - vcs-svn: rename repo functions to \"svn_repo\"\n - vcs-svn: remove unused prototypes\n (this branch is used by bc/hash-algo.)\n\n Code clean-up.\n\n Will merge to 'next'.\n\n\n* jk/doc-the-this (2017-08-20) 1 commit\n - doc: fix typo in sendemail.identity\n\n Doc clean-up.\n\n Will merge to 'next'.\n\n\n* kw/write-index-reduce-alloc (2017-08-21) 3 commits\n - read-cache: avoid allocating every ondisk entry when writing\n - read-cache: fix memory leak in do_write_index\n - perf: add test for writing the index\n\n\n* mg/killed-merge (2017-08-21) 3 commits\n - merge: save merge state earlier\n - merge: split write_merge_state in two\n - Documentation/git-merge: explain --continue\n\n Killing \"git merge --edit\" before the editor returns control left\n the repository in a state with MERGE_MSG but without MERGE_HEAD,\n which incorrectly tells the subsequent \"git commit\" that there was\n a squash merge in progress.  This has been fixed.\n\n Looked mostly good with minor nits.\n cf. <36bea69b-010a-9542-ec87-38b00d2bb009@grubix.eu>\n\n\n* po/object-id (2017-08-20) 6 commits\n - sha1_file: convert index_stream to struct object_id\n - sha1_file: convert hash_sha1_file_literally to struct object_id\n - sha1_file: convert index_fd to struct object_id\n - sha1_file: convert index_path to struct object_id\n - read-cache: convert to struct object_id\n - builtin/hash-object: convert to struct object_id\n\n Will merge to 'next'.\n\n\n--------------------------------------------------\n[Stalled]\n\n* mg/status-in-progress-info (2017-05-10) 2 commits\n - status --short --inprogress: spell it as --in-progress\n - status: show in-progress info for short status\n\n \"git status\" learns an option to report various operations\n (e.g. \"merging\") that the user is in the middle of.\n\n cf. <xmqqmvakcdqw.fsf@gitster.mtv.corp.google.com>\n\n\n* nd/worktree-move (2017-04-20) 6 commits\n - worktree remove: new command\n - worktree move: refuse to move worktrees with submodules\n - worktree move: accept destination as directory\n - worktree move: new command\n - worktree.c: add update_worktree_location()\n - worktree.c: add validate_worktree()\n\n \"git worktree\" learned move and remove subcommands.\n\n Expecting a reroll.\n cf. <20170420101024.7593-1-pclouds@gmail.com>\n cf. <20170421145916.mknekgqzhxffu7di@sigill.intra.peff.net>\n cf. <d0e81b1e-5869-299e-f462-4d43dc997bd1@ramsayjones.plus.com>\n\n\n* sg/clone-refspec-from-command-line-config (2017-06-16) 2 commits\n - Documentation/clone: document ignored configuration variables\n - clone: respect additional configured fetch refspecs during initial fetch\n (this branch is used by sg/remote-no-string-refspecs.)\n\n \"git clone -c var=val\" is a way to set configuration variables in\n the resulting repository, but it is more useful to also make these\n variables take effect while the initial clone is happening,\n e.g. these configuration variables could be fetch refspecs.\n\n Waiting for a response.\n cf. <20170617112228.vugswym4o4owf6wj@sigill.intra.peff.net>\n cf. <xmqqmv8zhdap.fsf@gitster.mtv.corp.google.com>\n\n\n* js/rebase-i-final (2017-07-27) 10 commits\n - rebase -i: rearrange fixup/squash lines using the rebase--helper\n - t3415: test fixup with wrapped oneline\n - rebase -i: skip unnecessary picks using the rebase--helper\n - rebase -i: check for missing commits in the rebase--helper\n - t3404: relax rebase.missingCommitsCheck tests\n - rebase -i: also expand/collapse the SHA-1s via the rebase--helper\n - rebase -i: do not invent onelines when expanding/collapsing SHA-1s\n - rebase -i: remove useless indentation\n - rebase -i: generate the script via rebase--helper\n - t3415: verify that an empty instructionFormat is handled as before\n\n The final batch to \"git rebase -i\" updates to move more code from\n the shell script to C.\n\n Expecting a reroll.\n\n\n* bp/fsmonitor (2017-06-12) 6 commits\n - fsmonitor: add a sample query-fsmonitor hook script for Watchman\n - fsmonitor: add documentation for the fsmonitor extension.\n - fsmonitor: add test cases for fsmonitor extension\n - fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.\n - dir: make lookup_untracked() available outside of dir.c\n - bswap: add 64 bit endianness helper get_be64\n\n We learned to talk to watchman to speed up \"git status\".\n\n Expecting a reroll.\n cf. <bade1166-e646-b05a-f65b-adb8da8ba0a7@gmail.com>\n\n--------------------------------------------------\n[Cooking]\n\n* cc/subprocess-handshake-missing-capabilities (2017-08-16) 1 commit\n  (merged to 'next' on 2017-08-19 at c512710fda)\n + sub-process: print the cmd when a capability is unsupported\n\n When handshake with a subprocess filter notices that the process\n asked for an unknown capability, Git did not report what program\n the offending subprocess was running.  This has been corrected.\n\n Will merge to 'master'.\n\n We may want a follow-up fix to tighten the error checking, though.\n\n\n* tb/apply-with-crlf (2017-08-19) 2 commits\n  (merged to 'next' on 2017-08-22 at f92bf67061)\n + apply: file commited with CRLF should roundtrip diff and apply\n + convert: add SAFE_CRLF_KEEP_CRLF\n (this branch is tangled with jc/apply-with-crlf.)\n\n \"git apply\" that is used as a better \"patch -p1\" failed to apply a\n taken from a file with CRLF line endings to a file with CRLF line\n endings.  The root cause was because it misused convert_to_git()\n that tried to do \"safe-crlf\" processing by looking at the index\n entry at the same path, which is a nonsense---in that mode, \"apply\"\n is not working on the data in (or derived from) the index at all.\n This has been fixed.\n\n Will merge to 'master'.\n\n\n* rs/t1002-do-not-use-sum (2017-08-15) 1 commit\n  (merged to 'next' on 2017-08-19 at 15b2a5f21b)\n + t1002: stop using sum(1)\n\n Test simplification.\n\n Will merge to 'master'.\n\n\n* sb/sha1-file-cleanup (2017-08-15) 1 commit\n  (merged to 'next' on 2017-08-19 at 85898d1e7c)\n + sha1_file: make read_info_alternates static\n\n Code clean-up.\n\n Will merge to 'master'.\n\n\n* as/grep-quiet-no-match-exit-code-fix (2017-08-17) 1 commit\n  (merged to 'next' on 2017-08-19 at 362f88fb41)\n + git-grep: correct exit code with --quiet and -L\n\n \"git grep -L\" and \"git grep --quiet -L\" reported different exit\n codes; this has been corrected.\n\n Will merge to 'master'.\n\n\n* hv/t5526-andand-chain-fix (2017-08-17) 1 commit\n  (merged to 'next' on 2017-08-19 at fa95053653)\n + t5526: fix some broken && chains\n\n Test fix.\n\n Will merge to 'master'.\n\n\n* jc/diff-sane-truncate-no-more (2017-08-17) 1 commit\n  (merged to 'next' on 2017-08-19 at 3ba3980eed)\n + diff: retire sane_truncate_fn\n\n Code clean-up.\n\n Will merge to 'master'.\n\n\n* ks/branch-set-upstream (2017-08-17) 3 commits\n - branch: quote branch/ref names to improve readability\n - builtin/branch: stop supporting the \"--set-upstream\" option\n - t3200: cleanup cruft of a test\n\n \"branch --set-upstream\" that has been deprecated in Git 1.8 has\n finally been retired.\n\n Will merge to 'next'.\n\n\n* mg/format-ref-doc-fix (2017-08-18) 2 commits\n  (merged to 'next' on 2017-08-19 at 6490525c54)\n + Documentation/git-for-each-ref: clarify peeling of tags for --format\n + Documentation: use proper wording for ref format strings\n\n Doc fix.\n\n Will merge to 'master'.\n\n\n* po/read-graft-line (2017-08-18) 4 commits\n  (merged to 'next' on 2017-08-22 at 1e3fe0d3a1)\n + commit: rewrite read_graft_line\n + commit: allocate array using object_id size\n + commit: replace the raw buffer with strbuf in read_graft_line\n + sha1_file: fix definition of null_sha1\n\n Conversion from uchar[20] to struct object_id continues; this is to\n ensure that we do not assume sizeof(struct object_id) is the same\n as the length of SHA-1 hash (or length of longest hash we support).\n\n Will merge to 'master'.\n\n\n* sb/submodule-parallel-update (2017-08-17) 1 commit\n  (merged to 'next' on 2017-08-19 at c023a834f0)\n + submodule.sh: remove unused variable\n\n Code clean-up.\n\n Will merge to 'master'.\n\n\n* ks/prepare-commit-msg-sample-fix (2017-08-14) 1 commit\n  (merged to 'next' on 2017-08-19 at e75c30de64)\n + hook: use correct logical variable\n\n An \"oops\" fix to a topic that is already in 'master'.\n\n Will merge to 'master'.\n\n\n* mk/diff-delta-uint-may-be-shorter-than-ulong (2017-08-10) 1 commit\n . diff-delta: fix encoding size that would not fit in \"unsigned int\"\n\n The machinery to create xdelta used in pack files received the\n sizes of the data in size_t, but lost the higher bits of them by\n storing them in \"unsigned int\" during the computation, which is\n fixed.\n\n Dropped, as it was rerolled for review as part of a larger series.\n cf. <1502914591-26215-1-git-send-email-martin@mail.zuhause>\n\n\n* jk/drop-ancient-curl (2017-08-09) 5 commits\n - http: #error on too-old curl\n - curl: remove ifdef'd code never used with curl >=7.19.4\n - http: drop support for curl < 7.19.4\n - http: drop support for curl < 7.16.0\n - http: drop support for curl < 7.11.1\n\n Some code in http.c that has bitrot is being removed.\n\n Will be rerolled after tc/curl-with-backports stabilizes.\n\n\n* tc/curl-with-backports (2017-08-11) 2 commits\n - http: use a feature check to enable GSSAPI delegation control\n - http: fix handling of missing CURLPROTO_*\n\n Updates to the HTTP layer we made recently unconditionally used\n features of libCurl without checking the existence of them, causing\n compilation errors, which has been fixed.  Also migrate the code to\n check feature macros, not version numbers, to cope better with\n libCurl that vendor ships with backported features.\n\n Will merge to 'next'.\n\n\n* jk/trailers-parse (2017-08-20) 9 commits\n  (merged to 'next' on 2017-08-22 at 2d4d937141)\n + doc/interpret-trailers: fix \"the this\" typo\n  (merged to 'next' on 2017-08-19 at faa63f8196)\n + pretty: support normalization options for %(trailers)\n + t4205: refactor %(trailers) tests\n + pretty: move trailer formatting to trailer.c\n + interpret-trailers: add --parse convenience option\n + interpret-trailers: add an option to unfold values\n + interpret-trailers: add an option to show only existing trailers\n + interpret-trailers: add an option to show only the trailers\n + trailer: put process_trailers() options into a struct\n\n \"git interpret-trailers\" has been taught a \"--parse\" and a few\n other options to make it easier for scripts to grab existing\n trailer lines from a commit log message.\n\n Will merge to 'master'.\n Possible leftover bits are mentioned in\n cf. <20170820094009.z23wclpku35txflg@sigill.intra.peff.net>\n\n\n* mk/use-size-t-in-zlib (2017-08-10) 1 commit\n . zlib.c: use size_t for size\n\n The wrapper to call into zlib followed our long tradition to use\n \"unsigned long\" for sizes of regions in memory, which have been\n updated to use \"size_t\".\n\n Dropped, as it was rerolled for review as part of a larger series.\n cf. <1502914591-26215-1-git-send-email-martin@mail.zuhause>\n\n\n* jt/sha1-file-cleanup (2017-08-11) 2 commits\n  (merged to 'next' on 2017-08-19 at 93f4c94578)\n + sha1_file: remove read_packed_sha1()\n + sha1_file: set whence in storage-specific info fn\n (this branch is used by jt/packmigrate.)\n\n Preparatory code clean-up.\n\n Will merge to 'master'.\n\n\n* kw/rebase-progress (2017-08-14) 2 commits\n  (merged to 'next' on 2017-08-19 at 1958f378dd)\n + rebase: turn on progress option by default for format-patch\n + format-patch: have progress option while generating patches\n\n \"git rebase\", especially when it is run by mistake and ends up\n trying to replay many changes, spent long time in silence.  The\n command has been taught to show progress report when it spends\n long time preparing these many changes to replay (which would give\n the user a chance to abort with ^C).\n\n Will merge to 'master'.\n\n\n* mk/diff-delta-avoid-large-offset (2017-08-11) 1 commit\n . diff-delta: do not allow delta offset truncation\n\n The delta format used in the packfile cannot reference data at\n offset larger than what can be expressed in 4-byte, but the\n generator for the data failed to make sure the offset does not\n overflow.  This has been corrected.\n\n Dropped, as it was rerolled for review as part of a larger series.\n cf. <1502914591-26215-1-git-send-email-martin@mail.zuhause>\n\n\n* nm/stash-untracked (2017-08-11) 1 commit\n  (merged to 'next' on 2017-08-19 at 70990d7eb3)\n + stash: clean untracked files before reset\n\n \"git stash -u\" used the contents of the committed version of the\n \".gitignore\" file to decide which paths are ignored, even when the\n file has local changes.  The command has been taught to instead use\n the locally modified contents.\n\n Will merge to 'master'.\n\n\n* rs/object-id (2017-08-14) 1 commit\n  (merged to 'next' on 2017-08-19 at 0f7283cd19)\n + tree-walk: convert fill_tree_descriptor() to object_id\n\n Conversion from uchar[20] to struct object_id continues.\n\n Will merge to 'master'.\n\n\n* ah/doc-empty-string-is-false (2017-08-14) 1 commit\n  (merged to 'next' on 2017-08-19 at df47ffeffa)\n + doc: clarify \"config --bool\" behaviour with empty string\n\n Doc update.\n\n Will merge to 'master'.\n\n\n* jt/diff-color-move-fix (2017-08-16) 3 commits\n  (merged to 'next' on 2017-08-19 at 6ae3831c8c)\n + diff: define block by number of alphanumeric chars\n + diff: respect MIN_BLOCK_LENGTH for last block\n + diff: avoid redundantly clearing a flag\n (this branch uses sb/diff-color-move.)\n\n A handful of bugfixes and an improvement to \"diff --color-moved\".\n\n Will merge to 'master'.\n\n\n* kd/stash-with-bash-4.4 (2017-08-14) 1 commit\n  (merged to 'next' on 2017-08-19 at 79b2c4b052)\n + stash: prevent warning about null bytes in input\n\n bash 4.4 or newer gave a warning on NUL byte in command\n substitution done in \"git stash\"; this has been squelched.\n\n Will merge to 'master'.\n\n\n* kw/commit-keep-index-when-pre-commit-is-not-run (2017-08-16) 1 commit\n  (merged to 'next' on 2017-08-19 at 2b5a25e5ae)\n + commit: skip discarding the index if there is no pre-commit hook\n\n \"git commit\" used to discard the index and re-read from the filesystem\n just in case the pre-commit hook has updated it in the middle; this\n has been optimized out when we know we do not run the pre-commit hook.\n\n Will merge to 'master'.\n\n\n* bw/git-clang-format (2017-08-14) 2 commits\n - Makefile: add style build rule\n - clang-format: outline the git project's coding style\n\n \"make style\" runs git-clang-format to help developers by pointing\n out coding style issues.\n\n\n* lg/merge-signoff (2017-07-25) 1 commit\n  (merged to 'next' on 2017-08-19 at cb53d7b026)\n + merge: add a --signoff flag\n\n \"git merge\" learned a \"--signoff\" option to add the Signed-off-by:\n trailer with the committer's name.\n\n Will merge to 'master'.\n\n\n* pb/trailers-from-command-line (2017-08-14) 4 commits\n  (merged to 'next' on 2017-08-19 at b12342e49e)\n + interpret-trailers: fix documentation typo\n + interpret-trailers: add options for actions\n + trailers: introduce struct new_trailer_item\n + trailers: export action enums and corresponding lookup functions\n\n \"git interpret-trailers\" learned to take the trailer specifications\n from the command line that overrides the configured values.\n\n Will merge to 'master'.\n\n\n* sb/submodule-recursive-checkout-detach-head (2017-07-28) 2 commits\n - Documentation/checkout: clarify submodule HEADs to be detached\n - recursive submodules: detach HEAD from new state\n\n \"git checkout --recursive\" may overwrite and rewind the history of\n the branch that happens to be checked out in submodule\n repositories, which might not be desirable.  Detach the HEAD but\n still allow the recursive checkout to succeed in such a case.\n\n Undecided.\n This needs justification in a larger picture; it is unclear why\n this is better than rejecting recursive checkout, for example.\n\n\n* ti/external-sha1dc (2017-08-16) 2 commits\n - sha1dc: allow building with the external sha1dc library\n - sha1dc: build git plumbing code more explicitly\n\n Platforms that ship with a separate sha1 with collision detection\n library can link to it instead of using the copy we ship as part of\n our source tree.\n\n Waiting for reviews.\n cf. <20170815120417.31616-1-tiwai@suse.de>\n\n\n* bw/submodule-config-cleanup (2017-08-03) 17 commits\n - submodule: remove gitmodules_config\n - unpack-trees: improve loading of .gitmodules\n - submodule-config: lazy-load a repository's .gitmodules file\n - submodule-config: move submodule-config functions to submodule-config.c\n - submodule-config: remove support for overlaying repository config\n - diff: stop allowing diff to have submodules configured in .git/config\n - submodule: remove submodule_config callback routine\n - unpack-trees: don't respect submodule.update\n - submodule: don't rely on overlayed config when setting diffopts\n - fetch: don't overlay config with submodule-config\n - submodule--helper: don't overlay config in update-clone\n - submodule--helper: don't overlay config in remote_submodule_branch\n - add, reset: ensure submodules can be added or reset\n - submodule: don't use submodule_from_name\n - t7411: check configuration parsing errors\n - Merge branch 'bc/object-id' into bw/submodule-config-cleanup\n - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup\n\n Code clean-up to avoid mixing values read from the .gitmodules file\n and values read from the .git/config file.\n\n So, after the recent discussion around submodule.<name>.update (and\n its resolution \"use submodule.<name>.active; \"reset --hard\" must\n ignore the .update thing\"), this is now good to go, I presume?\n Please yell at me that I am clueless if that is not the case ;-)\n\n\n* jk/check-ref-format-oor-fix (2017-07-14) 1 commit\n - check-ref-format: require a repository for --branch\n\n Discussion slowly continues...\n cf. <20170717172709.GL93855@aiede.mtv.corp.google.com>\n cf. <20170817102217.3yw7uxnkupdy3lh5@sigill.intra.peff.net>\n\n\n* rs/sha1-file-micro-optim (2017-07-09) 2 commits\n - SQUASH???\n - sha1_file: add slash once in for_each_file_in_obj_subdir()\n\n Code cleanup.\n\n Perhaps drop.\n cf. <f59c8256-716b-9305-2a4f-d4fe49f666ff@web.de>\n\n\n* jc/allow-lazy-cas (2017-07-06) 1 commit\n - push: disable lazy --force-with-lease by default\n\n Because \"git push --force-with-lease[=<ref>]\" that relies on the\n stability of remote-tracking branches is unsafe when something\n fetches into the repository behind user's back, it is now disabled\n by default.  A new configuration variable can be used to enable it\n by users who know what they are doing.  This would pave the way to\n possibly turn `--force` into `--force-with-lease`.\n\n Will discard.\n Independent from disabling the feature by default, this stirred up\n a discussion to replace the DWIM heuristics with a better one, which\n deserves to be its own topic.\n cf. <alpine.DEB.2.21.1.1707131435220.4193@virtualbox>\n\n\n* ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits\n  (merged to 'next' on 2017-08-14 at 24db08a6e8)\n + pathspec: die on empty strings as pathspec\n + t0027: do not use an empty string as a pathspec element\n\n The final step to make an empty string as a pathspec element\n illegal.  We started this by first deprecating and warning a\n pathspec that has such an element in 2.11 (Nov 2016).\n\n Hopefully we can merge this down to the 'master' by the end of the\n year?  A deprecation warning period that is about 1 year does not\n sound too bad.\n\n Will cook in 'next'.\n As the draft RelNotes says, let's merge this to 'master' after\n this release cycle.\n\n\n* sd/branch-copy (2017-06-18) 3 commits\n - branch: add a --copy (-c) option to go with --move (-m)\n - branch: add test for -m renaming multiple config sections\n - config: create a function to format section headers\n\n \"git branch\" learned \"-c/-C\" to create and switch to a new branch\n by copying an existing one.\n\n I personally do not think \"branch --copy master backup\" while on\n \"master\" that switches to \"backup\" is a good UI, and I *will* say\n \"I told you so\" when users complain after we merge this down to\n 'master'.\n\n\n* sb/diff-color-move (2017-06-30) 26 commits\n  (merged to 'next' on 2017-08-19 at a239d031bc)\n + diff: document the new --color-moved setting\n + diff.c: add dimming to moved line detection\n + diff.c: color moved lines differently, plain mode\n + diff.c: color moved lines differently\n + diff.c: buffer all output if asked to\n + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY\n + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP\n + diff.c: convert word diffing to use emit_diff_symbol\n + diff.c: convert show_stats to use emit_diff_symbol\n + diff.c: convert emit_binary_diff_body to use emit_diff_symbol\n + submodule.c: migrate diff output to use emit_diff_symbol\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF\n + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR_{PLUS, MINUS}\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS[_PORCELAIN]\n + diff.c: migrate emit_line_checked to use emit_diff_symbol\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO\n + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER\n + diff.c: introduce emit_diff_symbol\n + diff.c: factor out diff_flush_patch_all_file_pairs\n + diff.c: move line ending check into emit_hunk_header\n + diff.c: readability fix\n + Merge branch 'sb/hashmap-customize-comparison' into sb/diff-color-move\n (this branch is used by jt/diff-color-move-fix.)\n\n \"git diff\" has been taught to optionally paint new lines that are\n the same as deleted lines elsewhere differently from genuinely new\n lines.\n\n Will merge to 'master'.\n\n--------------------------------------------------\n[Discarded]\n\n* nd/prune-in-worktree (2017-04-24) 12 commits\n . rev-list: expose and document --single-worktree\n . revision.c: --reflog add HEAD reflog from all worktrees\n . files-backend: make reflog iterator go through per-worktree reflog\n . revision.c: --all adds HEAD from all worktrees\n . refs: remove dead for_each_*_submodule()\n . revision.c: use refs_for_each*() instead of for_each_*_submodule()\n . refs: add refs_head_ref()\n . refs: move submodule slash stripping code to get_submodule_ref_store\n . refs.c: refactor get_submodule_ref_store(), share common free block\n . revision.c: --indexed-objects add objects from all worktrees\n . revision.c: refactor add_index_objects_to_pending()\n . revision.h: new flag in struct rev_info wrt. worktree-related refs\n\n \"git gc\" and friends when multiple worktrees are used off of a\n single repository did not consider the index and per-worktree refs\n of other worktrees as the root for reachability traversal, making\n objects that are in use only in other worktrees to be subject to\n garbage collection.\n\n\n* jc/apply-with-crlf (2017-08-16) 6 commits\n . apply: clarify read_old_data() is about no-index case\n . apply: localize the CRLF business to read_old_data()\n . apply: only pay attention to CRLF in the preimage\n . apply: remove unused field apply_state.flags\n . apply: file commited with CRLF should roundtrip diff and apply\n + convert: add SAFE_CRLF_KEEP_CRLF\n (this branch is tangled with tb/apply-with-crlf.)\n\n This served as an input to updated tb/apply-with-crlf.\n"},{"id":"327007","messageId":"20170823010056.GB114773@google.com","threadId":"46650","inReplyTo":"xmqq4lsz2x6r.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-08-23T01:00:56Z","receivedAt":"2017-08-23T01:01:04Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 08/22, Junio C Hamano wrote:\n> \n> * bw/submodule-config-cleanup (2017-08-03) 17 commits\n>  - submodule: remove gitmodules_config\n>  - unpack-trees: improve loading of .gitmodules\n>  - submodule-config: lazy-load a repository's .gitmodules file\n>  - submodule-config: move submodule-config functions to submodule-config.c\n>  - submodule-config: remove support for overlaying repository config\n>  - diff: stop allowing diff to have submodules configured in .git/config\n>  - submodule: remove submodule_config callback routine\n>  - unpack-trees: don't respect submodule.update\n>  - submodule: don't rely on overlayed config when setting diffopts\n>  - fetch: don't overlay config with submodule-config\n>  - submodule--helper: don't overlay config in update-clone\n>  - submodule--helper: don't overlay config in remote_submodule_branch\n>  - add, reset: ensure submodules can be added or reset\n>  - submodule: don't use submodule_from_name\n>  - t7411: check configuration parsing errors\n>  - Merge branch 'bc/object-id' into bw/submodule-config-cleanup\n>  - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup\n> \n>  Code clean-up to avoid mixing values read from the .gitmodules file\n>  and values read from the .git/config file.\n> \n>  So, after the recent discussion around submodule.<name>.update (and\n>  its resolution \"use submodule.<name>.active; \"reset --hard\" must\n>  ignore the .update thing\"), this is now good to go, I presume?\n>  Please yell at me that I am clueless if that is not the case ;-)\n\nYep I came to the same conclusion that you did so this should be good to\ngo!\n\n-- \nBrandon Williams\n"},{"id":"327092","messageId":"7D99B245-4D22-4C9C-9C43-C8B8656F8E6D@gmail.com","threadId":"46650","inReplyTo":"xmqq4lsz2x6r.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-08-23T21:38:06Z","receivedAt":"2017-08-23T21:38:15Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 22 Aug 2017, at 21:56, Junio C Hamano <gitster@pobox.com> wrote:\n\n> Here are the topics that have been cooking.  Commits prefixed with\n> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> '+' are in 'next'.  The ones marked with '.' do not appear in any of\n> the integration branches, but I am still holding onto them.\n> \n> The second batch of topics are in.  This cycle is going a bit slower\n> than the previous one (as of mid-week #3 of this cycle, we have\n> about 200 patches on 'master' since v2.14, compared to about 300\n> patches in the cycle towards v2.14 at a similar point in the cycle),\n> but hopefully we can catch up eventually.  \n> \n> I am planning to be offline most of the next week, by the way.\n> \n> You can find the changes described here in the integration branches\n> of the repositories listed at\n> \n>    http://git-blame.blogspot.com/p/git-public-repositories.html\n> \n> --------------------------------------------------\n> [Graduated to \"master\"]\n> \n\nHi Junio,\n\njust in case this got lost: I posted a patch with an improvement to \n2841e8f (\"convert: add \"status=delayed\" to filter process protocol\", \n2017-06-30) which was merged to master in the beginning of 2.15.\n\nhttps://public-inbox.org/git/20170820154720.32259-1-larsxschneider@gmail.com/\n\nThanks,\nLars\n"},{"id":"327149","messageId":"xmqq1so0wyjd.fsf@gitster.mtv.corp.google.com","threadId":"46650","inReplyTo":"7D99B245-4D22-4C9C-9C43-C8B8656F8E6D@gmail.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-08-24T19:33:58Z","receivedAt":"2017-08-24T19:34:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider <larsxschneider@gmail.com> writes:\n\n> On 22 Aug 2017, at 21:56, Junio C Hamano <gitster@pobox.com> wrote:\n>\n>> Here are the topics that have been cooking.  Commits prefixed with\n>> '-' are only in 'pu' (proposed updates) while commits prefixed with\n>> '+' are in 'next'.  The ones marked with '.' do not appear in any of\n>> the integration branches, but I am still holding onto them.\n>> \n>> The second batch of topics are in.  This cycle is going a bit slower\n>> than the previous one (as of mid-week #3 of this cycle, we have\n>> about 200 patches on 'master' since v2.14, compared to about 300\n>> patches in the cycle towards v2.14 at a similar point in the cycle),\n>> but hopefully we can catch up eventually.  \n>> \n>> I am planning to be offline most of the next week, by the way.\n>> \n>> You can find the changes described here in the integration branches\n>> of the repositories listed at\n>> \n>>    http://git-blame.blogspot.com/p/git-public-repositories.html\n>> \n>> --------------------------------------------------\n>> [Graduated to \"master\"]\n>> \n>\n> Hi Junio,\n>\n> just in case this got lost: I posted a patch with an improvement to \n> 2841e8f (\"convert: add \"status=delayed\" to filter process protocol\", \n> 2017-06-30) which was merged to master in the beginning of 2.15.\n>\n> https://public-inbox.org/git/20170820154720.32259-1-larsxschneider@gmail.com/\n\nThanks for pinging, but next time ping the thread itself if it is\nabout something that is not in What's cooking report you are\nresponding to.\n\n"},{"id":"328129","messageId":"alpine.DEB.2.21.1.1709151816390.219280@virtualbox","threadId":"46650","inReplyTo":"xmqq1so0wyjd.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-15T16:18:19Z","receivedAt":"2017-09-15T16:18:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 24 Aug 2017, Junio C Hamano wrote:\n\n> Lars Schneider <larsxschneider@gmail.com> writes:\n> \n> > On 22 Aug 2017, at 21:56, Junio C Hamano <gitster@pobox.com> wrote:\n> >\n> >> Here are the topics that have been cooking.  Commits prefixed with\n> >> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> >> '+' are in 'next'.  The ones marked with '.' do not appear in any of\n> >> the integration branches, but I am still holding onto them.\n> >> \n> >> The second batch of topics are in.  This cycle is going a bit slower\n> >> than the previous one (as of mid-week #3 of this cycle, we have\n> >> about 200 patches on 'master' since v2.14, compared to about 300\n> >> patches in the cycle towards v2.14 at a similar point in the cycle),\n> >> but hopefully we can catch up eventually.  \n> >> \n> >> I am planning to be offline most of the next week, by the way.\n> >> \n> >> You can find the changes described here in the integration branches\n> >> of the repositories listed at\n> >> \n> >>    http://git-blame.blogspot.com/p/git-public-repositories.html\n> >> \n> >> --------------------------------------------------\n> >> [Graduated to \"master\"]\n> >> \n> >\n> > Hi Junio,\n> >\n> > just in case this got lost: I posted a patch with an improvement to \n> > 2841e8f (\"convert: add \"status=delayed\" to filter process protocol\", \n> > 2017-06-30) which was merged to master in the beginning of 2.15.\n> >\n> > https://public-inbox.org/git/20170820154720.32259-1-larsxschneider@gmail.com/\n> \n> Thanks for pinging, but next time ping the thread itself if it is\n> about something that is not in What's cooking report you are\n> responding to.\n\nIf you want *contributors* to ping the thread themselves, how about\n*posting your updates there, too*?\n\nIt does make things inconvenient for contributors if they have to monitor\nthose Whats' cooking emails in addition to the mail threads, you know?\n\nCiao,\nDscho\n"},{"id":"328141","messageId":"xmqqo9qbx14b.fsf@gitster.mtv.corp.google.com","threadId":"46650","inReplyTo":"alpine.DEB.2.21.1.1709151816390.219280@virtualbox","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-15T18:33:56Z","receivedAt":"2017-09-15T18:34:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> If you want *contributors* to ping the thread themselves, how about\n> *posting your updates there, too*?\n\nI do not understand this comment at all.  That is what I and others\nalready and always do by responding to the patches, and when trying\nto see if a topic is still alive, with thread-specific responses and\npings.\n\nIf you are demanding that \"What's cooking\" report to be sent as a\nresponse to all the topics, that will *NOT* going to happen.  It is\nmeant to give a summary of the current state to help contributors\nand reviewers be aware of what is happening across the entire tree\nand not limited to a specific topic.\n"},{"id":"328161","messageId":"alpine.DEB.2.21.1.1709152214100.219280@virtualbox","threadId":"46650","inReplyTo":"xmqqo9qbx14b.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-15T20:15:08Z","receivedAt":"2017-09-15T20:15:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 16 Sep 2017, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > If you want *contributors* to ping the thread themselves, how about\n> > *posting your updates there, too*?\n> \n> I do not understand this comment at all.  That is what I and others\n> already and always do by responding to the patches, and when trying\n> to see if a topic is still alive, with thread-specific responses and\n> pings.\n> \n> If you are demanding that \"What's cooking\" report to be sent as a\n> response to all the topics, that will *NOT* going to happen.  It is\n> meant to give a summary of the current state to help contributors\n> and reviewers be aware of what is happening across the entire tree\n> and not limited to a specific topic.\n\nIf that is the case, you will have to be okay with others responding to\nyour \"What's cooking\" mails instead of the original threads. That's what\nyou are buying into by having these \"What's cooking\" mails that are in no\nusable way connected to the original threads.\n\nCiao,\nDscho\n"},{"id":"328170","messageId":"xmqq377nwtbe.fsf@gitster.mtv.corp.google.com","threadId":"46650","inReplyTo":"alpine.DEB.2.21.1.1709152214100.219280@virtualbox","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-15T21:22:29Z","receivedAt":"2017-09-15T21:22:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> On Sat, 16 Sep 2017, Junio C Hamano wrote:\n>\n>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n>> \n>> > If you want *contributors* to ping the thread themselves, how about\n>> > *posting your updates there, too*?\n>> \n>> I do not understand this comment at all.  That is what I and others\n>> already and always do by responding to the patches, and when trying\n>> to see if a topic is still alive, with thread-specific responses and\n>> pings.\n>> \n>> If you are demanding that \"What's cooking\" report to be sent as a\n>> response to all the topics, that will *NOT* going to happen.  It is\n>> meant to give a summary of the current state to help contributors\n>> and reviewers be aware of what is happening across the entire tree\n>> and not limited to a specific topic.\n>\n> If that is the case, you will have to be okay with others responding to\n> your \"What's cooking\" mails instead of the original threads.\n\nYes and no.  When I say \"This topic waits for a reroll\" and somebody\n(not necessarily the author of the topic) wants to remind me that a\nreroll has already been posted (or worse--I queued the updated\nversion but forgot to update the message), I do appreciate that the\nreply is made to the \"What's cooking\" report.  When there is \"This\ntopic waits for a response to a review comment\" and the responder\nwants to respond to the review comment, the reply should be made in\nresponse to that review comment.  Otherwise, the discussion will\nlose the continuity.\n\nAnd as you alluded to, we may need to see if we can help making it\neasier to do the latter when needed.\n\n> That's what\n> you are buying into by having these \"What's cooking\" mails that are in no\n> usable way connected to the original threads.\n\nFor the above reason, I do not think this is a particularly useful\nstance to take.  Do you have a concrete suggestion to make these\nindividual entries more helpful for people who may want go back to\nthe original thread in doing so?  In-reply-to: or References: fields\nof the \"What's cooking\" report would not help.  I often have the\nmessage IDs that made/helped me make these individual comments in\nthe description; they alone would not react to mouse clicks, though.\n\nHaving said that, I'd expect that individual contributors have past\nmessages pertaining to the smaller numbers of their own topics in\nflight in their mailbox than the project wide \"What's cooking\"\nreport covers, so perhaps an affort to devise such a mechanism may\nresult in an over-engineering waste nobody finds useful.  I dunno.\n\n\n"},{"id":"328296","messageId":"alpine.DEB.2.21.1.1709181637420.219280@virtualbox","threadId":"46650","inReplyTo":"xmqq377nwtbe.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-18T14:41:39Z","receivedAt":"2017-09-18T14:41:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sat, 16 Sep 2017, Junio C Hamano wrote:\n\n> And as you alluded to, we may need to see if we can help making it\n> easier to do the latter when needed.\n\nThat mistakes it for \"Someone Else's Problem\".\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > That's what you are buying into by having these \"What's cooking\" mails\n> > that are in no usable way connected to the original threads.\n> \n> For the above reason, I do not think this is a particularly useful\n> stance to take.\n\nI agree, but this is the process you chose to use.\n\n> Do you have a concrete suggestion to make these individual entries more\n> helpful for people who may want go back to the original thread in doing\n> so?  In-reply-to: or References: fields of the \"What's cooking\" report\n> would not help.  I often have the message IDs that made/helped me make\n> these individual comments in the description; they alone would not react\n> to mouse clicks, though.\n\nOh gawd, not even more stuff piled onto the mail format. Please stop.\n\n> Having said that, I'd expect that individual contributors have past\n> messages pertaining to the smaller numbers of their own topics in flight\n> in their mailbox than the project wide \"What's cooking\" report covers,\n> so perhaps an affort to devise such a mechanism may result in an\n> over-engineering waste nobody finds useful.  I dunno.\n\nI frequently find myself putting off that What's cooking mail because it\nsimply takes too long to study.\n\nIt probably tries to serve too many purposes at the same time, and thereby\nnone.\n\nIn the same vein as \"to a hammer, everything looks like a nail\": when it\ncomes to project management, a dedicated tool will always beat a\ngeneral-purpose mailing list.\n\nCiao,\nDscho\n"},{"id":"328330","messageId":"xmqqbmm7s9ja.fsf@gitster.mtv.corp.google.com","threadId":"46650","inReplyTo":"alpine.DEB.2.21.1.1709181637420.219280@virtualbox","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-19T02:32:25Z","receivedAt":"2017-09-19T02:32:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> Do you have a concrete suggestion to make these individual entries more\n>> helpful for people who may want go back to the original thread in doing\n>> so?  In-reply-to: or References: fields of the \"What's cooking\" report\n>> would not help.  I often have the message IDs that made/helped me make\n>> these individual comments in the description; they alone would not react\n>> to mouse clicks, though.\n>\n> Oh gawd, not even more stuff piled onto the mail format. Please stop.\n> ...\n> It probably tries to serve too many purposes at the same time, and thereby\n> none.\n\nWell, this was started as my attempt to give a public service that\nshows a summary of what is happening in the entire integration tree,\nas there was nothing like that before (and going to github.com and\nlooking at 'pu' branch would not give you an easy overview).  As\nmany people contribute many topics to the project, complaining that\nit talks about too many topics would not get you anywhere.\n\nIf you find \"What's cooking\" report not serving your needs, and if\nno one finds it not serving his or her needs, then I can stop\nsending these out, of course, but I am not getting the impression\nthat we are at that point, at least not yet.\n"},{"id":"328391","messageId":"alpine.DEB.2.21.1.1709191733450.219280@virtualbox","threadId":"46650","inReplyTo":"xmqqbmm7s9ja.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-19T15:43:02Z","receivedAt":"2017-09-19T15:43:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Tue, 19 Sep 2017, Junio C Hamano wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> >> Do you have a concrete suggestion to make these individual entries\n> >> more helpful for people who may want go back to the original thread\n> >> in doing so?  In-reply-to: or References: fields of the \"What's\n> >> cooking\" report would not help.  I often have the message IDs that\n> >> made/helped me make these individual comments in the description;\n> >> they alone would not react to mouse clicks, though.\n> >\n> > Oh gawd, not even more stuff piled onto the mail format. Please stop.\n> > ...\n> > It probably tries to serve too many purposes at the same time, and\n> > thereby none.\n> \n> Well, this was started as my attempt to give a public service that shows\n> a summary of what is happening in the entire integration tree, as there\n> was nothing like that before (and going to github.com and looking at\n> 'pu' branch would not give you an easy overview).  As many people\n> contribute many topics to the project, complaining that it talks about\n> too many topics would not get you anywhere.\n> \n> If you find \"What's cooking\" report not serving your needs, and if no\n> one finds it not serving his or her needs, then I can stop sending these\n> out, of course, but I am not getting the impression that we are at that\n> point, at least not yet.\n\nC'mon, don't *try* to misunderstand me.\n\nOf course there need to be updates as to the state of patch series.\n\nIt's just that mails only go *so* far when you need to connect and\naggregate information. You need the connection between the original patch\nseries, the latest unaddressed reviews, links to the branches, history of\nthe patch series' iterations, and ideally links to the repositories of the\ncontributors with *their* branch names. And then, of course, your verdict\nas to the state of the patch series and your expectation what happens\nnext.\n\nTo relate that, you are using a plain text format that is not well defined\nand not structured, and certainly not machine-readable, for information\nthat is crucial for project management.\n\nWhat you need is a tool to aggregate this information, to help working\nwith it, to manage the project, and to be updated automatically. And to\npublish this information continuously, without costing you extra effort.\n\nI understand that you started before GitHub existed, and before GitHub was\nan option, the script-generated What's cooking mail was the best you could\ndo.\n\nCiao,\nDscho\n"},{"id":"328392","messageId":"20170919160753.GA75068@aiede.mtv.corp.google.com","threadId":"46650","inReplyTo":"alpine.DEB.2.21.1.1709191733450.219280@virtualbox","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-09-19T16:07:53Z","receivedAt":"2017-09-19T16:08:15Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJohannes Schindelin wrote:\n\n> To relate that, you are using a plain text format that is not well defined\n> and not structured, and certainly not machine-readable, for information\n> that is crucial for project management.\n>\n> What you need is a tool to aggregate this information, to help working\n> with it, to manage the project, and to be updated automatically. And to\n> publish this information continuously, without costing you extra effort.\n>\n> I understand that you started before GitHub existed, and before GitHub was\n> an option, the script-generated What's cooking mail was the best you could\n> do.\n\nI think you are subtly (but not directly, for some reason?) advocating\nmoving project management for the Git project to GitHub Issues.\n\nFor what it's worth:\n\n 1. I would be happy to see Git adopt a bug tracker.  As we've\n    discussed on the list before, I suspect the only way that this is\n    going to happen is if some contributors start using a bug tracker\n    and keep up with bugs there, without requiring everyone to use it.\n    That is how the Linux Kernel project started using\n    bugzilla.kernel.org, for example.\n\n 2. GitHub Issues is one of my least favorite bug trackers, for what\n    it's worth.  If some sub-project of Git chooses to use it, then\n    that's great and I won't get in their way.  I'm just providing\n    this single data point that approximately any other tracker\n    (Bugzilla, JIRA, debbugs, patchwork) is something I'd be more\n    likely to use.\n\n 3. This advice might feel hopeless, because if the maintainer is not\n    involved in the initial pilot, then how does the bug tracker get\n    notified when a patch has been accepted?  But fortunately this is\n    a problem other people have solved: e.g. most bug trackers have an\n    API that can be used to automatically notify the bug when a patch\n    with a certain subject line appears on a certain branch.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"328393","messageId":"20170919162035.GB75068@aiede.mtv.corp.google.com","threadId":"46650","inReplyTo":"alpine.DEB.2.21.1.1709191733450.219280@virtualbox","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-09-19T16:20:35Z","receivedAt":"2017-09-19T16:20:45Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Johannes Schindelin wrote:\n\n> What you need is a tool to aggregate this information, to help working\n> with it, to manage the project, and to be updated automatically. And to\n> publish this information continuously, without costing you extra effort.\n>\n> I understand that you started before GitHub existed, and before GitHub was\n> an option, the script-generated What's cooking mail was the best you could\n> do.\n\nOn second reading, I think you're talking about GitHub's code review\n(\"pull request\") feature, not a bug tracker.\n\nThere's been some active work (some that you've been involved in, I\nbelieve) on getting information from a GitHub pull request to the\nmailing list.  One possibility would be to get information to also go\nin the other direction, so people have information about what happened\nto their patch in one place.\n\nI can also see why you are directing your attention to the maintainer\nfor this one, since if the entire project adopts the GitHub Pull\nRequest workflow, then the complexity and other flaws of such a\ntwo-way sync could be avoided.\n\nUnfortunately the maintainer is not the only person you'd need to\nconvince.  You'd also need to convince patch authors and reviewers to\nmove to the new workflow.  There are likely some potential\ncontributors that this would bring in, that would like to get involved\nin the Git project but had been deterred by e.g. the mailing list's\naggressive filtering of any email with an HTML part.  Meanwhile it\nwould also be a large adjustment for existing contributors, so it's\nnot risk free.\n\nI personally like how Bazel[1] handles this.  They have two ways to\ncontribute:\n\n A. People used to GitHub can use a pull request like they are\n    accustomed to.\n\n B. People preferring a more structured code review can use Gerrit.\n\nHaving only two ways to contribute means that the code review\ninformation is still easy to archive and search, just like our mailing\nlist archive.\n\n(Actually, an example I like even more is Akaros[2], which also\nappears to accept patch contributions by email.)\n\nAdding new ways for a contributor to submit a patch would mean that we\ncan experiment with new workflows without getting in the way of people\nusing an existing one.\n\nThoughts?\nJonathan\n\n[1] https://bazel.build/contributing.html\n[2] https://groups.google.com/forum/#!forum/akaros\n"},{"id":"328395","messageId":"905a4adf-a6bd-7484-f81c-0381f7200cfc@suse.de","threadId":"46650","inReplyTo":"alpine.DEB.2.21.1.1709191733450.219280@virtualbox","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Nicolas Morey-Chaisemartin","fromEmail":"nmoreychaisemartin@suse.de","sentAt":"2017-09-19T17:08:07Z","receivedAt":"2017-09-19T17:08:15Z","isPatch":false,"sender":{"key":"nmoreychaisemartin@suse.de","avatar":"https://gravatar.com/avatar/5546322ccb9067f56b6939d9d5c758a40cab5b978b1379fd6ec8ab9b8a6a12b1?d=mp&s=160"},"body":"\n\nLe 19/09/2017 à 17:43, Johannes Schindelin a écrit :\n>\n> C'mon, don't *try* to misunderstand me.\n>\n> Of course there need to be updates as to the state of patch series.\n>\n> It's just that mails only go *so* far when you need to connect and\n> aggregate information. You need the connection between the original patch\n> series, the latest unaddressed reviews, links to the branches, history of\n> the patch series' iterations, and ideally links to the repositories of the\n> contributors with *their* branch names. And then, of course, your verdict\n> as to the state of the patch series and your expectation what happens\n> next.\n>\n> To relate that, you are using a plain text format that is not well defined\n> and not structured, and certainly not machine-readable, for information\n> that is crucial for project management.\n>\n> What you need is a tool to aggregate this information, to help working\n> with it, to manage the project, and to be updated automatically. And to\n> publish this information continuously, without costing you extra effort.\n>\n> I understand that you started before GitHub existed, and before GitHub was\n> an option, the script-generated What's cooking mail was the best you could\n> do.\n>\n> Ciao,\n> Dscho\nHi,\n\nWould something like patchwork fix your need ?\nThey now seems to have a REST API, which means it could probably be pluggeg into\nJunio's scripts and work seemlessly for him (or any other happy ML user) while other people can browse\nthrough the web interface.\n\nI used to work with this one:\nhttp://patches.opendataplane.org/project/lng-odp/list/\nIt is not the best  example as the patch status are pretty much never updated on this one.\n\nBut it would solve most of the points you raised, while keeping fully compatible with the way people actually work (including Junio).\n\nNicolas\n\n\n"},{"id":"329172","messageId":"alpine.DEB.2.21.1.1709291344220.40514@virtualbox","threadId":"46650","inReplyTo":"20170919160753.GA75068@aiede.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-29T11:55:45Z","receivedAt":"2017-09-29T11:55:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jonathan,\n\nOn Tue, 19 Sep 2017, Jonathan Nieder wrote:\n\n> Johannes Schindelin wrote:\n> \n> > To relate that, you are using a plain text format that is not well\n> > defined and not structured, and certainly not machine-readable, for\n> > information that is crucial for project management.\n> >\n> > What you need is a tool to aggregate this information, to help working\n> > with it, to manage the project, and to be updated automatically. And\n> > to publish this information continuously, without costing you extra\n> > effort.\n> >\n> > I understand that you started before GitHub existed, and before GitHub\n> > was an option, the script-generated What's cooking mail was the best\n> > you could do.\n> \n> I think you are subtly (but not directly, for some reason?) advocating\n> moving project management for the Git project to GitHub Issues.\n\nNo, I don't. I know how cumbersome it would be to move tons of people over\nfrom one type of project management to another.\n\nHowever, the current situation is not really tenable, is it? It is tedious\nfor everybody involved. I know Junio defends the status quo, but I cannot\nimagine that he really likes it, as too much is too manual and\nlabor-intensive.\n\nAs I mentioned at the GitMerge (which was a bit pointless, because Junio\nwas not there, not even via Skype), I do not advocate one radical change,\never.\n\n> For what it's worth:\n> \n>  1. I would be happy to see Git adopt a bug tracker.  As we've\n>     discussed on the list before, I suspect the only way that this is\n>     going to happen is if some contributors start using a bug tracker\n>     and keep up with bugs there, without requiring everyone to use it.\n>     That is how the Linux Kernel project started using\n>     bugzilla.kernel.org, for example.\n\nI agree that a bug tracker goes a long way. Personally, I feel Bugzilla is\nway too clunky to use, but I am pampered. However, I could imagine that\nallowing issues to be opened at https://github.com/git/git, and\nencouraging bug submissions there for people who really need to be able to\nfind out very, very quickly what the current state of their bug report is,\nwould go a long way.\n\nOf course, this would require a commitment by Junio and others to allow\ndiscussions to move to that bug tracker from the mailing list. Once that\nwillingness is there, this should be a viable alternative to reporting\nbugs on the mailing list (and have those reports go unanswered because\nthey fell off the radar...).\n\n>  2. GitHub Issues is one of my least favorite bug trackers, for what\n>     it's worth.  If some sub-project of Git chooses to use it, then\n>     that's great and I won't get in their way.  I'm just providing\n>     this single data point that approximately any other tracker\n>     (Bugzilla, JIRA, debbugs, patchwork) is something I'd be more\n>     likely to use.\n\nMy experience with Git for Windows, where I try to live Postel's Law by\naccepting bug reports via mailing list and GitHub issues (and earlier\nGoogle Code, when that was still alive and kicking), and to a certain\nextent even via Twitter: next to nobody likes sending bug reports via mail.\n\nSo to add to your sentiment, I like Bugzilla *less* than GitHub issues,\nand the worst bug tracker is a mailing list.\n\nOr maybe you have written a shell script that can answer the question\n\"which of my reported bugs/submitted patch series are still open?\" for\nthe Git mailing list?\n\n>  3. This advice might feel hopeless, because if the maintainer is not\n>     involved in the initial pilot, then how does the bug tracker get\n>     notified when a patch has been accepted?  But fortunately this is\n>     a problem other people have solved: e.g. most bug trackers have an\n>     API that can be used to automatically notify the bug when a patch\n>     with a certain subject line appears on a certain branch.\n\nYes, I agree. The willingness to see the problem, followed by the\nwillingness to discuss possible solutions, those two need to be the first\nsteps.\n\nCiao,\nDscho\n"},{"id":"329175","messageId":"alpine.DEB.2.21.1.1709291402440.40514@virtualbox","threadId":"46650","inReplyTo":"905a4adf-a6bd-7484-f81c-0381f7200cfc@suse.de","subject":"Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-29T12:15:34Z","receivedAt":"2017-09-29T12:15:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Nicolas,\n\nOn Tue, 19 Sep 2017, Nicolas Morey-Chaisemartin wrote:\n\n> Le 19/09/2017 à 17:43, Johannes Schindelin a écrit :\n> >\n> > C'mon, don't *try* to misunderstand me.\n> >\n> > Of course there need to be updates as to the state of patch series.\n> >\n> > It's just that mails only go *so* far when you need to connect and\n> > aggregate information. You need the connection between the original patch\n> > series, the latest unaddressed reviews, links to the branches, history of\n> > the patch series' iterations, and ideally links to the repositories of the\n> > contributors with *their* branch names. And then, of course, your verdict\n> > as to the state of the patch series and your expectation what happens\n> > next.\n> >\n> > To relate that, you are using a plain text format that is not well defined\n> > and not structured, and certainly not machine-readable, for information\n> > that is crucial for project management.\n> >\n> > What you need is a tool to aggregate this information, to help working\n> > with it, to manage the project, and to be updated automatically. And to\n> > publish this information continuously, without costing you extra effort.\n> >\n> > I understand that you started before GitHub existed, and before GitHub was\n> > an option, the script-generated What's cooking mail was the best you could\n> > do.\n> \n> Would something like patchwork fix your need ?\n\nMaybe. Here is the link, for other interested parties:\nhttp://jk.ozlabs.org/projects/patchwork/ and\nhttps://github.com/getpatchwork/patchwork\n\n> They now seems to have a REST API, which means it could probably be\n> pluggeg into Junio's scripts and work seemlessly for him (or any other\n> happy ML user) while other people can browse through the web interface.\n\nIt seems that patchwork's design calls for the communication still being\nperformed as previously, and just providing a web interface to search a\nlittle more efficiently through the mails containing patch submissions.\n\nGit's mailing list, of course, poses the problem to patchwork that the\nstatus of any patch series is opaque to any automatic system that does not\nspecifically try to connect the What's cooking dot to the patch mail dots.\n\nAlso, a point that came up in a private discussion with another core Git\ncontributor this week: how many reviewers actually even so much as\ntest-compile, let alone look at the code in context? I am fairly certain\nthat none do, *just* because of the shortcomings of the process.\n\nPatchwork would not address this, of course.\n\nIn my ideal world (in which there would be world peace, too, so it would\nbe pretty boring, therefore you should not put much stock into what I am\nsaying next), the direction would be the other way round: the tool should\nnot scrape the mailing list and make the results accessible via web\ninterface. Instead, the tool would let me sidestep the mailing list\naltogether, using it just as a lossy communication medium (and keep the\nlost information accessible in different ways). SubmitGit \"threatened\" to\nallow me to do this: I could open a PR at https://github.com/git/git and\nthen hit a button and off it goes. SubmitGit stops there, though; If it\nwould have continued from there (and did not make the initial step\ndifficult by requiring some registration not everybody is comfortable\nwith), it would have fulfilled my wishes. Alas, it is written in Scala,\nusing a framework I am utterly unfamiliar with, so I could not do anything\nabout it.\n\nCiao,\nDscho"}]}