What's cooking in git.git (Aug 2017, #05; Tue, 22)

What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

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

The second batch of topics are in.  This cycle is going a bit slower
than the previous one (as of mid-week #3 of this cycle, we have
about 200 patches on 'master' since v2.14, compared to about 300
patches in the cycle towards v2.14 at a similar point in the cycle),
but hopefully we can catch up eventually.  

I am planning to be offline most of the next week, by the way.

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

* ab/ref-filter-no-contains (2017-08-07) 1 commit
  (merged to 'next' on 2017-08-18 at 7ec9d3d3a2)
 + tests: don't give unportable ">" to "test" built-in, use -gt

 A test fix.


* bw/clone-recursive-quiet (2017-08-04) 1 commit
  (merged to 'next' on 2017-08-14 at fbd4473ce4)
 + clone: teach recursive clones to respect -q

 "git clone --recurse-submodules --quiet" did not pass the quiet
 option down to submodules.


* bw/grep-recurse-submodules (2017-08-02) 10 commits
  (merged to 'next' on 2017-08-14 at dcfcfc94af)
 + grep: recurse in-process using 'struct repository'
 + submodule: merge repo_read_gitmodules and gitmodules_config
 + submodule: check for unmerged .gitmodules outside of config parsing
 + submodule: check for unstaged .gitmodules outside of config parsing
 + submodule: remove fetch.recursesubmodules from submodule-config parsing
 + submodule: remove submodule.fetchjobs from submodule-config parsing
 + config: add config_from_gitmodules
 + cache.h: add GITMODULES_FILE macro
 + repository: have the_repository use the_index
 + repo_read_index: don't discard the index
 (this branch is used by bw/submodule-config-cleanup.)

 "git grep --recurse-submodules" has been reworked to give a more
 consistent output across submodule boundary (and do its thing
 without having to fork a separate process).


* bw/push-options-recursively-to-submodules (2017-07-20) 1 commit
  (merged to 'next' on 2017-08-14 at 421dc09fd0)
 + submodule--helper: teach push-check to handle HEAD

 "git push --recurse-submodules $there HEAD:$target" was not
 propagated down to the submodules, but now it is.


* jc/perl-git-comment-typofix (2017-08-07) 1 commit
  (merged to 'next' on 2017-08-18 at b2ad043e6a)
 + perl/Git.pm: typofix in a comment

 A comment fix.


* jk/drop-sha1-entry-pos (2017-08-09) 1 commit
  (merged to 'next' on 2017-08-18 at 3a4d9bcf12)
 + sha1_file: drop experimental GIT_USE_LOOKUP search
 (this branch is used by jt/packmigrate.)

 Code clean-up.


* jk/hashcmp-memcmp (2017-08-09) 1 commit
  (merged to 'next' on 2017-08-18 at 27c4aa5520)
 + hashcmp: use memcmp instead of open-coded loop

 Code clean-up.


* ma/parse-maybe-bool (2017-08-07) 6 commits
  (merged to 'next' on 2017-08-18 at ba22bb836c)
 + parse_decoration_style: drop unused argument `var`
 + treewide: deprecate git_config_maybe_bool, use git_parse_maybe_bool
 + config: make git_{config,parse}_maybe_bool equivalent
 + config: introduce git_parse_maybe_bool_text
 + t5334: document that git push --signed=1 does not work
 + Doc/git-{push,send-pack}: correct --sign= to --signed=

 Code clean-up.


* mf/no-dashed-subcommands (2017-08-07) 1 commit
  (merged to 'next' on 2017-08-18 at 05365af2ff)
 + scripts: use "git foo" not "git-foo"

 Code clean-up.


* mh/packed-ref-store (2017-08-17) 32 commits
  (merged to 'next' on 2017-08-18 at 14c58936e1)
 + files-backend: cheapen refname_available check when locking refs
  (merged to 'next' on 2017-08-14 at 987b76d302)
 + packed_ref_store: handle a packed-refs file that is a symlink
 + read_packed_refs(): die if `packed-refs` contains bogus data
 + t3210: add some tests of bogus packed-refs file contents
 + repack_without_refs(): don't lock or unlock the packed refs
 + commit_packed_refs(): remove call to `packed_refs_unlock()`
 + clear_packed_ref_cache(): don't protest if the lock is held
 + packed_refs_unlock(), packed_refs_is_locked(): new functions
 + packed_refs_lock(): report errors via a `struct strbuf *err`
 + packed_refs_lock(): function renamed from lock_packed_refs()
 + commit_packed_refs(): use a staging file separate from the lockfile
 + commit_packed_refs(): report errors rather than dying
 + packed_ref_store: make class into a subclass of `ref_store`
 + packed-backend: new module for handling packed references
 + packed_read_raw_ref(): new function, replacing `resolve_packed_ref()`
 + packed_ref_store: support iteration
 + packed_peel_ref(): new function, extracted from `files_peel_ref()`
 + repack_without_refs(): take a `packed_ref_store *` parameter
 + get_packed_ref(): take a `packed_ref_store *` parameter
 + rollback_packed_refs(): take a `packed_ref_store *` parameter
 + commit_packed_refs(): take a `packed_ref_store *` parameter
 + lock_packed_refs(): take a `packed_ref_store *` parameter
 + add_packed_ref(): take a `packed_ref_store *` parameter
 + get_packed_refs(): take a `packed_ref_store *` parameter
 + get_packed_ref_cache(): take a `packed_ref_store *` parameter
 + validate_packed_ref_cache(): take a `packed_ref_store *` parameter
 + clear_packed_ref_cache(): take a `packed_ref_store *` parameter
 + packed_ref_store: move `packed_refs_lock` member here
 + packed_ref_store: move `packed_refs_path` here
 + packed_ref_store: new struct
 + add_packed_ref(): teach function to overwrite existing refs
 + t1408: add a test of stale packed refs covered by loose refs

 The "ref-store" code reorganization continues.


* pw/am-signoff (2017-08-08) 1 commit
  (merged to 'next' on 2017-08-18 at 7678ed822c)
 + am: fix signoff when other trailers are present

 "git am -s" has been taught that some input may end with a trailer
 block that is not Signed-off-by: and it should refrain from adding
 an extra blank line before adding a new sign-off in such a case.


* pw/sequence-rerere-autoupdate (2017-08-02) 6 commits
  (merged to 'next' on 2017-08-14 at 010cbb0cbe)
 + cherry-pick/revert: reject --rerere-autoupdate when continuing
 + cherry-pick/revert: remember --rerere-autoupdate
 + t3504: use test_commit
 + rebase -i: honor --rerere-autoupdate
 + rebase: honor --rerere-autoupdate
 + am: remember --rerere-autoupdate setting

 Commands like "git rebase" accepted the --rerere-autoupdate option
 from the command line, but did not always use it.  This has been
 fixed.


* rj/add-chmod-error-message (2017-08-09) 1 commit
  (merged to 'next' on 2017-08-18 at ba2afb696a)
 + builtin/add: add detail to a 'cannot chmod' error message

 Message fix.


* rs/apply-lose-prefix-length (2017-08-09) 1 commit
  (merged to 'next' on 2017-08-18 at 6ce0dbb3f0)
 + apply: remove prefix_length member from apply_state

 Code clean-up.


* rs/find-pack-entry-bisection (2017-08-09) 1 commit
  (merged to 'next' on 2017-08-18 at b4130177a9)
 + sha1_file: avoid comparison if no packed hash matches the first byte
 (this branch is used by jt/packmigrate.)

 Code clean-up.


* rs/fsck-obj-leakfix (2017-08-10) 1 commit
  (merged to 'next' on 2017-08-18 at 77e3d111ef)
 + fsck: free buffers on error in fsck_obj()

 Memory leak in an error codepath has been plugged.


* rs/in-obsd-basename-dirname-take-const (2017-08-07) 1 commit
  (merged to 'next' on 2017-08-18 at c739077e3b)
 + test-path-utils: handle const parameter of basename and dirname

 Portability fix.


* rs/merge-microcleanup (2017-08-10) 1 commit
  (merged to 'next' on 2017-08-18 at 79ba7d301d)
 + merge: use skip_prefix()

 Code clean-up.


* rs/obsd-getcwd-workaround (2017-08-07) 1 commit
  (merged to 'next' on 2017-08-18 at adb98cfe0c)
 + t0001: skip test with restrictive permissions if getpwd(3) respects them

 Test portability fix for BSDs.


* rs/strbuf-getwholeline-fix (2017-08-10) 1 commit
  (merged to 'next' on 2017-08-18 at 5f879d8261)
 + strbuf: clear errno before calling getdelim(3)

 A helper function to read a single whole line into strbuf
 mistakenly triggered OOM error at EOF under certain conditions,
 which has been fixed.


* rs/t3700-clean-leftover (2017-08-08) 1 commit
  (merged to 'next' on 2017-08-18 at 12232a8cd3)
 + t3700: fix broken test under !POSIXPERM

 A test fix.


* rs/t4062-obsd (2017-08-09) 1 commit
  (merged to 'next' on 2017-08-18 at 02bff42d86)
 + t4062: use less than 256 repetitions in regex

 Test portability fix.


* rs/unpack-entry-leakfix (2017-08-10) 1 commit
  (merged to 'next' on 2017-08-18 at 1e7d8f54b1)
 + sha1_file: release delta_stack on error in unpack_entry()
 (this branch is used by jt/packmigrate.)

 Memory leak in an error codepath has been plugged.


* rs/win32-syslog-leakfix (2017-08-10) 1 commit
  (merged to 'next' on 2017-08-18 at 011eccb7bd)
 + win32: plug memory leak on realloc() failure in syslog()

 Memory leak in an error codepath has been plugged.


* sb/retire-t1200 (2017-08-10) 1 commit
  (merged to 'next' on 2017-08-18 at d436f9bbce)
 + t1200: remove t1200-tutorial.sh

 A test script that outlived its usefulness has been removed.


* ur/svn-local-zone (2017-08-08) 1 commit
  (merged to 'next' on 2017-08-18 at f222bb6db0)
 + git svn fetch: Create correct commit timestamp when using --localtime

 "git svn" used with "--localtime" option did not compute the tz
 offset for the timestamp in question and instead always used the
 current time, which has been corrected.

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

* jt/packmigrate (2017-08-19) 27 commits
 - pack: move for_each_packed_object()
 - pack: move has_pack_index()
 - pack: move has_sha1_pack()
 - pack: move find_pack_entry() and make it global
 - pack: move find_sha1_pack()
 - pack: move find_pack_entry_one(), is_pack_valid()
 - pack: move check_pack_index_ptr(), nth_packed_object_offset()
 - pack: move nth_packed_object_{sha1,oid}
 - pack: move clear_delta_base_cache(), packed_object_info(), unpack_entry()
 - pack: move unpack_object_header()
 - pack: move get_size_from_delta()
 - pack: move unpack_object_header_buffer()
 - pack: move {,re}prepare_packed_git and approximate_object_count
 - pack: move install_packed_git()
 - pack: move add_packed_git()
 - pack: move unuse_pack()
 - pack: move use_pack()
 - pack: move pack-closing functions
 - pack: move release_pack_memory()
 - pack: move open_pack_index(), parse_pack_index()
 - pack: move pack_report()
 - pack: move static state variables
 - pack: move pack name-related functions
 - Merge branch 'rs/unpack-entry-leakfix' into HEAD
 - Merge branch 'jt/sha1-file-cleanup' into HEAD
 - Merge branch 'jk/drop-sha1-entry-pos' into HEAD
 - Merge branch 'rs/find-pack-entry-bisection' into HEAD
 (this branch uses jt/sha1-file-cleanup.)

 Code movement to make it easier to hack later.

 Rebase this on the master after jt/sha1-file-cleanup graduates and
 merge it to 'next' (if reviewers found this a good change, that
 is).


* jc/cutoff-config (2017-08-19) 2 commits
 - rerere: allow approxidate in gc.rerereResolved/gc.rerereUnresolved
 - rerere: represent time duration in timestamp_t internally

 "[gc] rerereResolved = 5.days" used to be invalid, as the variable
 is defined to take an integer counting the number of days.  It now
 is allowed.

 Needs reroll.
 cf. <xmqqa82t7ov1.fsf@gitster.mtv.corp.google.com>


* jc/simplify-progress (2017-08-19) 1 commit
 - progress: simplify "delayed" progress API

 The API to start showing progress meter after a short delay has
 been simplified.

 Will merge to 'next'.


* jt/stash-tests (2017-08-19) 3 commits
  (merged to 'next' on 2017-08-22 at 0b022697aa)
 + stash: add a test for stashing in a detached state
 + stash: add a test for when apply fails during stash branch
 + stash: add a test for stash create with no files

 Test update to improve coverage for "git stash" operations.

 Will merge to 'master'.


* rs/archive-excluded-directory (2017-08-19) 3 commits
 - archive: don't queue excluded directories
 - archive: factor out helper functions for handling attributes
 - t5001: add tests for export-ignore attributes and exclude pathspecs

 "git archive" did not work well with pathspecs and the
 export-ignore attribute.

 Will merge to 'next'.

 We may want to resurrect the "we don't archive an empty directory"
 bonus patch, but I do not mind merging the above early to 'next'
 and leave it as a separate follow-up enhancement.
 cf. <20170820090629.tumvqwzkromcykjf@sigill.intra.peff.net>


* rs/commit-h-single-parent-cleanup (2017-08-19) 1 commit
  (merged to 'next' on 2017-08-22 at 7db01c4035)
 + commit: remove unused inline function single_parent()

 Code clean-up.

 Will merge to 'master'.


* bc/hash-algo (2017-08-20) 5 commits
 - hash-algo: switch empty tree and blob lookups to use hash abstraction
 - hash-algo: integrate hash algorithm support with repo setup
 - hash-algo: add structure representing hash algorithm
 - setup: expose enumerated repo info
 - Merge branch 'bc/vcs-svn-cleanup' into bc/hash-algo
 (this branch uses bc/vcs-svn-cleanup.)


* bc/vcs-svn-cleanup (2017-08-20) 2 commits
 - vcs-svn: rename repo functions to "svn_repo"
 - vcs-svn: remove unused prototypes
 (this branch is used by bc/hash-algo.)

 Code clean-up.

 Will merge to 'next'.


* jk/doc-the-this (2017-08-20) 1 commit
 - doc: fix typo in sendemail.identity

 Doc clean-up.

 Will merge to 'next'.


* kw/write-index-reduce-alloc (2017-08-21) 3 commits
 - read-cache: avoid allocating every ondisk entry when writing
 - read-cache: fix memory leak in do_write_index
 - perf: add test for writing the index


* mg/killed-merge (2017-08-21) 3 commits
 - merge: save merge state earlier
 - merge: split write_merge_state in two
 - Documentation/git-merge: explain --continue

 Killing "git merge --edit" before the editor returns control left
 the repository in a state with MERGE_MSG but without MERGE_HEAD,
 which incorrectly tells the subsequent "git commit" that there was
 a squash merge in progress.  This has been fixed.

 Looked mostly good with minor nits.
 cf. <36bea69b-010a-9542-ec87-38b00d2bb009@grubix.eu>


* po/object-id (2017-08-20) 6 commits
 - sha1_file: convert index_stream to struct object_id
 - sha1_file: convert hash_sha1_file_literally to struct object_id
 - sha1_file: convert index_fd to struct object_id
 - sha1_file: convert index_path to struct object_id
 - read-cache: convert to struct object_id
 - builtin/hash-object: convert to struct object_id

 Will merge to 'next'.


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

* mg/status-in-progress-info (2017-05-10) 2 commits
 - status --short --inprogress: spell it as --in-progress
 - status: show in-progress info for short status

 "git status" learns an option to report various operations
 (e.g. "merging") that the user is in the middle of.

 cf. <xmqqmvakcdqw.fsf@gitster.mtv.corp.google.com>


* nd/worktree-move (2017-04-20) 6 commits
 - worktree remove: new command
 - worktree move: refuse to move worktrees with submodules
 - worktree move: accept destination as directory
 - worktree move: new command
 - worktree.c: add update_worktree_location()
 - worktree.c: add validate_worktree()

 "git worktree" learned move and remove subcommands.

 Expecting a reroll.
 cf. <20170420101024.7593-1-pclouds@gmail.com>
 cf. <20170421145916.mknekgqzhxffu7di@sigill.intra.peff.net>
 cf. <d0e81b1e-5869-299e-f462-4d43dc997bd1@ramsayjones.plus.com>


* sg/clone-refspec-from-command-line-config (2017-06-16) 2 commits
 - Documentation/clone: document ignored configuration variables
 - clone: respect additional configured fetch refspecs during initial fetch
 (this branch is used by sg/remote-no-string-refspecs.)

 "git clone -c var=val" is a way to set configuration variables in
 the resulting repository, but it is more useful to also make these
 variables take effect while the initial clone is happening,
 e.g. these configuration variables could be fetch refspecs.

 Waiting for a response.
 cf. <20170617112228.vugswym4o4owf6wj@sigill.intra.peff.net>
 cf. <xmqqmv8zhdap.fsf@gitster.mtv.corp.google.com>


* js/rebase-i-final (2017-07-27) 10 commits
 - rebase -i: rearrange fixup/squash lines using the rebase--helper
 - t3415: test fixup with wrapped oneline
 - rebase -i: skip unnecessary picks using the rebase--helper
 - rebase -i: check for missing commits in the rebase--helper
 - t3404: relax rebase.missingCommitsCheck tests
 - rebase -i: also expand/collapse the SHA-1s via the rebase--helper
 - rebase -i: do not invent onelines when expanding/collapsing SHA-1s
 - rebase -i: remove useless indentation
 - rebase -i: generate the script via rebase--helper
 - t3415: verify that an empty instructionFormat is handled as before

 The final batch to "git rebase -i" updates to move more code from
 the shell script to C.

 Expecting a reroll.


* bp/fsmonitor (2017-06-12) 6 commits
 - fsmonitor: add a sample query-fsmonitor hook script for Watchman
 - fsmonitor: add documentation for the fsmonitor extension.
 - fsmonitor: add test cases for fsmonitor extension
 - fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.
 - dir: make lookup_untracked() available outside of dir.c
 - bswap: add 64 bit endianness helper get_be64

 We learned to talk to watchman to speed up "git status".

 Expecting a reroll.
 cf. <bade1166-e646-b05a-f65b-adb8da8ba0a7@gmail.com>

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

* cc/subprocess-handshake-missing-capabilities (2017-08-16) 1 commit
  (merged to 'next' on 2017-08-19 at c512710fda)
 + sub-process: print the cmd when a capability is unsupported

 When handshake with a subprocess filter notices that the process
 asked for an unknown capability, Git did not report what program
 the offending subprocess was running.  This has been corrected.

 Will merge to 'master'.

 We may want a follow-up fix to tighten the error checking, though.


* tb/apply-with-crlf (2017-08-19) 2 commits
  (merged to 'next' on 2017-08-22 at f92bf67061)
 + apply: file commited with CRLF should roundtrip diff and apply
 + convert: add SAFE_CRLF_KEEP_CRLF
 (this branch is tangled with jc/apply-with-crlf.)

 "git apply" that is used as a better "patch -p1" failed to apply a
 taken from a file with CRLF line endings to a file with CRLF line
 endings.  The root cause was because it misused convert_to_git()
 that tried to do "safe-crlf" processing by looking at the index
 entry at the same path, which is a nonsense---in that mode, "apply"
 is not working on the data in (or derived from) the index at all.
 This has been fixed.

 Will merge to 'master'.


* rs/t1002-do-not-use-sum (2017-08-15) 1 commit
  (merged to 'next' on 2017-08-19 at 15b2a5f21b)
 + t1002: stop using sum(1)

 Test simplification.

 Will merge to 'master'.


* sb/sha1-file-cleanup (2017-08-15) 1 commit
  (merged to 'next' on 2017-08-19 at 85898d1e7c)
 + sha1_file: make read_info_alternates static

 Code clean-up.

 Will merge to 'master'.


* as/grep-quiet-no-match-exit-code-fix (2017-08-17) 1 commit
  (merged to 'next' on 2017-08-19 at 362f88fb41)
 + git-grep: correct exit code with --quiet and -L

 "git grep -L" and "git grep --quiet -L" reported different exit
 codes; this has been corrected.

 Will merge to 'master'.


* hv/t5526-andand-chain-fix (2017-08-17) 1 commit
  (merged to 'next' on 2017-08-19 at fa95053653)
 + t5526: fix some broken && chains

 Test fix.

 Will merge to 'master'.


* jc/diff-sane-truncate-no-more (2017-08-17) 1 commit
  (merged to 'next' on 2017-08-19 at 3ba3980eed)
 + diff: retire sane_truncate_fn

 Code clean-up.

 Will merge to 'master'.


* ks/branch-set-upstream (2017-08-17) 3 commits
 - branch: quote branch/ref names to improve readability
 - builtin/branch: stop supporting the "--set-upstream" option
 - t3200: cleanup cruft of a test

 "branch --set-upstream" that has been deprecated in Git 1.8 has
 finally been retired.

 Will merge to 'next'.


* mg/format-ref-doc-fix (2017-08-18) 2 commits
  (merged to 'next' on 2017-08-19 at 6490525c54)
 + Documentation/git-for-each-ref: clarify peeling of tags for --format
 + Documentation: use proper wording for ref format strings

 Doc fix.

 Will merge to 'master'.


* po/read-graft-line (2017-08-18) 4 commits
  (merged to 'next' on 2017-08-22 at 1e3fe0d3a1)
 + commit: rewrite read_graft_line
 + commit: allocate array using object_id size
 + commit: replace the raw buffer with strbuf in read_graft_line
 + sha1_file: fix definition of null_sha1

 Conversion from uchar[20] to struct object_id continues; this is to
 ensure that we do not assume sizeof(struct object_id) is the same
 as the length of SHA-1 hash (or length of longest hash we support).

 Will merge to 'master'.


* sb/submodule-parallel-update (2017-08-17) 1 commit
  (merged to 'next' on 2017-08-19 at c023a834f0)
 + submodule.sh: remove unused variable

 Code clean-up.

 Will merge to 'master'.


* ks/prepare-commit-msg-sample-fix (2017-08-14) 1 commit
  (merged to 'next' on 2017-08-19 at e75c30de64)
 + hook: use correct logical variable

 An "oops" fix to a topic that is already in 'master'.

 Will merge to 'master'.


* mk/diff-delta-uint-may-be-shorter-than-ulong (2017-08-10) 1 commit
 . diff-delta: fix encoding size that would not fit in "unsigned int"

 The machinery to create xdelta used in pack files received the
 sizes of the data in size_t, but lost the higher bits of them by
 storing them in "unsigned int" during the computation, which is
 fixed.

 Dropped, as it was rerolled for review as part of a larger series.
 cf. <1502914591-26215-1-git-send-email-martin@mail.zuhause>


* jk/drop-ancient-curl (2017-08-09) 5 commits
 - http: #error on too-old curl
 - curl: remove ifdef'd code never used with curl >=7.19.4
 - http: drop support for curl < 7.19.4
 - http: drop support for curl < 7.16.0
 - http: drop support for curl < 7.11.1

 Some code in http.c that has bitrot is being removed.

 Will be rerolled after tc/curl-with-backports stabilizes.


* tc/curl-with-backports (2017-08-11) 2 commits
 - http: use a feature check to enable GSSAPI delegation control
 - http: fix handling of missing CURLPROTO_*

 Updates to the HTTP layer we made recently unconditionally used
 features of libCurl without checking the existence of them, causing
 compilation errors, which has been fixed.  Also migrate the code to
 check feature macros, not version numbers, to cope better with
 libCurl that vendor ships with backported features.

 Will merge to 'next'.


* jk/trailers-parse (2017-08-20) 9 commits
  (merged to 'next' on 2017-08-22 at 2d4d937141)
 + doc/interpret-trailers: fix "the this" typo
  (merged to 'next' on 2017-08-19 at faa63f8196)
 + pretty: support normalization options for %(trailers)
 + t4205: refactor %(trailers) tests
 + pretty: move trailer formatting to trailer.c
 + interpret-trailers: add --parse convenience option
 + interpret-trailers: add an option to unfold values
 + interpret-trailers: add an option to show only existing trailers
 + interpret-trailers: add an option to show only the trailers
 + trailer: put process_trailers() options into a struct

 "git interpret-trailers" has been taught a "--parse" and a few
 other options to make it easier for scripts to grab existing
 trailer lines from a commit log message.

 Will merge to 'master'.
 Possible leftover bits are mentioned in
 cf. <20170820094009.z23wclpku35txflg@sigill.intra.peff.net>


* mk/use-size-t-in-zlib (2017-08-10) 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".

 Dropped, as it was rerolled for review as part of a larger series.
 cf. <1502914591-26215-1-git-send-email-martin@mail.zuhause>


* jt/sha1-file-cleanup (2017-08-11) 2 commits
  (merged to 'next' on 2017-08-19 at 93f4c94578)
 + sha1_file: remove read_packed_sha1()
 + sha1_file: set whence in storage-specific info fn
 (this branch is used by jt/packmigrate.)

 Preparatory code clean-up.

 Will merge to 'master'.


* kw/rebase-progress (2017-08-14) 2 commits
  (merged to 'next' on 2017-08-19 at 1958f378dd)
 + rebase: turn on progress option by default for format-patch
 + format-patch: have progress option while generating patches

 "git rebase", especially when it is run by mistake and ends up
 trying to replay many changes, spent long time in silence.  The
 command has been taught to show progress report when it spends
 long time preparing these many changes to replay (which would give
 the user a chance to abort with ^C).

 Will merge to 'master'.


* mk/diff-delta-avoid-large-offset (2017-08-11) 1 commit
 . diff-delta: do not allow delta offset truncation

 The delta format used in the packfile cannot reference data at
 offset larger than what can be expressed in 4-byte, but the
 generator for the data failed to make sure the offset does not
 overflow.  This has been corrected.

 Dropped, as it was rerolled for review as part of a larger series.
 cf. <1502914591-26215-1-git-send-email-martin@mail.zuhause>


* nm/stash-untracked (2017-08-11) 1 commit
  (merged to 'next' on 2017-08-19 at 70990d7eb3)
 + stash: clean untracked files before reset

 "git stash -u" used the contents of the committed version of the
 ".gitignore" file to decide which paths are ignored, even when the
 file has local changes.  The command has been taught to instead use
 the locally modified contents.

 Will merge to 'master'.


* rs/object-id (2017-08-14) 1 commit
  (merged to 'next' on 2017-08-19 at 0f7283cd19)
 + tree-walk: convert fill_tree_descriptor() to object_id

 Conversion from uchar[20] to struct object_id continues.

 Will merge to 'master'.


* ah/doc-empty-string-is-false (2017-08-14) 1 commit
  (merged to 'next' on 2017-08-19 at df47ffeffa)
 + doc: clarify "config --bool" behaviour with empty string

 Doc update.

 Will merge to 'master'.


* jt/diff-color-move-fix (2017-08-16) 3 commits
  (merged to 'next' on 2017-08-19 at 6ae3831c8c)
 + diff: define block by number of alphanumeric chars
 + diff: respect MIN_BLOCK_LENGTH for last block
 + diff: avoid redundantly clearing a flag
 (this branch uses sb/diff-color-move.)

 A handful of bugfixes and an improvement to "diff --color-moved".

 Will merge to 'master'.


* kd/stash-with-bash-4.4 (2017-08-14) 1 commit
  (merged to 'next' on 2017-08-19 at 79b2c4b052)
 + stash: prevent warning about null bytes in input

 bash 4.4 or newer gave a warning on NUL byte in command
 substitution done in "git stash"; this has been squelched.

 Will merge to 'master'.


* kw/commit-keep-index-when-pre-commit-is-not-run (2017-08-16) 1 commit
  (merged to 'next' on 2017-08-19 at 2b5a25e5ae)
 + commit: skip discarding the index if there is no pre-commit hook

 "git commit" used to discard the index and re-read from the filesystem
 just in case the pre-commit hook has updated it in the middle; this
 has been optimized out when we know we do not run the pre-commit hook.

 Will merge to 'master'.


* bw/git-clang-format (2017-08-14) 2 commits
 - Makefile: add style build rule
 - clang-format: outline the git project's coding style

 "make style" runs git-clang-format to help developers by pointing
 out coding style issues.


* lg/merge-signoff (2017-07-25) 1 commit
  (merged to 'next' on 2017-08-19 at cb53d7b026)
 + merge: add a --signoff flag

 "git merge" learned a "--signoff" option to add the Signed-off-by:
 trailer with the committer's name.

 Will merge to 'master'.


* pb/trailers-from-command-line (2017-08-14) 4 commits
  (merged to 'next' on 2017-08-19 at b12342e49e)
 + interpret-trailers: fix documentation typo
 + interpret-trailers: add options for actions
 + trailers: introduce struct new_trailer_item
 + trailers: export action enums and corresponding lookup functions

 "git interpret-trailers" learned to take the trailer specifications
 from the command line that overrides the configured values.

 Will merge to 'master'.


* sb/submodule-recursive-checkout-detach-head (2017-07-28) 2 commits
 - Documentation/checkout: clarify submodule HEADs to be detached
 - recursive submodules: detach HEAD from new state

 "git checkout --recursive" may overwrite and rewind the history of
 the branch that happens to be checked out in submodule
 repositories, which might not be desirable.  Detach the HEAD but
 still allow the recursive checkout to succeed in such a case.

 Undecided.
 This needs justification in a larger picture; it is unclear why
 this is better than rejecting recursive checkout, for example.


* ti/external-sha1dc (2017-08-16) 2 commits
 - sha1dc: allow building with the external sha1dc library
 - sha1dc: build git plumbing code more explicitly

 Platforms that ship with a separate sha1 with collision detection
 library can link to it instead of using the copy we ship as part of
 our source tree.

 Waiting for reviews.
 cf. <20170815120417.31616-1-tiwai@suse.de>


* bw/submodule-config-cleanup (2017-08-03) 17 commits
 - submodule: remove gitmodules_config
 - unpack-trees: improve loading of .gitmodules
 - submodule-config: lazy-load a repository's .gitmodules file
 - submodule-config: move submodule-config functions to submodule-config.c
 - submodule-config: remove support for overlaying repository config
 - diff: stop allowing diff to have submodules configured in .git/config
 - submodule: remove submodule_config callback routine
 - unpack-trees: don't respect submodule.update
 - submodule: don't rely on overlayed config when setting diffopts
 - fetch: don't overlay config with submodule-config
 - submodule--helper: don't overlay config in update-clone
 - submodule--helper: don't overlay config in remote_submodule_branch
 - add, reset: ensure submodules can be added or reset
 - submodule: don't use submodule_from_name
 - t7411: check configuration parsing errors
 - Merge branch 'bc/object-id' into bw/submodule-config-cleanup
 - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup

 Code clean-up to avoid mixing values read from the .gitmodules file
 and values read from the .git/config file.

 So, after the recent discussion around submodule.<name>.update (and
 its resolution "use submodule.<name>.active; "reset --hard" must
 ignore the .update thing"), this is now good to go, I presume?
 Please yell at me that I am clueless if that is not the case ;-)


* jk/check-ref-format-oor-fix (2017-07-14) 1 commit
 - check-ref-format: require a repository for --branch

 Discussion slowly continues...
 cf. <20170717172709.GL93855@aiede.mtv.corp.google.com>
 cf. <20170817102217.3yw7uxnkupdy3lh5@sigill.intra.peff.net>


* rs/sha1-file-micro-optim (2017-07-09) 2 commits
 - SQUASH???
 - sha1_file: add slash once in for_each_file_in_obj_subdir()

 Code cleanup.

 Perhaps drop.
 cf. <f59c8256-716b-9305-2a4f-d4fe49f666ff@web.de>


* jc/allow-lazy-cas (2017-07-06) 1 commit
 - push: disable lazy --force-with-lease by default

 Because "git push --force-with-lease[=<ref>]" that relies on the
 stability of remote-tracking branches is unsafe when something
 fetches into the repository behind user's back, it is now disabled
 by default.  A new configuration variable can be used to enable it
 by users who know what they are doing.  This would pave the way to
 possibly turn `--force` into `--force-with-lease`.

 Will discard.
 Independent from disabling the feature by default, this stirred up
 a discussion to replace the DWIM heuristics with a better one, which
 deserves to be its own topic.
 cf. <alpine.DEB.2.21.1.1707131435220.4193@virtualbox>


* ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits
  (merged to 'next' on 2017-08-14 at 24db08a6e8)
 + pathspec: die on empty strings as pathspec
 + t0027: do not use an empty string as a pathspec element

 The final step to make an empty string as a pathspec element
 illegal.  We started this by first deprecating and warning a
 pathspec that has such an element in 2.11 (Nov 2016).

 Hopefully we can merge this down to the 'master' by the end of the
 year?  A deprecation warning period that is about 1 year does not
 sound too bad.

 Will cook in 'next'.
 As the draft RelNotes says, let's merge this to 'master' after
 this release cycle.


* sd/branch-copy (2017-06-18) 3 commits
 - branch: add a --copy (-c) option to go with --move (-m)
 - branch: add test for -m renaming multiple config sections
 - config: create a function to format section headers

 "git branch" learned "-c/-C" to create and switch to a new branch
 by copying an existing one.

 I personally do not think "branch --copy master backup" while on
 "master" that switches to "backup" is a good UI, and I *will* say
 "I told you so" when users complain after we merge this down to
 'master'.


* sb/diff-color-move (2017-06-30) 26 commits
  (merged to 'next' on 2017-08-19 at a239d031bc)
 + diff: document the new --color-moved setting
 + diff.c: add dimming to moved line detection
 + diff.c: color moved lines differently, plain mode
 + diff.c: color moved lines differently
 + diff.c: buffer all output if asked to
 + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY
 + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP
 + diff.c: convert word diffing to use emit_diff_symbol
 + diff.c: convert show_stats to use emit_diff_symbol
 + diff.c: convert emit_binary_diff_body to use emit_diff_symbol
 + submodule.c: migrate diff output to use emit_diff_symbol
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF
 + diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR_{PLUS, MINUS}
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS[_PORCELAIN]
 + diff.c: migrate emit_line_checked to use emit_diff_symbol
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO
 + diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER
 + diff.c: introduce emit_diff_symbol
 + diff.c: factor out diff_flush_patch_all_file_pairs
 + diff.c: move line ending check into emit_hunk_header
 + diff.c: readability fix
 + Merge branch 'sb/hashmap-customize-comparison' into sb/diff-color-move
 (this branch is used by jt/diff-color-move-fix.)

 "git diff" has been taught to optionally paint new lines that are
 the same as deleted lines elsewhere differently from genuinely new
 lines.

 Will merge to 'master'.

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

* nd/prune-in-worktree (2017-04-24) 12 commits
 . rev-list: expose and document --single-worktree
 . revision.c: --reflog add HEAD reflog from all worktrees
 . files-backend: make reflog iterator go through per-worktree reflog
 . revision.c: --all adds HEAD from all worktrees
 . refs: remove dead for_each_*_submodule()
 . revision.c: use refs_for_each*() instead of for_each_*_submodule()
 . refs: add refs_head_ref()
 . refs: move submodule slash stripping code to get_submodule_ref_store
 . refs.c: refactor get_submodule_ref_store(), share common free block
 . revision.c: --indexed-objects add objects from all worktrees
 . revision.c: refactor add_index_objects_to_pending()
 . revision.h: new flag in struct rev_info wrt. worktree-related refs

 "git gc" and friends when multiple worktrees are used off of a
 single repository did not consider the index and per-worktree refs
 of other worktrees as the root for reachability traversal, making
 objects that are in use only in other worktrees to be subject to
 garbage collection.


* jc/apply-with-crlf (2017-08-16) 6 commits
 . apply: clarify read_old_data() is about no-index case
 . apply: localize the CRLF business to read_old_data()
 . apply: only pay attention to CRLF in the preimage
 . apply: remove unused field apply_state.flags
 . apply: file commited with CRLF should roundtrip diff and apply
 + convert: add SAFE_CRLF_KEEP_CRLF
 (this branch is tangled with tb/apply-with-crlf.)

 This served as an input to updated tb/apply-with-crlf.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Brandon Williams]

On 08/22, Junio C Hamano wrote:
> 
> * bw/submodule-config-cleanup (2017-08-03) 17 commits
>  - submodule: remove gitmodules_config
>  - unpack-trees: improve loading of .gitmodules
>  - submodule-config: lazy-load a repository's .gitmodules file
>  - submodule-config: move submodule-config functions to submodule-config.c
>  - submodule-config: remove support for overlaying repository config
>  - diff: stop allowing diff to have submodules configured in .git/config
>  - submodule: remove submodule_config callback routine
>  - unpack-trees: don't respect submodule.update
>  - submodule: don't rely on overlayed config when setting diffopts
>  - fetch: don't overlay config with submodule-config
>  - submodule--helper: don't overlay config in update-clone
>  - submodule--helper: don't overlay config in remote_submodule_branch
>  - add, reset: ensure submodules can be added or reset
>  - submodule: don't use submodule_from_name
>  - t7411: check configuration parsing errors
>  - Merge branch 'bc/object-id' into bw/submodule-config-cleanup
>  - Merge branch 'bw/grep-recurse-submodules' into bw/submodule-config-cleanup
> 
>  Code clean-up to avoid mixing values read from the .gitmodules file
>  and values read from the .git/config file.
> 
>  So, after the recent discussion around submodule.<name>.update (and
>  its resolution "use submodule.<name>.active; "reset --hard" must
>  ignore the .update thing"), this is now good to go, I presume?
>  Please yell at me that I am clueless if that is not the case ;-)

Yep I came to the same conclusion that you did so this should be good to
go!

-- 
Brandon Williams

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Lars Schneider]

On 22 Aug 2017, at 21:56, Junio C Hamano <gitster@pobox.com> wrote:

> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
> 
> The second batch of topics are in.  This cycle is going a bit slower
> than the previous one (as of mid-week #3 of this cycle, we have
> about 200 patches on 'master' since v2.14, compared to about 300
> patches in the cycle towards v2.14 at a similar point in the cycle),
> but hopefully we can catch up eventually.  
> 
> I am planning to be offline most of the next week, by the way.
> 
> 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"]
> 

Hi Junio,

just in case this got lost: I posted a patch with an improvement to 
2841e8f ("convert: add "status=delayed" to filter process protocol", 
2017-06-30) which was merged to master in the beginning of 2.15.

https://public-inbox.org/git/20170820154720.32259-1-larsxschneider@gmail.com/

Thanks,
Lars

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

Lars Schneider <larsxschneider@gmail.com> writes:

> On 22 Aug 2017, at 21:56, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Here are the topics that have been cooking.  Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'.  The ones marked with '.' do not appear in any of
>> the integration branches, but I am still holding onto them.
>> 
>> The second batch of topics are in.  This cycle is going a bit slower
>> than the previous one (as of mid-week #3 of this cycle, we have
>> about 200 patches on 'master' since v2.14, compared to about 300
>> patches in the cycle towards v2.14 at a similar point in the cycle),
>> but hopefully we can catch up eventually.  
>> 
>> I am planning to be offline most of the next week, by the way.
>> 
>> 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"]
>> 
>
> Hi Junio,
>
> just in case this got lost: I posted a patch with an improvement to 
> 2841e8f ("convert: add "status=delayed" to filter process protocol", 
> 2017-06-30) which was merged to master in the beginning of 2.15.
>
> https://public-inbox.org/git/20170820154720.32259-1-larsxschneider@gmail.com/

Thanks for pinging, but next time ping the thread itself if it is
about something that is not in What's cooking report you are
responding to.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Thu, 24 Aug 2017, Junio C Hamano wrote:

> Lars Schneider <larsxschneider@gmail.com> writes:
> 
> > On 22 Aug 2017, at 21:56, Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> Here are the topics that have been cooking.  Commits prefixed with
> >> '-' are only in 'pu' (proposed updates) while commits prefixed with
> >> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> >> the integration branches, but I am still holding onto them.
> >> 
> >> The second batch of topics are in.  This cycle is going a bit slower
> >> than the previous one (as of mid-week #3 of this cycle, we have
> >> about 200 patches on 'master' since v2.14, compared to about 300
> >> patches in the cycle towards v2.14 at a similar point in the cycle),
> >> but hopefully we can catch up eventually.  
> >> 
> >> I am planning to be offline most of the next week, by the way.
> >> 
> >> 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"]
> >> 
> >
> > Hi Junio,
> >
> > just in case this got lost: I posted a patch with an improvement to 
> > 2841e8f ("convert: add "status=delayed" to filter process protocol", 
> > 2017-06-30) which was merged to master in the beginning of 2.15.
> >
> > https://public-inbox.org/git/20170820154720.32259-1-larsxschneider@gmail.com/
> 
> Thanks for pinging, but next time ping the thread itself if it is
> about something that is not in What's cooking report you are
> responding to.

If you want *contributors* to ping the thread themselves, how about
*posting your updates there, too*?

It does make things inconvenient for contributors if they have to monitor
those Whats' cooking emails in addition to the mail threads, you know?

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

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

> If you want *contributors* to ping the thread themselves, how about
> *posting your updates there, too*?

I do not understand this comment at all.  That is what I and others
already and always do by responding to the patches, and when trying
to see if a topic is still alive, with thread-specific responses and
pings.

If you are demanding that "What's cooking" report to be sent as a
response to all the topics, that will *NOT* going to happen.  It is
meant to give a summary of the current state to help contributors
and reviewers be aware of what is happening across the entire tree
and not limited to a specific topic.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Sat, 16 Sep 2017, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > If you want *contributors* to ping the thread themselves, how about
> > *posting your updates there, too*?
> 
> I do not understand this comment at all.  That is what I and others
> already and always do by responding to the patches, and when trying
> to see if a topic is still alive, with thread-specific responses and
> pings.
> 
> If you are demanding that "What's cooking" report to be sent as a
> response to all the topics, that will *NOT* going to happen.  It is
> meant to give a summary of the current state to help contributors
> and reviewers be aware of what is happening across the entire tree
> and not limited to a specific topic.

If that is the case, you will have to be okay with others responding to
your "What's cooking" mails instead of the original threads. That's what
you are buying into by having these "What's cooking" mails that are in no
usable way connected to the original threads.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

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

> On Sat, 16 Sep 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > If you want *contributors* to ping the thread themselves, how about
>> > *posting your updates there, too*?
>> 
>> I do not understand this comment at all.  That is what I and others
>> already and always do by responding to the patches, and when trying
>> to see if a topic is still alive, with thread-specific responses and
>> pings.
>> 
>> If you are demanding that "What's cooking" report to be sent as a
>> response to all the topics, that will *NOT* going to happen.  It is
>> meant to give a summary of the current state to help contributors
>> and reviewers be aware of what is happening across the entire tree
>> and not limited to a specific topic.
>
> If that is the case, you will have to be okay with others responding to
> your "What's cooking" mails instead of the original threads.

Yes and no.  When I say "This topic waits for a reroll" and somebody
(not necessarily the author of the topic) wants to remind me that a
reroll has already been posted (or worse--I queued the updated
version but forgot to update the message), I do appreciate that the
reply is made to the "What's cooking" report.  When there is "This
topic waits for a response to a review comment" and the responder
wants to respond to the review comment, the reply should be made in
response to that review comment.  Otherwise, the discussion will
lose the continuity.

And as you alluded to, we may need to see if we can help making it
easier to do the latter when needed.

> That's what
> you are buying into by having these "What's cooking" mails that are in no
> usable way connected to the original threads.

For the above reason, I do not think this is a particularly useful
stance to take.  Do you have a concrete suggestion to make these
individual entries more helpful for people who may want go back to
the original thread in doing so?  In-reply-to: or References: fields
of the "What's cooking" report would not help.  I often have the
message IDs that made/helped me make these individual comments in
the description; they alone would not react to mouse clicks, though.

Having said that, I'd expect that individual contributors have past
messages pertaining to the smaller numbers of their own topics in
flight in their mailbox than the project wide "What's cooking"
report covers, so perhaps an affort to devise such a mechanism may
result in an over-engineering waste nobody finds useful.  I dunno.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Sat, 16 Sep 2017, Junio C Hamano wrote:

> And as you alluded to, we may need to see if we can help making it
> easier to do the latter when needed.

That mistakes it for "Someone Else's Problem".

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > That's what you are buying into by having these "What's cooking" mails
> > that are in no usable way connected to the original threads.
> 
> For the above reason, I do not think this is a particularly useful
> stance to take.

I agree, but this is the process you chose to use.

> Do you have a concrete suggestion to make these individual entries more
> helpful for people who may want go back to the original thread in doing
> so?  In-reply-to: or References: fields of the "What's cooking" report
> would not help.  I often have the message IDs that made/helped me make
> these individual comments in the description; they alone would not react
> to mouse clicks, though.

Oh gawd, not even more stuff piled onto the mail format. Please stop.

> Having said that, I'd expect that individual contributors have past
> messages pertaining to the smaller numbers of their own topics in flight
> in their mailbox than the project wide "What's cooking" report covers,
> so perhaps an affort to devise such a mechanism may result in an
> over-engineering waste nobody finds useful.  I dunno.

I frequently find myself putting off that What's cooking mail because it
simply takes too long to study.

It probably tries to serve too many purposes at the same time, and thereby
none.

In the same vein as "to a hammer, everything looks like a nail": when it
comes to project management, a dedicated tool will always beat a
general-purpose mailing list.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Junio C Hamano]

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

>> Do you have a concrete suggestion to make these individual entries more
>> helpful for people who may want go back to the original thread in doing
>> so?  In-reply-to: or References: fields of the "What's cooking" report
>> would not help.  I often have the message IDs that made/helped me make
>> these individual comments in the description; they alone would not react
>> to mouse clicks, though.
>
> Oh gawd, not even more stuff piled onto the mail format. Please stop.
> ...
> It probably tries to serve too many purposes at the same time, and thereby
> none.

Well, this was started as my attempt to give a public service that
shows a summary of what is happening in the entire integration tree,
as there was nothing like that before (and going to github.com and
looking at 'pu' branch would not give you an easy overview).  As
many people contribute many topics to the project, complaining that
it talks about too many topics would not get you anywhere.

If you find "What's cooking" report not serving your needs, and if
no one finds it not serving his or her needs, then I can stop
sending these out, of course, but I am not getting the impression
that we are at that point, at least not yet.

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Junio,

On Tue, 19 Sep 2017, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> Do you have a concrete suggestion to make these individual entries
> >> more helpful for people who may want go back to the original thread
> >> in doing so?  In-reply-to: or References: fields of the "What's
> >> cooking" report would not help.  I often have the message IDs that
> >> made/helped me make these individual comments in the description;
> >> they alone would not react to mouse clicks, though.
> >
> > Oh gawd, not even more stuff piled onto the mail format. Please stop.
> > ...
> > It probably tries to serve too many purposes at the same time, and
> > thereby none.
> 
> Well, this was started as my attempt to give a public service that shows
> a summary of what is happening in the entire integration tree, as there
> was nothing like that before (and going to github.com and looking at
> 'pu' branch would not give you an easy overview).  As many people
> contribute many topics to the project, complaining that it talks about
> too many topics would not get you anywhere.
> 
> If you find "What's cooking" report not serving your needs, and if no
> one finds it not serving his or her needs, then I can stop sending these
> out, of course, but I am not getting the impression that we are at that
> point, at least not yet.

C'mon, don't *try* to misunderstand me.

Of course there need to be updates as to the state of patch series.

It's just that mails only go *so* far when you need to connect and
aggregate information. You need the connection between the original patch
series, the latest unaddressed reviews, links to the branches, history of
the patch series' iterations, and ideally links to the repositories of the
contributors with *their* branch names. And then, of course, your verdict
as to the state of the patch series and your expectation what happens
next.

To relate that, you are using a plain text format that is not well defined
and not structured, and certainly not machine-readable, for information
that is crucial for project management.

What you need is a tool to aggregate this information, to help working
with it, to manage the project, and to be updated automatically. And to
publish this information continuously, without costing you extra effort.

I understand that you started before GitHub existed, and before GitHub was
an option, the script-generated What's cooking mail was the best you could
do.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Jonathan Nieder]

Hi,

Johannes Schindelin wrote:

> To relate that, you are using a plain text format that is not well defined
> and not structured, and certainly not machine-readable, for information
> that is crucial for project management.
>
> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.

I think you are subtly (but not directly, for some reason?) advocating
moving project management for the Git project to GitHub Issues.

For what it's worth:

 1. I would be happy to see Git adopt a bug tracker.  As we've
    discussed on the list before, I suspect the only way that this is
    going to happen is if some contributors start using a bug tracker
    and keep up with bugs there, without requiring everyone to use it.
    That is how the Linux Kernel project started using
    bugzilla.kernel.org, for example.

 2. GitHub Issues is one of my least favorite bug trackers, for what
    it's worth.  If some sub-project of Git chooses to use it, then
    that's great and I won't get in their way.  I'm just providing
    this single data point that approximately any other tracker
    (Bugzilla, JIRA, debbugs, patchwork) is something I'd be more
    likely to use.

 3. This advice might feel hopeless, because if the maintainer is not
    involved in the initial pilot, then how does the bug tracker get
    notified when a patch has been accepted?  But fortunately this is
    a problem other people have solved: e.g. most bug trackers have an
    API that can be used to automatically notify the bug when a patch
    with a certain subject line appears on a certain branch.

Thanks and hope that helps,
Jonathan

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Jonathan Nieder]

Johannes Schindelin wrote:

> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.

On second reading, I think you're talking about GitHub's code review
("pull request") feature, not a bug tracker.

There's been some active work (some that you've been involved in, I
believe) on getting information from a GitHub pull request to the
mailing list.  One possibility would be to get information to also go
in the other direction, so people have information about what happened
to their patch in one place.

I can also see why you are directing your attention to the maintainer
for this one, since if the entire project adopts the GitHub Pull
Request workflow, then the complexity and other flaws of such a
two-way sync could be avoided.

Unfortunately the maintainer is not the only person you'd need to
convince.  You'd also need to convince patch authors and reviewers to
move to the new workflow.  There are likely some potential
contributors that this would bring in, that would like to get involved
in the Git project but had been deterred by e.g. the mailing list's
aggressive filtering of any email with an HTML part.  Meanwhile it
would also be a large adjustment for existing contributors, so it's
not risk free.

I personally like how Bazel[1] handles this.  They have two ways to
contribute:

 A. People used to GitHub can use a pull request like they are
    accustomed to.

 B. People preferring a more structured code review can use Gerrit.

Having only two ways to contribute means that the code review
information is still easy to archive and search, just like our mailing
list archive.

(Actually, an example I like even more is Akaros[2], which also
appears to accept patch contributions by email.)

Adding new ways for a contributor to submit a patch would mean that we
can experiment with new workflows without getting in the way of people
using an existing one.

Thoughts?
Jonathan

[1] https://bazel.build/contributing.html
[2] https://groups.google.com/forum/#!forum/akaros

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Nicolas Morey-Chaisemartin]

Le 19/09/2017 à 17:43, Johannes Schindelin a écrit :
>
> C'mon, don't *try* to misunderstand me.
>
> Of course there need to be updates as to the state of patch series.
>
> It's just that mails only go *so* far when you need to connect and
> aggregate information. You need the connection between the original patch
> series, the latest unaddressed reviews, links to the branches, history of
> the patch series' iterations, and ideally links to the repositories of the
> contributors with *their* branch names. And then, of course, your verdict
> as to the state of the patch series and your expectation what happens
> next.
>
> To relate that, you are using a plain text format that is not well defined
> and not structured, and certainly not machine-readable, for information
> that is crucial for project management.
>
> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.
>
> Ciao,
> Dscho
Hi,

Would something like patchwork fix your need ?
They now seems to have a REST API, which means it could probably be pluggeg into
Junio's scripts and work seemlessly for him (or any other happy ML user) while other people can browse
through the web interface.

I used to work with this one:
http://patches.opendataplane.org/project/lng-odp/list/
It is not the best  example as the patch status are pretty much never updated on this one.

But it would solve most of the points you raised, while keeping fully compatible with the way people actually work (including Junio).

Nicolas

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

Hi Jonathan,

On Tue, 19 Sep 2017, Jonathan Nieder wrote:

> Johannes Schindelin wrote:
> 
> > To relate that, you are using a plain text format that is not well
> > defined and not structured, and certainly not machine-readable, for
> > information that is crucial for project management.
> >
> > What you need is a tool to aggregate this information, to help working
> > with it, to manage the project, and to be updated automatically. And
> > to publish this information continuously, without costing you extra
> > effort.
> >
> > I understand that you started before GitHub existed, and before GitHub
> > was an option, the script-generated What's cooking mail was the best
> > you could do.
> 
> I think you are subtly (but not directly, for some reason?) advocating
> moving project management for the Git project to GitHub Issues.

No, I don't. I know how cumbersome it would be to move tons of people over
from one type of project management to another.

However, the current situation is not really tenable, is it? It is tedious
for everybody involved. I know Junio defends the status quo, but I cannot
imagine that he really likes it, as too much is too manual and
labor-intensive.

As I mentioned at the GitMerge (which was a bit pointless, because Junio
was not there, not even via Skype), I do not advocate one radical change,
ever.

> For what it's worth:
> 
>  1. I would be happy to see Git adopt a bug tracker.  As we've
>     discussed on the list before, I suspect the only way that this is
>     going to happen is if some contributors start using a bug tracker
>     and keep up with bugs there, without requiring everyone to use it.
>     That is how the Linux Kernel project started using
>     bugzilla.kernel.org, for example.

I agree that a bug tracker goes a long way. Personally, I feel Bugzilla is
way too clunky to use, but I am pampered. However, I could imagine that
allowing issues to be opened at https://github.com/git/git, and
encouraging bug submissions there for people who really need to be able to
find out very, very quickly what the current state of their bug report is,
would go a long way.

Of course, this would require a commitment by Junio and others to allow
discussions to move to that bug tracker from the mailing list. Once that
willingness is there, this should be a viable alternative to reporting
bugs on the mailing list (and have those reports go unanswered because
they fell off the radar...).

>  2. GitHub Issues is one of my least favorite bug trackers, for what
>     it's worth.  If some sub-project of Git chooses to use it, then
>     that's great and I won't get in their way.  I'm just providing
>     this single data point that approximately any other tracker
>     (Bugzilla, JIRA, debbugs, patchwork) is something I'd be more
>     likely to use.

My experience with Git for Windows, where I try to live Postel's Law by
accepting bug reports via mailing list and GitHub issues (and earlier
Google Code, when that was still alive and kicking), and to a certain
extent even via Twitter: next to nobody likes sending bug reports via mail.

So to add to your sentiment, I like Bugzilla *less* than GitHub issues,
and the worst bug tracker is a mailing list.

Or maybe you have written a shell script that can answer the question
"which of my reported bugs/submitted patch series are still open?" for
the Git mailing list?

>  3. This advice might feel hopeless, because if the maintainer is not
>     involved in the initial pilot, then how does the bug tracker get
>     notified when a patch has been accepted?  But fortunately this is
>     a problem other people have solved: e.g. most bug trackers have an
>     API that can be used to automatically notify the bug when a patch
>     with a certain subject line appears on a certain branch.

Yes, I agree. The willingness to see the problem, followed by the
willingness to discuss possible solutions, those two need to be the first
steps.

Ciao,
Dscho

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

[Johannes Schindelin]

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

Hi Nicolas,

On Tue, 19 Sep 2017, Nicolas Morey-Chaisemartin wrote:

> Le 19/09/2017 à 17:43, Johannes Schindelin a écrit :
> >
> > C'mon, don't *try* to misunderstand me.
> >
> > Of course there need to be updates as to the state of patch series.
> >
> > It's just that mails only go *so* far when you need to connect and
> > aggregate information. You need the connection between the original patch
> > series, the latest unaddressed reviews, links to the branches, history of
> > the patch series' iterations, and ideally links to the repositories of the
> > contributors with *their* branch names. And then, of course, your verdict
> > as to the state of the patch series and your expectation what happens
> > next.
> >
> > To relate that, you are using a plain text format that is not well defined
> > and not structured, and certainly not machine-readable, for information
> > that is crucial for project management.
> >
> > What you need is a tool to aggregate this information, to help working
> > with it, to manage the project, and to be updated automatically. And to
> > publish this information continuously, without costing you extra effort.
> >
> > I understand that you started before GitHub existed, and before GitHub was
> > an option, the script-generated What's cooking mail was the best you could
> > do.
> 
> Would something like patchwork fix your need ?

Maybe. Here is the link, for other interested parties:
http://jk.ozlabs.org/projects/patchwork/ and
https://github.com/getpatchwork/patchwork

> They now seems to have a REST API, which means it could probably be
> pluggeg into Junio's scripts and work seemlessly for him (or any other
> happy ML user) while other people can browse through the web interface.

It seems that patchwork's design calls for the communication still being
performed as previously, and just providing a web interface to search a
little more efficiently through the mails containing patch submissions.

Git's mailing list, of course, poses the problem to patchwork that the
status of any patch series is opaque to any automatic system that does not
specifically try to connect the What's cooking dot to the patch mail dots.

Also, a point that came up in a private discussion with another core Git
contributor this week: how many reviewers actually even so much as
test-compile, let alone look at the code in context? I am fairly certain
that none do, *just* because of the shortcomings of the process.

Patchwork would not address this, of course.

In my ideal world (in which there would be world peace, too, so it would
be pretty boring, therefore you should not put much stock into what I am
saying next), the direction would be the other way round: the tool should
not scrape the mailing list and make the results accessible via web
interface. Instead, the tool would let me sidestep the mailing list
altogether, using it just as a lossy communication medium (and keep the
lost information accessible in different ways). SubmitGit "threatened" to
allow me to do this: I could open a PR at https://github.com/git/git and
then hit a button and off it goes. SubmitGit stops there, though; If it
would have continued from there (and did not make the initial step
difficult by requiring some registration not everybody is comfortable
with), it would have fulfilled my wishes. Alas, it is written in Scala,
using a framework I am utterly unfamiliar with, so I could not do anything
about it.

Ciao,
Dscho