{"thread":{"id":"45752","subject":"What's cooking in git.git (Apr 2017, #04; Wed, 19)","startedAt":"2017-04-20T05:37:33Z","lastAt":"2017-04-25T18:27:11Z","messageCount":29,"participants":["Junio C Hamano","Duy Nguyen","Johannes Schindelin","Lars Schneider","Jeff King","Brandon Williams","Christian Couder","Johannes Sixt","Ævar Arnfjörð Bjarmason","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"317309","messageId":"xmqq4lxjabce.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":null,"subject":"What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-20T05:37:21Z","receivedAt":"2017-04-20T05:37:33Z","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\nAn early preview for the upcoming 2.13 release has been tagged,\nalmost a full day earlier than I planned.\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/grep-plug-pathspec-leak (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-18 at d8f00b5e44)\n + grep: plug a trivial memory leak\n\n Call clear_pathspec() to release resources immediately before the\n cmd_grep() function returns.\n\n\n* ah/diff-files-ours-theirs-doc (2017-04-13) 1 commit\n (merged to 'next' on 2017-04-18 at a4f80f0c3f)\n + diff-files: document --ours etc.\n\n The diff options \"--ours\", \"--theirs\" exist for quite some time.\n But so far they were not documented. Now they are.\n\n\n* bc/object-id (2017-03-31) 20 commits\n (merged to 'next' on 2017-04-16 at b16f1899dd)\n + Documentation: update and rename api-sha1-array.txt\n + Rename sha1_array to oid_array\n + Convert sha1_array_for_each_unique and for_each_abbrev to object_id\n + Convert sha1_array_lookup to take struct object_id\n + Convert remaining callers of sha1_array_lookup to object_id\n + Make sha1_array_append take a struct object_id *\n + sha1-array: convert internal storage for struct sha1_array to object_id\n + builtin/pull: convert to struct object_id\n + submodule: convert check_for_new_submodule_commits to object_id\n + sha1_name: convert disambiguate_hint_fn to take object_id\n + sha1_name: convert struct disambiguate_state to object_id\n + test-sha1-array: convert most code to struct object_id\n + parse-options-cb: convert sha1_array_append caller to struct object_id\n + fsck: convert init_skiplist to struct object_id\n + builtin/receive-pack: convert portions to struct object_id\n + builtin/pull: convert portions to struct object_id\n + builtin/diff: convert to struct object_id\n + Convert GIT_SHA1_RAWSZ used for allocation to GIT_MAX_RAWSZ\n + Convert GIT_SHA1_HEXSZ used for allocation to GIT_MAX_HEXSZ\n + Define new hash-size constants for allocating memory\n\n Conversion from unsigned char [40] to struct object_id continues.\n\n\n* bw/attr-pathspec (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-18 at 2644ca1269)\n + pathspec: fix segfault in clear_pathspec\n\n Hotfix for a topic already in 'master'.\n\n\n* bw/push-options-recursively-to-submodules (2017-04-11) 5 commits\n (merged to 'next' on 2017-04-16 at d4d657724b)\n + push: propagate remote and refspec with --recurse-submodules\n + submodule--helper: add push-check subcommand\n + remote: expose parse_push_refspec function\n + push: propagate push-options with --recurse-submodules\n + push: unmark a local variable as static\n\n \"git push --recurse-submodules --push-option=\" learned to\n propagate the push option recursively down to pushes in submodules.\n\n\n* bw/submodule-is-active (2017-04-13) 1 commit\n (merged to 'next' on 2017-04-18 at 25b05ec29e)\n + submodule--helper: fix typo in is_active error message\n\n Error message fix.\n\n\n* dt/gc-ignore-old-gc-logs (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-18 at caadf4ff66)\n + t6500: wait for detached auto gc at the end of the test script\n\n Hotfix for a topic already in 'master'.\n\n\n* jh/memihash-opt (2017-04-18) 4 commits\n (merged to 'next' on 2017-04-18 at 6555be6bab)\n + p0004: make perf test executable\n (merged to 'next' on 2017-04-15 at 6bfc58e19a)\n + t3008: skip lazy-init test on a single-core box\n + test-online-cpus: helper to return cpu count\n (merged to 'next' on 2017-04-11 at ec5a6f2818)\n + name-hash: fix buffer overrun\n\n Hotfix for a topic that is already in 'master'.\n\n\n* jk/no-looking-at-dotgit-outside-repo (2017-04-16) 2 commits\n (merged to 'next' on 2017-04-18 at 68260787ad)\n + test-read-cache: setup git dir\n + has_sha1_file: don't bother if we are not in a repository\n\n Clean up fallouts from recent tightening of the set-up sequence,\n where Git barfs when repository information is accessed without\n first ensuring that it was started in a repository.\n\n\n* ld/p4-current-branch-fix (2017-04-16) 3 commits\n (merged to 'next' on 2017-04-18 at 9e74a2609e)\n + git-p4: don't use name-rev to get current branch\n + git-p4: add read_pipe_text() internal function\n + git-p4: add failing test for name-rev rather than symbolic-ref\n\n \"git p4\" used \"name-rev HEAD\" when it wants to learn what branch is\n checked out; it should use \"symbolic-ref HEAD\".\n\n\n* lt/mailinfo-in-body-header-continuation (2017-04-11) 1 commit\n (merged to 'next' on 2017-04-16 at b2f51f0780)\n + mailinfo: fix in-body header continuations\n\n If a patch e-mail had its first paragraph after an in-body header\n indented (even after a blank line after the in-body header line),\n the indented line was mistook as a continuation of the in-body\n header. This has been fixed.\n\n\n* nd/files-backend-git-dir (2017-04-14) 28 commits\n (merged to 'next' on 2017-04-18 at 79292aac69)\n + refs.h: add a note about sorting order of for_each_ref_*\n + t1406: new tests for submodule ref store\n + t1405: some basic tests on main ref store\n + t/helper: add test-ref-store to test ref-store functions\n + refs: delete pack_refs() in favor of refs_pack_refs()\n + files-backend: avoid ref api targeting main ref store\n + refs: new transaction related ref-store api\n + refs: add new ref-store api\n + refs: rename get_ref_store() to get_submodule_ref_store() and make it public\n + files-backend: replace submodule_allowed check in files_downcast()\n + refs: move submodule code out of files-backend.c\n + path.c: move some code out of strbuf_git_path_submodule()\n + refs.c: make get_main_ref_store() public and use it\n + refs.c: kill register_ref_store(), add register_submodule_ref_store()\n + refs.c: flatten get_ref_store() a bit\n + refs: rename lookup_ref_store() to lookup_submodule_ref_store()\n + refs.c: introduce get_main_ref_store()\n + files-backend: remove the use of git_path()\n + files-backend: add and use files_ref_path()\n + files-backend: add and use files_reflog_path()\n + files-backend: move \"logs/\" out of TMP_RENAMED_LOG\n + files-backend: convert git_path() to strbuf_git_path()\n + files-backend: make sure files_rename_ref() always reach the end\n + files-backend: add and use files_packed_refs_path()\n + files-backend: delete dead code in files_init_db()\n + files-backend.c: delete dead code in files_ref_iterator_begin()\n + files-backend: make files_log_ref_write() static\n + refs.h: add forward declaration for structs used in this file\n (this branch is used by mh/separate-ref-cache, nd/prune-in-worktree and nd/worktree-kill-parse-ref.)\n\n The \"submodule\" specific field in the ref_store structure is\n replaced with a more generic \"gitdir\" that can later be used also\n when dealing with ref_store that represents the set of refs visible\n from the other worktrees.\n\n\n* sb/submodule-rm-absorb (2017-04-13) 1 commit\n (merged to 'next' on 2017-04-18 at 179081f848)\n + submodule.c: add missing ' in error messages\n\n Error message fix.\n\n\n* sb/submodule-short-status (2017-03-29) 7 commits\n (merged to 'next' on 2017-04-16 at 24e18f4a4a)\n + submodule.c: correctly handle nested submodules in is_submodule_modified\n + short status: improve reporting for submodule changes\n + submodule.c: stricter checking for submodules in is_submodule_modified\n + submodule.c: port is_submodule_modified to use porcelain 2\n + submodule.c: convert is_submodule_modified to use strbuf_getwholeline\n + submodule.c: factor out early loop termination in is_submodule_modified\n + submodule.c: use argv_array in is_submodule_modified\n\n The output from \"git status --short\" has been extended to show\n various kinds of dirtyness in submodules differently; instead of to\n \"M\" for modified, 'm' and '?' can be shown to signal changes only\n to the working tree of the submodule but not the commit that is\n checked out.\n\n\n* sf/putty-w-args (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-18 at cbf042088c)\n + connect.c: handle errors from split_cmdline\n\n Hotfix for a topic already in 'master'.\n\n\n* va/i18n-perl-scripts (2017-04-13) 1 commit\n (merged to 'next' on 2017-04-18 at 89f1c77091)\n + git-add--interactive.perl: add missing dot in a message\n\n Message fix.\n\n\n* vn/revision-shorthand-for-side-branch-log (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-18 at 9fbe55bfef)\n + doc/revisions: remove brackets from rev^-n shorthand\n\n Doc cleanup.\n\n--------------------------------------------------\n[New Topics]\n\n* ab/push-cas-doc-n-test (2017-04-19) 1 commit\n - push: document & test --force-with-lease with multiple remotes\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* jk/parse-options-no-no-no (2017-04-19) 2 commits\n - SQUASH???\n - parse-options: disallow double-negations of options starting with no-\n\n Command line options that begin with \"--no-\" (e.g. \"--no-checkout\"\n option of \"git clone\") can be negated by removing \"--no-\"; we\n historically also allowed prefixing an extra \"no\" to the option\n (e.g. \"--no-no-checkout\"), which made the command line look ugly\n and unusual. This proposes to forbid it.\n\n While I agree there is no need to support \"--no-no-checkout\", this\n looks more like \"if it looks ugly and unusual, you do not have to\n use it\". Perhaps we can drop it?\n\n\n* ss/gitmodules-ignore-doc (2017-04-19) 1 commit\n - gitmodules: clarify the ignore option values\n\n Doc update.\n\n Will merge to 'next'.\n\n\n* ss/submodule-shallow-doc (2017-04-19) 1 commit\n - gitmodules: clarify what history depth a shallow clone has\n\n Doc update.\n\n Will merge to 'next'.\n\n--------------------------------------------------\n[Stalled]\n\n* sg/clone-refspec-from-command-line-config (2017-02-27) 1 commit\n - clone: respect configured fetch respecs during initial fetch\n\n Expecting a reroll.\n cf. <20170227211217.73gydlxb2qu2sp3m@sigill.intra.peff.net>\n cf. \n Some nits but looks ok.\n\n\n* sk/dash-is-previous (2017-03-01) 5 commits\n - revert.c: delegate handling of \"-\" shorthand to setup_revisions\n - sha1_name.c: teach get_sha1_1 \"-\" shorthand for \"@{-1}\"\n - revision.c: args starting with \"-\" might be a revision\n - revision.c: swap if/else blocks\n - revision.c: do not update argv with unknown option\n\n A dash \"-\" can be written to mean \"the branch that was previously\n checked out\" in more places.\n\n Needs review.\n cf. <1488007487-12965-1-git-send-email-kannan.siddharth12@gmail.com>\n\n\n* ls/filter-process-delayed (2017-03-06) 1 commit\n - convert: add \"status=delayed\" to filter process protocol\n\n What's the status of this one???\n cf. \n\n\n* nd/worktree-move (2017-01-27) 7 commits\n . fixup! worktree move: new command\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 Tentatively ejected as it seems to break 'pu' when merged.\n\n\n* pb/bisect (2017-02-18) 28 commits\n - fixup! bisect--helper: `bisect_next_check` & bisect_voc shell function in C\n - bisect--helper: remove the dequote in bisect_start()\n - bisect--helper: retire `--bisect-auto-next` subcommand\n - bisect--helper: retire `--bisect-autostart` subcommand\n - bisect--helper: retire `--bisect-write` subcommand\n - bisect--helper: `bisect_replay` shell function in C\n - bisect--helper: `bisect_log` shell function in C\n - bisect--helper: retire `--write-terms` subcommand\n - bisect--helper: retire `--check-expected-revs` subcommand\n - bisect--helper: `bisect_state` & `bisect_head` shell function in C\n - bisect--helper: `bisect_autostart` shell function in C\n - bisect--helper: retire `--next-all` subcommand\n - bisect--helper: retire `--bisect-clean-state` subcommand\n - bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C\n - t6030: no cleanup with bad merge base\n - bisect--helper: `bisect_start` shell function partially in C\n - bisect--helper: `get_terms` & `bisect_terms` shell function in C\n - bisect--helper: `bisect_next_check` & bisect_voc shell function in C\n - bisect--helper: `check_and_set_terms` shell function in C\n - bisect--helper: `bisect_write` shell function in C\n - bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C\n - bisect--helper: `bisect_reset` shell function in C\n - wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()\n - t6030: explicitly test for bisection cleanup\n - bisect--helper: `bisect_clean_state` shell function in C\n - bisect--helper: `write_terms` shell function in C\n - bisect: rewrite `check_term_format` shell function in C\n - bisect--helper: use OPT_CMDMODE instead of OPT_BOOL\n\n Move more parts of \"git bisect\" to C.\n\n Expecting a reroll.\n cf. \n cf. \n cf. \n\n\n* sh/grep-tree-obj-tweak-output (2017-01-20) 2 commits\n - grep: use '/' delimiter for paths\n - grep: only add delimiter if there isn't one already\n\n \"git grep\", when fed a tree-ish as an input, shows each hit\n prefixed with \":::\". As is\n almost always either a commit or a tag that points at a commit, the\n early part of the output \":\" can be used as the\n name of the blob and given to \"git show\". When is a\n tree given in the extended SHA-1 syntax (e.g. \":\", or\n \":\"), however, this results in a string that does not\n name a blob (e.g. \"::\" or \"::\").\n \"git grep\" has been taught to be a bit more intelligent about these\n cases and omit a colon (in the former case) or use slash (in the\n latter case) to produce \":\" and\n \":/\" that can be used as the name of a blob.\n\n Expecting a reroll? Is this good enough with known limitations?\n\n\n* jc/diff-b-m (2015-02-23) 5 commits\n . WIPWIP\n . WIP: diff-b-m\n - diffcore-rename: allow easier debugging\n - diffcore-rename.c: add locate_rename_src()\n - diffcore-break: allow debugging\n\n \"git diff -B -M\" produced incorrect patch when the postimage of a\n completely rewritten file is similar to the preimage of a removed\n file; such a resulting file must not be expressed as a rename from\n other place.\n\n The fix in this patch is broken, unfortunately.\n\n Will discard.\n\n--------------------------------------------------\n[Cooking]\n\n* df/dir-iter-remove-subtree (2017-04-19) 5 commits\n - remove_subtree(): reimplement using iterators\n - dir_iterator: rewrite state machine model\n - dir_iterator: refactor dir_iterator_advance\n - remove_subtree(): test removing nested directories\n - dir_iterator: add tests for dir_iterator API\n\n Update the dir-iterator API and use it to reimplement\n remove_subtree().\n\n Almost there except for a minor nit.\n GSoC microproject.\n\n\n* jk/ls-files-recurse-submodules-fix (2017-04-18) 2 commits\n (merged to 'next' on 2017-04-19 at d4682ceaae)\n + ls-files: fix path used when recursing into submodules\n + ls-files: fix recurse-submodules with nested submodules\n\n \"ls-files --recurse-submodules\" did not quite work well in a\n project with nested submodules.\n\n Will merge to 'master'.\n\n\n* jt/fetch-pack-error-reporting (2017-04-17) 1 commit\n (merged to 'next' on 2017-04-19 at 6da61f7236)\n + fetch-pack: show clearer error message upon ERR\n\n \"git fetch-pack\" was not prepared to accept ERR packet that the\n upload-pack can send with a human-readable error message. It\n showed the packet contents with ERR prefix, so there was no data\n loss, but it was redundant to say \"ERR\" in an error message.\n\n Will merge to 'master'.\n\n\n* nd/conditional-config-in-early-config (2017-04-19) 3 commits\n - config: correct file reading order in read_early_config()\n - config: handle conditional include when $GIT_DIR is not set up\n - config: prepare to pass more info in git_config_with_options()\n\n The recently introduced conditional inclusion of configuration did\n not work well when early-config mechanism was involved.\n\n Will merge to 'next'.\n\n\n* sb/checkout-recurse-submodules (2017-04-17) 1 commit\n (merged to 'next' on 2017-04-19 at 414e18fd9b)\n + submodule: remove a superfluous second check for the \"new\" variable\n\n Code cleanup.\n\n Will merge to 'master'.\n\n\n* xy/format-patch-base (2017-04-17) 1 commit\n (merged to 'next' on 2017-04-19 at c10723d486)\n + doc: trivial typo in git-format-patch.txt\n\n Doc cleanup.\n\n Will merge to 'master'.\n\n\n* jk/snprintf-cleanups (2017-04-17) 1 commit\n (merged to 'next' on 2017-04-19 at 4a18ea9971)\n + replace: plug a memory leak\n\n Hotfix for a topic that is already in 'master'.\n\n Will merge to 'master'.\n\n\n* ab/clone-no-tags (2017-04-19) 1 commit\n - clone: add a --no-tags option to clone without tags\n\n \"git clone\" learned the \"--no-tags\" option not to fetch all tags\n initially, and also set up the tagopt not to follow any tags in\n subsequent fetches.\n\n Will merge to 'next'.\n\n\n* ab/completion-push-delete-ref (2017-04-18) 1 commit\n - completion: expand \"push --delete \" for refs on that \n\n The completion script (in contrib/) learned to complete \"git push\n --delete b\" to complete branch name to be deleted.\n\n Will merge to 'next'.\n\n\n* bw/forking-and-threading (2017-04-19) 11 commits\n - run-command: block signals between fork and execve\n - run-command: add note about forking and threading\n - run-command: handle dup2 and close errors in child\n - run-command: eliminate calls to error handling functions in child\n - run-command: don't die in child when duping /dev/null\n - run-command: prepare child environment before forking\n - string-list: add string_list_remove function\n - run-command: use the async-signal-safe execv instead of execvp\n - run-command: prepare command before forking\n - t0061: run_command executes scripts without a #! line\n - t5550: use write_script to generate post-update hook\n\n The \"run-command\" APIimplementation has been made more robust\n against dead-locking in a threaded environment.\n\n Will merge to 'next'.\n\n\n* sb/reset-recurse-submodules (2017-04-18) 4 commits\n - builtin/reset: add --recurse-submodules switch\n - submodule.c: submodule_move_head works with broken submodules\n - submodule.c: uninitialized submodules are ignored in recursive commands\n - entry.c: submodule recursing: respect force flag correctly\n\n \"git reset\" learned \"--recurse-submodules\" option.\n\n\n* dt/xgethostname-nul-termination (2017-04-18) 2 commits\n (merged to 'next' on 2017-04-19 at 4035f442cc)\n + xgethostname: handle long hostnames\n + use HOST_NAME_MAX to size buffers for gethostname(2)\n\n gethostname(2) may not NUL terminate the buffer if hostname does\n not fit; unfortunately there is no easy way to see if our buffer\n was too small, but at least this will make sure we will not end up\n using garbage past the end of the buffer.\n\n Will merge to 'master'.\n\n\n* jh/string-list-micro-optim (2017-04-15) 1 commit\n (merged to 'next' on 2017-04-19 at 2a5e339df9)\n + string-list: use ALLOC_GROW macro when reallocing string_list\n\n The string-list API used a custom reallocation strategy that was\n very inefficient, instead of using the usual ALLOC_GROW() macro,\n which has been fixed.\n\n Will merge to 'master'.\n\n\n* jh/unpack-trees-micro-optim (2017-04-15) 1 commit\n (merged to 'next' on 2017-04-19 at 970c47a2f9)\n + unpack-trees: avoid duplicate ODB lookups during checkout\n\n In a 2- and 3-way merge of trees, more than one source trees often\n end up sharing an identical subtree; optimize by not reading the\n same tree multiple times in such a case.\n\n Will merge to 'master'.\n\n\n* jh/verify-index-checksum-only-in-fsck (2017-04-15) 1 commit\n (merged to 'next' on 2017-04-19 at a089b97d34)\n + read-cache: force_verify_index_checksum\n\n The index file has a trailing SHA-1 checksum to detect file\n corruption, and historically we checked it every time the index\n file is used. Omit the validation during normal use, and instead\n verify only in \"git fsck\".\n\n Will merge to 'master'.\n\n\n* ls/travis-doc-asciidoctor (2017-04-16) 3 commits\n (merged to 'next' on 2017-04-19 at 359c32953b)\n + travis-ci: unset compiler for jobs that do not need one\n + travis-ci: parallelize documentation build\n + travis-ci: build documentation with AsciiDoc and Asciidoctor\n\n Have Travis CI format the documentation with both AsciiDoc and\n AsciiDoctor.\n\n Will merge to 'master'.\n\n\n* mg/status-in-progress-info (2017-04-14) 1 commit\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 Waiting for final confirmation.\n cf. \n\n\n* nd/conditional-config-include (2017-04-14) 2 commits\n (merged to 'next' on 2017-04-19 at 2e94c40b46)\n + config: resolve symlinks in conditional include's patterns\n + path.c: and an option to call real_path() in expand_user_path()\n\n $GIT_DIR may in some cases be normalized with all symlinks resolved\n while \"gitdir\" path expansion in the pattern does not receive the\n same treatment, leading to incorrect mismatch. This has been fixed.\n\n Will merge to 'master'.\n\n\n* nd/worktree-add-lock (2017-04-16) 2 commits\n - SQUASH???\n - worktree add: add --lock option\n\n Allow to lock a worktree immediately after it's created. This helps\n prevent a race between \"git worktree add; git worktree lock\" and\n \"git worktree prune\".\n\n Waiting for a response to SQUASH???\n\n\n* ps/pathspec-empty-prefix-origin (2017-04-14) 1 commit\n - pathspec: honor `PATHSPEC_PREFIX_ORIGIN` with empty prefix\n\n A recent update broke \"git add -p ../foo\" from a subdirectory.\n\n Will merge to 'next'.\n\n\n* sr/http-proxy-configuration-fix (2017-04-13) 2 commits\n (merged to 'next' on 2017-04-19 at d8f507e951)\n + http: fix the silent ignoring of proxy misconfiguraion\n + http: honor empty http.proxy option to bypass proxy\n\n \"http.proxy\" set to an empty string is used to disable the usage of\n proxy. We broke this early last year.\n\n Will merge to 'master'.\n\n\n* tb/doc-eol-normalization (2017-04-13) 1 commit\n (merged to 'next' on 2017-04-19 at fe15d04d0a)\n + gitattributes.txt: document how to normalize the line endings\n\n Doc update.\n\n Will merge to 'master'.\n\n\n* gb/rebase-signoff (2017-04-18) 3 commits\n (merged to 'next' on 2017-04-19 at c3c04e6a71)\n + rebase: pass --[no-]signoff option to git am\n + builtin/am: fold am_signoff() into am_append_signoff()\n + builtin/am: honor --signoff also when --rebasing\n\n \"git rebase\" learns \"--signoff\" option.\n\n Will merge to 'master'.\n\n\n* jh/add-index-entry-optim (2017-04-19) 5 commits\n - read-cache: speed up has_dir_name (part 2)\n - read-cache: speed up has_dir_name (part 1)\n - read-cache: speed up add_index_entry during checkout\n - p0006-read-tree-checkout: perf test to time read-tree\n - read-cache: add strcmp_offset function\n\n \"git checkout\" that handles a lot of paths has been optimized by\n reducing the number of unnecessary checks of paths in the\n has_dir_name() function.\n\n Will merge to 'next'.\n\n\n* ab/grep-threading-cleanup (2017-04-16) 8 commits\n - grep: given --threads with NO_PTHREADS=YesPlease, warn\n - pack-objects: fix buggy warning about threads under NO_PTHREADS=YesPlease\n - pack-object & index-pack: add test for --threads warning under NO_PTHREADS\n - tests: add a PTHREADS prerequisite\n - grep: skip pthreads overhead when using one thread\n - grep: don't redundantly compile throwaway patterns under threading\n - grep: add tests for --threads=N and grep.threads\n - grep: assert that threading is enabled when calling grep_{lock,unlock}\n\n\n* bw/submodule-with-bs-path (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-19 at 692775477b)\n + submodule: prevent backslash expantion in submodule names\n\n \"git submodule\" script does not work well with strange pathnames.\n Protect it from a path with slashes in them, at least.\n\n Will merge to 'master'.\n\n\n* jk/loose-object-fsck (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-19 at 0cc7810018)\n + sha1_file: remove an used fd variable\n\n Code cleanup.\n\n Will merge to 'master'.\n\n\n* jk/quarantine-received-objects (2017-04-16) 3 commits\n (merged to 'next' on 2017-04-19 at 2c6fcf1d6d)\n + refs: reject ref updates while GIT_QUARANTINE_PATH is set\n + receive-pack: document user-visible quarantine effects\n + receive-pack: drop tmp_objdir_env from run_update_hook\n\n Add finishing touches to a recent topic.\n\n Will merge to 'master'.\n\n\n* ls/travis-coccicheck (2017-04-16) 1 commit\n - travis-ci: add static analysis build job to run coccicheck\n\n Travis CI learns to run coccicheck.\n\n Will merge to 'next'.\n\n\n* rs/misc-cppcheck-fixes (2017-04-17) 3 commits\n (merged to 'next' on 2017-04-19 at e8fca7f593)\n + server-info: avoid calling fclose(3) twice in update_info_file()\n + files_for_each_reflog_ent_reverse(): close stream and free strbuf on error\n + am: close stream on error, but not stdin\n\n Various small fixes.\n\n Will merge to 'master'.\n\n\n* km/t1400-modernization (2017-04-16) 1 commit\n (merged to 'next' on 2017-04-19 at 7490be39bf)\n + t1400: use consistent style for test_expect_success calls\n\n Code cleanup.\n\n Will merge to 'master'.\n\n\n* dt/http-postbuffer-can-be-large (2017-04-13) 1 commit\n (merged to 'next' on 2017-04-19 at dc9de26fc9)\n + http.postbuffer: allow full range of ssize_t values\n\n Allow the http.postbuffer configuration variable to be set to a\n size that can be expressed in size_t, which can be larger than\n ulong on some platforms.\n\n Will merge to 'master'.\n\n\n* pc/t2027-git-to-pipe-cleanup (2017-04-14) 1 commit\n - t2027: avoid using pipes\n\n Having a git command on the upstream side of a pipe in a test\n script will hide the exit status from the command, which may cause\n us to fail to notice a breakage; rewrite tests in a script to avoid\n this issue.\n\n Will merge to 'next'.\n\n\n* bp/sub-process-convert-filter (2017-03-30) 8 commits\n - convert: update subprocess_read_status to not die on EOF\n - sub-process: move sub-process functions into separate files\n - convert: rename reusable sub-process functions\n - convert: update generic functions to only use generic data structures\n - convert: separate generic structures and variables from the filter specific ones\n - convert: split start_multi_file_filter() into two separate functions\n - convert: move packet_write_list() into pkt-line.c as packet_writel()\n - pkt-line: add packet_read_line_gently()\n\n Code from \"conversion using external process\" codepath has been\n extracted to a separate sub-process.[ch] module.\n\n Reroll exists but needs more work.\n cf. <20170407120354.17736-1-benpeart@microsoft.com>\n\n\n* cc/split-index-config (2017-03-30) 1 commit\n - read-cache: avoid using git_path() in freshen_shared_index()\n\n The split-index code configuration code used an unsafe git_path()\n function without copying its result out.\n\n Needs to be explained better.\n The code looked OK, though.\n\n\n* mg/name-rev-debug (2017-03-31) 4 commits\n - describe: pass --debug down to name-rev\n - name-rev: provide debug output\n - name-rev: favor describing with tags and use committer date to tiebreak\n - name-rev: refactor logic to see if a new candidate is a better name\n\n \"git describe --debug --contains\" did not add any meaningful\n information, even though without \"--contains\" it did.\n\n Expecting a reroll of the tip two.\n cf. \n\n\n* mh/separate-ref-cache (2017-04-16) 20 commits\n - do_for_each_entry_in_dir(): delete function\n - files_pack_refs(): use reference iteration\n - commit_packed_refs(): use reference iteration\n - cache_ref_iterator_begin(): make function smarter\n - get_loose_ref_cache(): new function\n - get_loose_ref_dir(): function renamed from get_loose_refs()\n - do_for_each_entry_in_dir(): eliminate `offset` argument\n - refs: handle \"refs/bisect/\" in `loose_fill_ref_dir()`\n - ref-cache: use a callback function to fill the cache\n - refs: record the ref_store in ref_cache, not ref_dir\n - ref-cache: introduce a new type, ref_cache\n - refs: split `ref_cache` code into separate files\n - ref-cache: rename `remove_entry()` to `remove_entry_from_dir()`\n - ref-cache: rename `find_ref()` to `find_ref_entry()`\n - ref-cache: rename `add_ref()` to `add_ref_entry()`\n - refs_verify_refname_available(): use function in more places\n - refs_verify_refname_available(): implement once for all backends\n - refs_ref_iterator_begin(): new function\n - refs_read_raw_ref(): new function\n - get_ref_dir(): don't call read_loose_refs() for \"refs/bisect\"\n\n The internals of the refs API around the cached refs has been\n streamlined.\n\n Will merge to 'next'.\n\n\n* ja/doc-l10n (2017-03-20) 3 commits\n - SQUASH???\n - l10n: add git-add.txt to localized man pages\n - l10n: introduce framework for localizing man pages\n\n A proposal to use po4a to localize our manual pages.\n\n\n* nd/prune-in-worktree (2017-04-19) 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 (this branch uses nd/worktree-kill-parse-ref.)\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 Waiting for nd/worktree-kill-parse-ref to settle.\n\n\n* nd/worktree-kill-parse-ref (2017-04-16) 5 commits\n - refs: kill set_worktree_head_symref()\n - worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe()\n - refs: introduce get_worktree_ref_store()\n - refs.c: make submodule ref store hashmap generic\n - environment.c: fix potential segfault by get_git_common_dir()\n (this branch is used by nd/prune-in-worktree.)\n\n \"git gc\" did not interact well with \"git worktree\"-managed\n per-worktree refs.\n\n Will merge to 'next'.\n\n\n* jc/bundle (2016-03-03) 6 commits\n - index-pack: --clone-bundle option\n - Merge branch 'jc/index-pack' into jc/bundle\n - bundle v3: the beginning\n - bundle: keep a copy of bundle file name in the in-core bundle header\n - bundle: plug resource leak\n - bundle doc: 'verify' is not about verifying the bundle\n\n The beginning of \"split bundle\", which could be one of the\n ingredients to allow \"git clone\" traffic off of the core server\n network to CDN.\n"},{"id":"317316","messageId":"20170420095921.GA23873@ash","threadId":"45752","inReplyTo":"xmqq4lxjabce.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-04-20T09:59:21Z","receivedAt":"2017-04-20T09:59:48Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Apr 19, 2017 at 10:37:21PM -0700, Junio C Hamano wrote:\n> * nd/worktree-add-lock (2017-04-16) 2 commits\n> - SQUASH???\n> - worktree add: add --lock option\n> \n> Allow to lock a worktree immediately after it's created. This helps\n> prevent a race between \"git worktree add; git worktree lock\" and\n> \"git worktree prune\".\n> \n> Waiting for a response to SQUASH???\n\nLooking good. I would add some comment, lest ';' feel lonely. But it's\nreally personal taste.\n\n-- 8< --\ndiff --git a/builtin/worktree.c b/builtin/worktree.c\nindex 5ebdcce793..bc75676bf3 100644\n--- a/builtin/worktree.c\n+++ b/builtin/worktree.c\n@@ -310,7 +310,7 @@ static int add_worktree(const char *path, const char *refname,\n \tstrbuf_reset(&sb);\n \tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n \tif (!ret && opts->keep_locked)\n-\t\t;\n+\t\t;\t /* --lock wants to keep \"locked\" file */\n \telse\n \t\tunlink_or_warn(sb.buf);\n \targv_array_clear(&child_env);\n-- 8< --\n"},{"id":"317344","messageId":"alpine.DEB.2.20.1704201523390.3480@virtualbox","threadId":"45752","inReplyTo":"D61D47BD-9750-4FB6-892E-013504E03738@gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-20T13:24:56Z","receivedAt":"2017-04-20T13:25:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Lars & Junio,\n\nOn Thu, 20 Apr 2017, Lars Schneider wrote:\n\n> > * bw/forking-and-threading (2017-04-19) 11 commits\n> > - run-command: block signals between fork and execve\n> > - run-command: add note about forking and threading\n> > - run-command: handle dup2 and close errors in child\n> > - run-command: eliminate calls to error handling functions in child\n> > - run-command: don't die in child when duping /dev/null\n> > - run-command: prepare child environment before forking\n> > - string-list: add string_list_remove function\n> > - run-command: use the async-signal-safe execv instead of execvp\n> > - run-command: prepare command before forking\n> > - t0061: run_command executes scripts without a #! line\n> > - t5550: use write_script to generate post-update hook\n> > \n> > The \"run-command\" APIimplementation has been made more robust\n> > against dead-locking in a threaded environment.\n> > \n> > Will merge to 'next'.\n> \n> There might be a problem on Windows with this (that's just a hunch, i can't test this right now):\n> https://travis-ci.org/git/git/jobs/223830474\n\nThanks for keeping track of Travis' failure reports. From what I see, the\nlatest iteration (which does not seem to have made it to `pu` yet) has the\n!MINGW prerequisite which should fix the issue. Hopefully my suggested\naddition to the commit message will make it into the commit history, too.\n\nCiao,\nDscho\n"},{"id":"317347","messageId":"25191991-F4EA-4D91-B291-854F46A34DC2@gmail.com","threadId":"45752","inReplyTo":"xmqq4lxjabce.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-04-20T15:32:13Z","receivedAt":"2017-04-20T15:32:31Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Sorry for sending this email multiple times. My mobile email client created html... Should be fixed now!\n\n> \n> * ls/filter-process-delayed (2017-03-06) 1 commit\n> - convert: add \"status=delayed\" to filter process protocol\n> \n> What's the status of this one???\n> cf. \n\nposted v3 here:\nhttps://public-inbox.org/git/20170409191107.20547-1-larsxschneider@gmail.com/ \n\nFrom my point of view the only open question is if we use an index (\"delay-id\" favored by Peff) or the path (favored by Taylor) to identify delayed items: \nhttps://public-inbox.org/git/20170227095825.jhdspwy6oa6mvvvm@sigill.intra.peff.net/ \nhttps://public-inbox.org/git/20170412173404.GA49694@Ida/#r \n\nI slightly favor the path approach as it simplifies the protocol. But I also trust Peff's opinion.\n\n\n> * ls/travis-doc-asciidoctor (2017-04-16) 3 commits\n> (merged to 'next' on 2017-04-19 at 359c32953b)\n> + travis-ci: unset compiler for jobs that do not need one\n> + travis-ci: parallelize documentation build\n> + travis-ci: build documentation with AsciiDoc and Asciidoctor\n> \n> Have Travis CI format the documentation with both AsciiDoc and\n> AsciiDoctor.\n> \n> Will merge to 'master'.\n\nCan you hold this until next week?\nThe I would post a v2 and check asciidoc stderr: \nhttps://public-inbox.org/git/D9F45212-91F7-4BB1-A0EC-74A84DA81860@gmail.com/ \n\nI can also post an additional patch if you prefer to merge now.\n\nThanks, Lars\n\n\n"},{"id":"317348","messageId":"20170420153512.kc57z7cyxdzq74sg@sigill.intra.peff.net","threadId":"45752","inReplyTo":"20170420095921.GA23873@ash","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-20T15:35:13Z","receivedAt":"2017-04-20T15:35:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 20, 2017 at 04:59:21PM +0700, Duy Nguyen wrote:\n\n> On Wed, Apr 19, 2017 at 10:37:21PM -0700, Junio C Hamano wrote:\n> > * nd/worktree-add-lock (2017-04-16) 2 commits\n> > - SQUASH???\n> > - worktree add: add --lock option\n> > \n> > Allow to lock a worktree immediately after it's created. This helps\n> > prevent a race between \"git worktree add; git worktree lock\" and\n> > \"git worktree prune\".\n> > \n> > Waiting for a response to SQUASH???\n> \n> Looking good. I would add some comment, lest ';' feel lonely. But it's\n> really personal taste.\n> \n> -- 8< --\n> diff --git a/builtin/worktree.c b/builtin/worktree.c\n> index 5ebdcce793..bc75676bf3 100644\n> --- a/builtin/worktree.c\n> +++ b/builtin/worktree.c\n> @@ -310,7 +310,7 @@ static int add_worktree(const char *path, const char *refname,\n> \tstrbuf_reset(&sb);\n> \tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n> \tif (!ret && opts->keep_locked)\n> -\t\t;\n> +\t\t;\t /* --lock wants to keep \"locked\" file */\n> \telse\n> \t\tunlink_or_warn(sb.buf);\n\nI know this is just a drive-by comment, but given that the \"else\" is the\nonly thing that does anything, would it be simpler to flip the\nconditional? The strbuf manipulation above also could go inside it.\nE.g.:\n\ndiff --git a/builtin/worktree.c b/builtin/worktree.c\nindex 5ebdcce79..05ade547c 100644\n--- a/builtin/worktree.c\n+++ b/builtin/worktree.c\n@@ -307,12 +307,11 @@ static int add_worktree(const char *path, const char *refname,\n \tjunk_git_dir = NULL;\n \n done:\n-\tstrbuf_reset(&sb);\n-\tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n-\tif (!ret && opts->keep_locked)\n-\t\t;\n-\telse\n+\tif (ret || !opts->keep_locked) {\n+\t\tstrbuf_reset(&sb);\n+\t\tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n \t\tunlink_or_warn(sb.buf);\n+\t}\n \targv_array_clear(&child_env);\n \tstrbuf_release(&sb);\n \tstrbuf_release(&symref);\n\n(Since it's in its own block I'd also consider just introducing a new\nvariable for the path, but I guess reusing \"sb\" for each path is already\na pattern in the function).\n\n-Peff\n"},{"id":"317355","messageId":"20170420165622.GC142567@google.com","threadId":"45752","inReplyTo":"alpine.DEB.2.20.1704201523390.3480@virtualbox","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-04-20T16:56:22Z","receivedAt":"2017-04-20T16:56:31Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 04/20, Johannes Schindelin wrote:\n> Hi Lars & Junio,\n> \n> On Thu, 20 Apr 2017, Lars Schneider wrote:\n> \n> > > * bw/forking-and-threading (2017-04-19) 11 commits\n> > > - run-command: block signals between fork and execve\n> > > - run-command: add note about forking and threading\n> > > - run-command: handle dup2 and close errors in child\n> > > - run-command: eliminate calls to error handling functions in child\n> > > - run-command: don't die in child when duping /dev/null\n> > > - run-command: prepare child environment before forking\n> > > - string-list: add string_list_remove function\n> > > - run-command: use the async-signal-safe execv instead of execvp\n> > > - run-command: prepare command before forking\n> > > - t0061: run_command executes scripts without a #! line\n> > > - t5550: use write_script to generate post-update hook\n> > > \n> > > The \"run-command\" APIimplementation has been made more robust\n> > > against dead-locking in a threaded environment.\n> > > \n> > > Will merge to 'next'.\n> > \n> > There might be a problem on Windows with this (that's just a hunch, i can't test this right now):\n> > https://travis-ci.org/git/git/jobs/223830474\n> \n> Thanks for keeping track of Travis' failure reports. From what I see, the\n> latest iteration (which does not seem to have made it to `pu` yet) has the\n> !MINGW prerequisite which should fix the issue. Hopefully my suggested\n> addition to the commit message will make it into the commit history, too.\n\nThanks for catching this. And as you pointed out the latest reroll\nshould fix the issue.\n\n> \n> Ciao,\n> Dscho\n\n-- \nBrandon Williams\n"},{"id":"317436","messageId":"xmqqshl28zpi.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"20170420095921.GA23873@ash","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-20T22:46:17Z","receivedAt":"2017-04-20T22:46:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> Looking good. I would add some comment, lest ';' feel lonely. But it's\n> really personal taste.\n\n... which matches mine. Thanks for the update (which I'll squash in).\n\n>\n> -- 8< --\n> diff --git a/builtin/worktree.c b/builtin/worktree.c\n> index 5ebdcce793..bc75676bf3 100644\n> --- a/builtin/worktree.c\n> +++ b/builtin/worktree.c\n> @@ -310,7 +310,7 @@ static int add_worktree(const char *path, const char *refname,\n> \tstrbuf_reset(&sb);\n> \tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n> \tif (!ret && opts->keep_locked)\n> -\t\t;\n> +\t\t;\t /* --lock wants to keep \"locked\" file */\n> \telse\n> \t\tunlink_or_warn(sb.buf);\n> \targv_array_clear(&child_env);\n> -- 8< --\n"},{"id":"317437","messageId":"xmqqo9vq8zhn.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"20170420153512.kc57z7cyxdzq74sg@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-20T22:51:00Z","receivedAt":"2017-04-20T22:51:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> \tif (!ret && opts->keep_locked)\n>> -\t\t;\n>> +\t\t;\t /* --lock wants to keep \"locked\" file */\n>> \telse\n>> \t\tunlink_or_warn(sb.buf);\n>\n> I know this is just a drive-by comment, but given that the \"else\" is the\n> only thing that does anything, would it be simpler to flip the\n> conditional? The strbuf manipulation above also could go inside it.\n> E.g.:\n>\n> diff --git a/builtin/worktree.c b/builtin/worktree.c\n> index 5ebdcce79..05ade547c 100644\n> --- a/builtin/worktree.c\n> +++ b/builtin/worktree.c\n> @@ -307,12 +307,11 @@ static int add_worktree(const char *path, const char *refname,\n> \tjunk_git_dir = NULL;\n> \n> done:\n> -\tstrbuf_reset(&sb);\n> -\tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n> -\tif (!ret && opts->keep_locked)\n> -\t\t;\n> -\telse\n> +\tif (ret || !opts->keep_locked) {\n> +\t\tstrbuf_reset(&sb);\n> +\t\tstrbuf_addf(&sb, \"%s/locked\", sb_repo.buf);\n> \t\tunlink_or_warn(sb.buf);\n> +\t}\n> \targv_array_clear(&child_env);\n> \tstrbuf_release(&sb);\n> \tstrbuf_release(&symref);\n>\n> (Since it's in its own block I'd also consider just introducing a new\n> variable for the path, but I guess reusing \"sb\" for each path is already\n> a pattern in the function).\n\nYeah, when I looked at Duy's version and thought about changing to\nlose the empty statement myself, I was afraid that the \"if\"\ncondition might become less transparent to grasp, but now I see what\nyou actually written down, I think \"if we got an error, or the\ncaller didn't ask us to, remove that file\" is easy enough to\nunderstand.\n\nThanks.\n"},{"id":"317438","messageId":"xmqqinly8zev.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"25191991-F4EA-4D91-B291-854F46A34DC2@gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-20T22:52:40Z","receivedAt":"2017-04-20T22:52:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider writes:\n\n> Sorry for sending this email multiple times. My mobile email client created html... Should be fixed now!\n>\n>> \n>> * ls/filter-process-delayed (2017-03-06) 1 commit\n>> - convert: add \"status=delayed\" to filter process protocol\n>> \n>> What's the status of this one???\n>> cf. \n>\n> posted v3 here:\n> https://public-inbox.org/git/20170409191107.20547-1-larsxschneider@gmail.com/ \n>\n> From my point of view the only open question is if we use an index (\"delay-id\" favored by Peff) or the path (favored by Taylor) to identify delayed items: \n> https://public-inbox.org/git/20170227095825.jhdspwy6oa6mvvvm@sigill.intra.peff.net/ \n> https://public-inbox.org/git/20170412173404.GA49694@Ida/#r \n>\n> I slightly favor the path approach as it simplifies the protocol. But I also trust Peff's opinion.\n>\n\nThanks for a nice summary.\n\n>> * ls/travis-doc-asciidoctor (2017-04-16) 3 commits\n>> (merged to 'next' on 2017-04-19 at 359c32953b)\n>> + travis-ci: unset compiler for jobs that do not need one\n>> + travis-ci: parallelize documentation build\n>> + travis-ci: build documentation with AsciiDoc and Asciidoctor\n>> \n>> Have Travis CI format the documentation with both AsciiDoc and\n>> AsciiDoctor.\n>> \n>> Will merge to 'master'.\n>\n> Can you hold this until next week?\n> The I would post a v2 and check asciidoc stderr: \n> https://public-inbox.org/git/D9F45212-91F7-4BB1-A0EC-74A84DA81860@gmail.com/ \n>\n> I can also post an additional patch if you prefer to merge now.\n\nThanks; will hold.\n"},{"id":"317439","messageId":"xmqqbmrq8z4j.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"D61D47BD-9750-4FB6-892E-013504E03738@gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-20T22:58:52Z","receivedAt":"2017-04-20T22:59:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider writes:\n\n>> * bw/forking-and-threading (2017-04-19) 11 commits\n>> - run-command: block signals between fork and execve\n>> - run-command: add note about forking and threading\n>> - run-command: handle dup2 and close errors in child\n>> - run-command: eliminate calls to error handling functions in child\n>> - run-command: don't die in child when duping /dev/null\n>> - run-command: prepare child environment before forking\n>> - string-list: add string_list_remove function\n>> - run-command: use the async-signal-safe execv instead of execvp\n>> - run-command: prepare command before forking\n>> - t0061: run_command executes scripts without a #! line\n>> - t5550: use write_script to generate post-update hook\n>> \n>> The \"run-command\" APIimplementation has been made more robust\n>> against dead-locking in a threaded environment.\n>> \n>> Will merge to 'next'.\n>\n> There might be a problem on Windows with this (that's just a hunch, i can't test this right now):\n> https://travis-ci.org/git/git/jobs/223830474\n\nThanks for keeping an eye on Travis output. My eyes learned to\nignore the Windows section as its failures often seem to be due to\ntiming out.\n"},{"id":"317440","messageId":"20170420231836.GM142567@google.com","threadId":"45752","inReplyTo":"20170420165622.GC142567@google.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Brandon Williams","fromEmail":"bmwill@google.com","sentAt":"2017-04-20T23:18:36Z","receivedAt":"2017-04-20T23:18:50Z","isPatch":false,"sender":{"key":"bwilliams.eng@gmail.com","avatar":null},"body":"On 04/20, Brandon Williams wrote:\n> On 04/20, Johannes Schindelin wrote:\n> > Hi Lars & Junio,\n> > \n> > On Thu, 20 Apr 2017, Lars Schneider wrote:\n> > \n> > > > * bw/forking-and-threading (2017-04-19) 11 commits\n> > > > - run-command: block signals between fork and execve\n> > > > - run-command: add note about forking and threading\n> > > > - run-command: handle dup2 and close errors in child\n> > > > - run-command: eliminate calls to error handling functions in child\n> > > > - run-command: don't die in child when duping /dev/null\n> > > > - run-command: prepare child environment before forking\n> > > > - string-list: add string_list_remove function\n> > > > - run-command: use the async-signal-safe execv instead of execvp\n> > > > - run-command: prepare command before forking\n> > > > - t0061: run_command executes scripts without a #! line\n\nI just double checked what differences existed between what I have\nlocally and what is queued at bw/forking-and-threading and it looks like\nthe changes (adding the !MINGW) to just this one patch were missed,\nwhile the rest of them were picked up. Just and fyi.\n\n> > > > - t5550: use write_script to generate post-update hook\n> > > > \n> > > > The \"run-command\" APIimplementation has been made more robust\n> > > > against dead-locking in a threaded environment.\n> > > > \n> > > > Will merge to 'next'.\n> > > \n> > > There might be a problem on Windows with this (that's just a hunch, i can't test this right now):\n> > > https://travis-ci.org/git/git/jobs/223830474\n> > \n> > Thanks for keeping track of Travis' failure reports. From what I see, the\n> > latest iteration (which does not seem to have made it to `pu` yet) has the\n> > !MINGW prerequisite which should fix the issue. Hopefully my suggested\n> > addition to the commit message will make it into the commit history, too.\n> \n> Thanks for catching this. And as you pointed out the latest reroll\n> should fix the issue.\n> \n> > \n> > Ciao,\n> > Dscho\n> \n> -- \n> Brandon Williams\n\n-- \nBrandon Williams\n"},{"id":"317442","messageId":"xmqq37d28toa.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"20170420231836.GM142567@google.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-21T00:56:37Z","receivedAt":"2017-04-21T00:56:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Williams writes:\n\n> On 04/20, Brandon Williams wrote:\n>> On 04/20, Johannes Schindelin wrote:\n>> > Hi Lars & Junio,\n>> > \n>> > On Thu, 20 Apr 2017, Lars Schneider wrote:\n>> > \n>> > > > * bw/forking-and-threading (2017-04-19) 11 commits\n>> > > > - run-command: block signals between fork and execve\n>> > > > - run-command: add note about forking and threading\n>> > > > - run-command: handle dup2 and close errors in child\n>> > > > - run-command: eliminate calls to error handling functions in child\n>> > > > - run-command: don't die in child when duping /dev/null\n>> > > > - run-command: prepare child environment before forking\n>> > > > - string-list: add string_list_remove function\n>> > > > - run-command: use the async-signal-safe execv instead of execvp\n>> > > > - run-command: prepare command before forking\n>> > > > - t0061: run_command executes scripts without a #! line\n>\n> I just double checked what differences existed between what I have\n> locally and what is queued at bw/forking-and-threading and it looks like\n> the changes (adding the !MINGW) to just this one patch were missed,\n> while the rest of them were picked up. Just and fyi.\n\nThanks. Queued with a warning in the log message.\n\n"},{"id":"317469","messageId":"alpine.DEB.2.20.1704211135430.3480@virtualbox","threadId":"45752","inReplyTo":"xmqqbmrq8z4j.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-21T09:50:20Z","receivedAt":"2017-04-21T09:50:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 20 Apr 2017, Junio C Hamano wrote:\n\n> Lars Schneider writes:\n> \n> >> * bw/forking-and-threading (2017-04-19) 11 commits\n> >> - run-command: block signals between fork and execve\n> >> - run-command: add note about forking and threading\n> >> - run-command: handle dup2 and close errors in child\n> >> - run-command: eliminate calls to error handling functions in child\n> >> - run-command: don't die in child when duping /dev/null\n> >> - run-command: prepare child environment before forking\n> >> - string-list: add string_list_remove function\n> >> - run-command: use the async-signal-safe execv instead of execvp\n> >> - run-command: prepare command before forking\n> >> - t0061: run_command executes scripts without a #! line\n> >> - t5550: use write_script to generate post-update hook\n> >> \n> >> The \"run-command\" APIimplementation has been made more robust\n> >> against dead-locking in a threaded environment.\n> >> \n> >> Will merge to 'next'.\n> >\n> > There might be a problem on Windows with this (that's just a hunch, i can't test this right now):\n> > https://travis-ci.org/git/git/jobs/223830474\n> \n> Thanks for keeping an eye on Travis output. My eyes learned to\n> ignore the Windows section as its failures often seem to be due to\n> timing out.\n\nPart of the reason is that you push out all of the branches in one go,\ntypically at the very end of your work day. The idea of Continuous\nIntegration is a little orthogonal to that style, suggesting to build &\ntest whenever new changes come into the integration branch.\n\nAs a consequence, my original setup was a little overloaded: the VM sat\nidle most of the time, and when you pushed, it was overloaded.\n\nTo accommodate even that use case, I managed to pry away some resources\nthat should be mostly idle at the time you push, and that should be able\nto run up to 4 builds in parallel (the number \"4\" is not really magic, it\nis the number of integration branches of git.git).\n\nSince that \"let's aggregate everything and only push out the final result\nat the end of the day\" approach does not really allow the Continuous\nTesting to identify problems associated with individual topic branches, I\nhave another job that bisects the breakages (with all associated problems\nI reported earlier, as you apply some patches on top of really ancient\ncommits and bisect wants to test all merge bases first) because the\nrequired time *definitely* would let Travis time out all the time. Those\nbisect results are even less visible than the Travis results, see e.g.\nhttps://github.com/git/git/commit/2e3a8b9035a#commitcomment-21836854.\n\nHaving said that, I do not think that it makes sense for you to change\nyour habits, as proper Continuous Integration (as opposed to a variation\nof Continuous Testing that we use, really) would take a lot more of a\nchange than you are comfortable with: it would look a lot more Pull\nRequest centric than the current mailing list centered process.\n\nCiao,\nDscho\n"},{"id":"317489","messageId":"CAP8UFD19DVqQLHBta74uLcFPwJaRUKF8Ppmnhct5ub=OkKSqCQ@mail.gmail.com","threadId":"45752","inReplyTo":"alpine.DEB.2.20.1704211135430.3480@virtualbox","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-04-21T12:29:08Z","receivedAt":"2017-04-21T12:29:15Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Apr 21, 2017 at 11:50 AM, Johannes Schindelin\n wrote:\n>\n> Since that \"let's aggregate everything and only push out the final result\n> at the end of the day\" approach does not really allow the Continuous\n> Testing to identify problems associated with individual topic branches, I\n> have another job that bisects the breakages\n\nGreat!\n\n> (with all associated problems\n> I reported earlier, as you apply some patches on top of really ancient\n> commits and bisect wants to test all merge bases first)\n\nFirst bisect should ask you to test merge bases only if there are\n\"good\" commits that are not ancestors of the \"bad\" commit.\nSo I don't know how you want to bisect, but it seems to me that you\ncould just go back to a previous know \"good\" commit when the one you\nhave is not an ancestor of the \"bad\" commit.\nThis would get rid of the whole merge base problem.\n\nSecond yeah there is probably an old bug in bisect there. In theory in\nmost cases bisect should ask you to test only one merge base, as:\n\n- if the merge base is \"bad\", it means that the bug has been fixed\nbetween the merge base and your \"good\" commit, and bisecting will\nstop,\n- if the merge base is \"good\", it means that all the merge bases that\nare ancestor of this merge base are also good, so there is no need to\ntest them\n\nBut that theory can work only if bisect is asking you to test a merge\nbase that is a descendant of many (if not all the other merge bases),\nbut unfortunately I don't think bisect is smart enough for that yet.\n\n> because the\n> required time *definitely* would let Travis time out all the time. Those\n> bisect results are even less visible than the Travis results, see e.g.\n> https://github.com/git/git/commit/2e3a8b9035a#commitcomment-21836854.\n\nNice that they exists though!\n"},{"id":"317542","messageId":"alpine.DEB.2.20.1704221319580.3480@virtualbox","threadId":"45752","inReplyTo":"CAP8UFD19DVqQLHBta74uLcFPwJaRUKF8Ppmnhct5ub=OkKSqCQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-22T11:48:41Z","receivedAt":"2017-04-22T11:49:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Christian,\n\nOn Fri, 21 Apr 2017, Christian Couder wrote:\n\n> On Fri, Apr 21, 2017 at 11:50 AM, Johannes Schindelin\n> wrote:\n> >\n> > (with all associated problems I reported earlier, as you apply some\n> > patches on top of really ancient commits and bisect wants to test all\n> > merge bases first)\n> \n> First bisect should ask you to test merge bases only if there are\n> \"good\" commits that are not ancestors of the \"bad\" commit.\n\nPlease note that this is a stateless job. The only \"state\" I have is the\nbranch name.\n\nSo when something goes wrong, I have *no* indicator what is a known good\nstate.\n\nThe strategy I implemented was to use knowledge about the branches and\ntheir relations. So when there is a bug in `pu`, the script first tests\nwhether the same test passes in `next`. And if it does, that is my\nknown-good state.\n\nIn the meantime, I cheat and mark all merge-bases as known-good, too. But\nthat is by no means a correct assumption: sometimes Junio decides to base\na patch on top of a really ancient commit, one that may be broken on\nWindows. So there you are, I cannot win, I just tried to implement\nsomething that works reasonably well, most of the time. It still takes way\ntoo long.\n\n> Second yeah there is probably an old bug in bisect there. In theory in\n> most cases bisect should ask you to test only one merge base, as:\n> \n> - if the merge base is \"bad\", it means that the bug has been fixed\n> between the merge base and your \"good\" commit, and bisecting will\n> stop,\n> - if the merge base is \"good\", it means that all the merge bases that\n> are ancestor of this merge base are also good, so there is no need to\n> test them\n\nThat is not necessarily correct. If there are two merge bases, one may be\nbroken, and then that one is the first bad commit.\n\n> > because the required time *definitely* would let Travis time out all\n> > the time. Those bisect results are even less visible than the Travis\n> > results, see e.g.\n> > https://github.com/git/git/commit/2e3a8b9035a#commitcomment-21836854.\n> \n> Nice that they exists though!\n\nYeah, well, it took enough of my time to implement, too ;-)\n\nCiao,\nDscho\n"},{"id":"317543","messageId":"a9685abc-50ad-3ee6-3384-0e043d205612@kdbg.org","threadId":"45752","inReplyTo":"CAP8UFD19DVqQLHBta74uLcFPwJaRUKF8Ppmnhct5ub=OkKSqCQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-04-22T13:37:29Z","receivedAt":"2017-04-22T13:37:42Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 21.04.2017 um 14:29 schrieb Christian Couder:\n> First bisect should ask you to test merge bases only if there are\n> \"good\" commits that are not ancestors of the \"bad\" commit.\n\nThat's a tangent, but I have never understood why this needs to be so. \nConsider this:\n\n o--o--o--o--o--o--o--o--B\n / /\n -o--o--o--o--g--o--o--o--o--G\n\nWhen I mark B as bad and G as good, why would g have to be tested first? \nThis is exactly what I do when I bisect in Git history: I mark the \nlatest commits on git-gui and gitk sub-histories as good, because I know \nthey can't possibly be bad. (In my setup, these two histories are ahead \nof pu and next.)\n\n-- Hannes\n\n"},{"id":"317545","messageId":"CAP8UFD3QJ5irxNZqn__CqXPgi+uY4vhZ2HyrNu9RhScbRU0LOA@mail.gmail.com","threadId":"45752","inReplyTo":"alpine.DEB.2.20.1704221319580.3480@virtualbox","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-04-22T17:32:00Z","receivedAt":"2017-04-22T17:32:08Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Dscho,\n\nOn Sat, Apr 22, 2017 at 1:48 PM, Johannes Schindelin\n wrote:\n>>\n>> First bisect should ask you to test merge bases only if there are\n>> \"good\" commits that are not ancestors of the \"bad\" commit.\n>\n> Please note that this is a stateless job. The only \"state\" I have is the\n> branch name.\n>\n> So when something goes wrong, I have *no* indicator what is a known good\n> state.\n\nMaybe we could consider the last release a known good state?\n\n> The strategy I implemented was to use knowledge about the branches and\n> their relations. So when there is a bug in `pu`, the script first tests\n> whether the same test passes in `next`. And if it does, that is my\n> known-good state.\n>\n> In the meantime, I cheat and mark all merge-bases as known-good, too. But\n> that is by no means a correct assumption: sometimes Junio decides to base\n> a patch on top of a really ancient commit, one that may be broken on\n> Windows. So there you are, I cannot win, I just tried to implement\n> something that works reasonably well, most of the time. It still takes way\n> too long.\n>\n>> Second yeah there is probably an old bug in bisect there. In theory in\n>> most cases bisect should ask you to test only one merge base, as:\n>>\n>> - if the merge base is \"bad\", it means that the bug has been fixed\n>> between the merge base and your \"good\" commit, and bisecting will\n>> stop,\n>> - if the merge base is \"good\", it means that all the merge bases that\n>> are ancestor of this merge base are also good, so there is no need to\n>> test them\n>\n> That is not necessarily correct. If there are two merge bases, one may be\n> broken, and then that one is the first bad commit.\n\nI wrote \"in most cases\" above because I think that it is not usual for\ngit.git to have branches that start from a commit that is not among\nthe set given by `git rev-list --first-parent master`.\n\nSo \"in most cases\" all the merge bases are among the first parents of\nmaster, which means that if bisect was smart enough to first test the\nlast of these merge bases and to discard the merge bases that are\namong its ancestors, then bisect would not need to test the other\nmerge bases.\n\nEven if there were a few merge bases that were not among the first\nparents of master, the number of merge bases to test could be reduced\na lot.\n"},{"id":"317622","messageId":"xmqqfugy4pnx.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"alpine.DEB.2.20.1704211135430.3480@virtualbox","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-24T00:25:54Z","receivedAt":"2017-04-24T00:26:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Part of the reason is that you push out all of the branches in one go,\n> typically at the very end of your work day. The idea of Continuous\n> Integration is a little orthogonal to that style, suggesting to build &\n> test whenever new changes come into the integration branch.\n>\n> As a consequence, my original setup was a little overloaded: the VM sat\n> idle most of the time, and when you pushed, it was overloaded.\n\nI do not see pushing out all them in one go is making the problem\nworse for you, though.\n\nAs of this writing, master..pu counts 60+ first-parent merges.\nInstead of pushing out the final one at the end of the day, I could\npush out after every merge. Behind the scenes, because some topics\nare extended or tweaked while I read the list discussion, the number\nof merges I am doing during a day is about twice or more than that\nbefore I reach the final version for the day. \n\nMany issues can be noticed locally even before the patches hit a\ntopic, before the topic gets merged to 'pu', or before the tentative\n'pu' is pushed out, and breakage at each of these points can be\nlocally corrected without bothering external test setups. I've been\nassuming that pushing out all in one go at the end will help\nreducing the load at external test setups.\n"},{"id":"317691","messageId":"alpine.DEB.2.20.1704241604030.3480@virtualbox","threadId":"45752","inReplyTo":"CAP8UFD3QJ5irxNZqn__CqXPgi+uY4vhZ2HyrNu9RhScbRU0LOA@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-24T14:08:31Z","receivedAt":"2017-04-24T14:08:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Christian,\n\nOn Sat, 22 Apr 2017, Christian Couder wrote:\n\n> On Sat, Apr 22, 2017 at 1:48 PM, Johannes Schindelin\n> wrote:\n> >>\n> >> First bisect should ask you to test merge bases only if there are\n> >> \"good\" commits that are not ancestors of the \"bad\" commit.\n> >\n> > Please note that this is a stateless job. The only \"state\" I have is\n> > the branch name.\n> >\n> > So when something goes wrong, I have *no* indicator what is a known\n> > good state.\n> \n> Maybe we could consider the last release a known good state?\n\nYou mean the latest release. I would expect that we won't have a last\nrelease in a long time...\n\nUsing the latest release as a 'known good' would not improve on using the\nstrategy I chose, as the latest release is at most up-to-date with\nmaint/master. In the case of `pu`, for example, it is much better to test\n`next` and use it as a known good state if it passes.\n\nIf we had a Pull Request centric workflow with one integration branch (as\nopposed to four), it would be relatively easy, as `master` would always be\nexpected to serve as a \"known good\" state, and it would be the policy that\nthe build has to pass before Pull Requests would be accepted.\n\nBut we don't, and that's that.\n\nCiao,\nJohannes\n"},{"id":"317693","messageId":"alpine.DEB.2.20.1704241609300.3480@virtualbox","threadId":"45752","inReplyTo":"xmqqfugy4pnx.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-24T14:19:48Z","receivedAt":"2017-04-24T14:20:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Sun, 23 Apr 2017, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Part of the reason is that you push out all of the branches in one go,\n> > typically at the very end of your work day. The idea of Continuous\n> > Integration is a little orthogonal to that style, suggesting to build\n> > & test whenever new changes come into the integration branch.\n> >\n> > As a consequence, my original setup was a little overloaded: the VM\n> > sat idle most of the time, and when you pushed, it was overloaded.\n> \n> I do not see pushing out all them in one go is making the problem worse\n> for you, though.\n\nOh no, you don't see that? Then let me spell it out a little more\nclearly: when you push out four branches at the same time, the same\nVirtual Machine that hosts all of the build agents has to build each and\neveryone of them, then run the entire test suite.\n\nAs I have pointed out at several occasions (but I was probably complaining\ntoo much about it, so you probably ignored it), the test suite uses shell\nscripting a lot, and as a consequence it is really, really slow on\nWindows. Meaning that even on a high-end VM, it typically takes 1.5 hours\nto run the test suite. That's without SVN tests.\n\nSo now we have up to four build agents banging at the same CPU and RAM,\ncompeting for resources. Now it takes more like 2-3 hours to run the\nentire build & test.\n\nThe situation usually gets a little worse, even: you sometimes push out\nseveral iterations of `pu` in relatively rapid succession, \"rapid\" being\nrelative to the time taken by the builds.\n\nThat means that there are sometimes four jobs still hogging the VM when\nthe next request to build & test `pu` arrives, and sometimes there is\nanother one queued before the first job finishes.\n\nNaturally, the last two jobs will have started barely before Travis\ndecides that it waited long enough (3 hours) to call it quits.\n\nTo answer your implied question: the situation would be much, much better\nif the branches with more time in-between.\n\nBut as I said, I understand that it would be asking you way too much to\nchange your process that seems to work well for you.\n\n> As of this writing, master..pu counts 60+ first-parent merges.\n> Instead of pushing out the final one at the end of the day, I could\n> push out after every merge. Behind the scenes, because some topics\n> are extended or tweaked while I read the list discussion, the number\n> of merges I am doing during a day is about twice or more than that\n> before I reach the final version for the day. \n> \n> Many issues can be noticed locally even before the patches hit a\n> topic, before the topic gets merged to 'pu', or before the tentative\n> 'pu' is pushed out, and breakage at each of these points can be\n> locally corrected without bothering external test setups. I've been\n> assuming that pushing out all in one go at the end will help\n> reducing the load at external test setups.\n\nPushing out only four updates at the end of the day is probably better\nthan pushing after every merge, for sure.\n\nCiao,\nDscho\n"},{"id":"317694","messageId":"alpine.DEB.2.20.1704241622510.3480@virtualbox","threadId":"45752","inReplyTo":"a9685abc-50ad-3ee6-3384-0e043d205612@kdbg.org","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-04-24T14:24:13Z","receivedAt":"2017-04-24T14:24:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Hannes,\n\nOn Sat, 22 Apr 2017, Johannes Sixt wrote:\n\n> Am 21.04.2017 um 14:29 schrieb Christian Couder:\n> > First bisect should ask you to test merge bases only if there are\n> > \"good\" commits that are not ancestors of the \"bad\" commit.\n> \n> That's a tangent, but I have never understood why this needs to be so.\n> Consider this:\n> \n> o--o--o--o--o--o--o--o--B\n> / /\n> -o--o--o--o--g--o--o--o--o--G\n> \n> When I mark B as bad and G as good, why would g have to be tested first? This\n> is exactly what I do when I bisect in Git history: I mark the latest commits\n> on git-gui and gitk sub-histories as good, because I know they can't possibly\n> be bad. (In my setup, these two histories are ahead of pu and next.)\n\nI guess the idea behind bisect's reasoning is that you could have merged\nthe \"wrong\" branch first.\n\nCiao,\nDscho\n"},{"id":"317695","messageId":"CACBZZX7AmzFw-jVC_hd1t+qjK5jD485XD8g6U72p4RLoRD_kJA@mail.gmail.com","threadId":"45752","inReplyTo":"alpine.DEB.2.20.1704241609300.3480@virtualbox","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-24T15:18:57Z","receivedAt":"2017-04-24T15:19:30Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Apr 24, 2017 at 4:19 PM, Johannes Schindelin\n wrote:\n> Hi Junio,\n>\n> On Sun, 23 Apr 2017, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>>\n>> > Part of the reason is that you push out all of the branches in one go,\n>> > typically at the very end of your work day. The idea of Continuous\n>> > Integration is a little orthogonal to that style, suggesting to build\n>> > & test whenever new changes come into the integration branch.\n>> >\n>> > As a consequence, my original setup was a little overloaded: the VM\n>> > sat idle most of the time, and when you pushed, it was overloaded.\n>>\n>> I do not see pushing out all them in one go is making the problem worse\n>> for you, though.\n>\n> Oh no, you don't see that? Then let me spell it out a little more\n> clearly: when you push out four branches at the same time, the same\n> Virtual Machine that hosts all of the build agents has to build each and\n> everyone of them, then run the entire test suite.\n>\n> As I have pointed out at several occasions (but I was probably complaining\n> too much about it, so you probably ignored it), the test suite uses shell\n> scripting a lot, and as a consequence it is really, really slow on\n> Windows. Meaning that even on a high-end VM, it typically takes 1.5 hours\n> to run the test suite. That's without SVN tests.\n>\n> So now we have up to four build agents banging at the same CPU and RAM,\n> competing for resources. Now it takes more like 2-3 hours to run the\n> entire build & test.\n>\n> The situation usually gets a little worse, even: you sometimes push out\n> several iterations of `pu` in relatively rapid succession, \"rapid\" being\n> relative to the time taken by the builds.\n>\n> That means that there are sometimes four jobs still hogging the VM when\n> the next request to build & test `pu` arrives, and sometimes there is\n> another one queued before the first job finishes.\n>\n> Naturally, the last two jobs will have started barely before Travis\n> decides that it waited long enough (3 hours) to call it quits.\n>\n> To answer your implied question: the situation would be much, much better\n> if the branches with more time in-between.\n>\n> But as I said, I understand that it would be asking you way too much to\n> change your process that seems to work well for you.\n\nIs getting the results of these builds time-critical? If not perhaps\nan acceptable solution would be to use a source repo that's\ntime-delayed, e.g. 24hrs behind on average from Junio's git.git, and\nwhere commits are pushed in at some configurable trickle.\n\n>> As of this writing, master..pu counts 60+ first-parent merges.\n>> Instead of pushing out the final one at the end of the day, I could\n>> push out after every merge. Behind the scenes, because some topics\n>> are extended or tweaked while I read the list discussion, the number\n>> of merges I am doing during a day is about twice or more than that\n>> before I reach the final version for the day.\n>>\n>> Many issues can be noticed locally even before the patches hit a\n>> topic, before the topic gets merged to 'pu', or before the tentative\n>> 'pu' is pushed out, and breakage at each of these points can be\n>> locally corrected without bothering external test setups. I've been\n>> assuming that pushing out all in one go at the end will help\n>> reducing the load at external test setups.\n>\n> Pushing out only four updates at the end of the day is probably better\n> than pushing after every merge, for sure.\n>\n> Ciao,\n> Dscho\n"},{"id":"317699","messageId":"ADC645666B1F4ECA92E9082F0565F475@PhilipOakley","threadId":"45752","inReplyTo":"alpine.DEB.2.20.1704241622510.3480@virtualbox","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2017-04-24T16:34:32Z","receivedAt":"2017-04-24T16:35:06Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Johannes Schindelin\" \n> Hi Hannes,\n>\n> On Sat, 22 Apr 2017, Johannes Sixt wrote:\n>\n>> Am 21.04.2017 um 14:29 schrieb Christian Couder:\n>> > First bisect should ask you to test merge bases only if there are\n>> > \"good\" commits that are not ancestors of the \"bad\" commit.\n>>\n>> That's a tangent, but I have never understood why this needs to be so.\n>> Consider this:\n>>\n>> o--o--o--o--o--o--o--o--B\n>> / /\n>> -o--o--o--o--g--o--o--o--o--G\n>>\n>> When I mark B as bad and G as good, why would g have to be tested first? \n>> This\n>> is exactly what I do when I bisect in Git history: I mark the latest \n>> commits\n>> on git-gui and gitk sub-histories as good, because I know they can't \n>> possibly\n>> be bad. (In my setup, these two histories are ahead of pu and next.)\n>\n> I guess the idea behind bisect's reasoning is that you could have merged\n> the \"wrong\" branch first.\n>\n> Ciao,\n> Dscho\n>\n\nSorry if I'm bikeshedding here, but it does look like adding an alternate \n'bisect' strategy may be useful for this style of integration testing.\n\nTo me, given the multiplicity of independent branches being brought \ntogether, it should be possible to do a check on each of the branches \nseparately, before the tests along the line of integration . The tests would \nnot be a true 'bisection' as they are separate single point tests, but they \ndo establish good commits at the tips of those branches.\n\nThus, for each of the merges in the --first-parent traversal, the option \ncould test (in the OS of choice) the *second parent* commit of the merge. \nThis sets the known good points. The breakages during the integration then \nbecome easier to bisect, as it is only looking for the integration of a good \nseries into mainline that breaks. [1]\n\nIn addition, an aside that dscho made earlier about the merge-base of some \nbranches relative to Windows may have been missed. The normal bisect process \nassumes that we start from a set of good merge bases. However, dscho noticed \nthat occasionally some series may choose an older point on maint (etc.) that \nitself would _not_ be classed as good when tested on Windows (or on other \nOS's). Those older mergebases can make the classic bisect across all the \ncommits in the DAG between here and there a tortuous process, especially if \nthe local OS implementation percieves the base points as bad! (which breaks \nexpectations).\n\n--\nPhilip\n\n\n[1] It maybe that this can be approached via an alternate DAG, which could \nbe 'faked' up as if each of the topic branches had been squashed from being \na long series down to a single commit (the final tree of the series), and \nthen likewise (same tree) for the integration merges, such that all the \nsingleton commits are not tested, only the pre and post merge commits on the \nfirst-parent traverse. \n\n"},{"id":"317747","messageId":"xmqqbmrlz4mm.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"CACBZZX7AmzFw-jVC_hd1t+qjK5jD485XD8g6U72p4RLoRD_kJA@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-25T00:56:49Z","receivedAt":"2017-04-25T00:57:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Is getting the results of these builds time-critical? If not perhaps\n> an acceptable solution would be to use a source repo that's\n> time-delayed, e.g. 24hrs behind on average from Junio's git.git, and\n> where commits are pushed in at some configurable trickle.\n\nBecause the tip of 'pu' is updated every day, but the tips of\nindividual topics are not, the tip of the more stable side of\nintegration branches are less often updated, I would think that an\nautomated procedure (whether it is Travis or Dscho's Windows thing)\nthat is most efficient for us would:\n\n - treat updates to 'maint', 'master' and 'next' as they do right\n now;\n\n - use update to 'pu' as a mere \"trigger\" and not test 'pu' as an\n aggregate as it is not very interesting (merges near the tip may\n be merging known-broken topics, like yesterday's pushout).\n\nAnd arrange 'pu' update to trigger a procedure like this:\n\n - Grab the list of merge commits beyond what matches 'next':\n\n $ git rev-list --first-parent '^pu^{/^### match next}' pu\n\n - For each of these merges:\n\n - If its second parent (i.e. the tip of a topic) was already\n tested with the current 'master', do not bother testing it\n again;\n\n - Otherwise, call its second parent \"it\" in the below:\n\n - Create a merge of it (and nothing else) on top of 'master',\n and test it. Each topic is intended to be able to graduate\n without other topics in 'pu', so this will catch potential\n breakage early and help blocking a broken topic from getting\n merged to 'master'.\n\n - When the above fails, test it in isolation to see if it\n itself is broken. If this succeeds, we may have discovered\n unintended interactions between the topic and other topics\n already in 'master'. Or the topic itself may already been\n broken.\n\n - In either case, record the test result so that the same tip\n of the topic would not have to be tested again, merely\n because the tip of 'pu' got updated next day due to updates\n in other topics.\n\nWe can s/master/next/ in the above description (I am undecided on\npros-and-cons between using 'master' and 'next').\n"},{"id":"317752","messageId":"CAP8UFD1r9TFE9ns5pobDOpugF8MBiJAYgrRALCqGVmgWud=QjQ@mail.gmail.com","threadId":"45752","inReplyTo":"a9685abc-50ad-3ee6-3384-0e043d205612@kdbg.org","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-04-25T02:00:05Z","receivedAt":"2017-04-25T02:00:14Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Apr 22, 2017 at 3:37 PM, Johannes Sixt wrote:\n> Am 21.04.2017 um 14:29 schrieb Christian Couder:\n>>\n>> First bisect should ask you to test merge bases only if there are\n>> \"good\" commits that are not ancestors of the \"bad\" commit.\n>\n>\n> That's a tangent, but I have never understood why this needs to be so.\n> Consider this:\n>\n> o--o--o--o--o--o--o--o--B\n> / /\n> -o--o--o--o--g--o--o--o--o--G\n>\n> When I mark B as bad and G as good, why would g have to be tested first?\n\nIt is because g could be bad if the bug has been fixed between g and G.\nIf this happens and we don't test g, we would give a wrong result.\n\n> This is exactly what I do when I bisect in Git history: I mark the latest\n> commits on git-gui and gitk sub-histories as good, because I know they can't\n> possibly be bad. (In my setup, these two histories are ahead of pu and\n> next.)\n\nYeah, it is safe to do that in this case as we test the merge bases.\n"},{"id":"317755","messageId":"CAP8UFD2pHjoJmMQ7VXX0QGQ6_3-_yXtaAtzNzSsPjAgPVz8Fag@mail.gmail.com","threadId":"45752","inReplyTo":"ADC645666B1F4ECA92E9082F0565F475@PhilipOakley","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2017-04-25T02:17:35Z","receivedAt":"2017-04-25T02:17:50Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Apr 24, 2017 at 6:34 PM, Philip Oakley wrote:\n>\n> Sorry if I'm bikeshedding here, but it does look like adding an alternate\n> 'bisect' strategy may be useful for this style of integration testing.\n>\n> To me, given the multiplicity of independent branches being brought\n> together, it should be possible to do a check on each of the branches\n> separately, before the tests along the line of integration . The tests would\n> not be a true 'bisection' as they are separate single point tests, but they\n> do establish good commits at the tips of those branches.\n>\n> Thus, for each of the merges in the --first-parent traversal, the option\n> could test (in the OS of choice) the *second parent* commit of the merge.\n> This sets the known good points. The breakages during the integration then\n> become easier to bisect, as it is only looking for the integration of a good\n> series into mainline that breaks. [1]\n\nI think what you suggest is very similar in practice as the\n--first-parent strategy that we have been suggesting for some years to\nadd to bisect as a GSoC project:\n\nhttps://git.github.io/SoC-2017-Ideas/\n\n> In addition, an aside that dscho made earlier about the merge-base of some\n> branches relative to Windows may have been missed. The normal bisect process\n> assumes that we start from a set of good merge bases.\n\nWhen a good commit is not an ancestor of the bad commit, we test the\nmerge bases first and we abort if one of them is not good.\n\n> However, dscho noticed\n> that occasionally some series may choose an older point on maint (etc.) that\n> itself would _not_ be classed as good when tested on Windows (or on other\n> OS's). Those older mergebases can make the classic bisect across all the\n> commits in the DAG between here and there a tortuous process, especially if\n> the local OS implementation percieves the base points as bad! (which breaks\n> expectations).\n\nMy understanding of the bisecting problem that Dscho is reporting is\nthat the process is sometimes buggy or tortuous because bisect is not\nsmart enough to optimize the testing of the merge bases when there are\na lot of them.\n\nIt is not because bisect expects or assumes that some merge bases are\ngood or bad when in fact they are not.\n"},{"id":"317779","messageId":"3bd4a2d7-ada9-6198-8cf1-573d80cae1b4@kdbg.org","threadId":"45752","inReplyTo":"CAP8UFD1r9TFE9ns5pobDOpugF8MBiJAYgrRALCqGVmgWud=QjQ@mail.gmail.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-04-25T05:51:51Z","receivedAt":"2017-04-25T05:52:00Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 25.04.2017 um 04:00 schrieb Christian Couder:\n> On Sat, Apr 22, 2017 at 3:37 PM, Johannes Sixt wrote:\n>> Am 21.04.2017 um 14:29 schrieb Christian Couder:\n>>>\n>>> First bisect should ask you to test merge bases only if there are\n>>> \"good\" commits that are not ancestors of the \"bad\" commit.\n>>\n>>\n>> That's a tangent, but I have never understood why this needs to be so.\n>> Consider this:\n>>\n>> o--o--o--o--o--o--o--o--B\n>> / /\n>> -o--o--o--o--g--o--o--o--o--G\n>>\n>> When I mark B as bad and G as good, why would g have to be tested first?\n>\n> It is because g could be bad if the bug has been fixed between g and G.\n> If this happens and we don't test g, we would give a wrong result.\n\nGah! So, a typical messy workflow \"requires\" this behavior. A clean \nbranchy workflow like Git's does not because we know that a breakage is \neither on a topic branch, B, or a (the?) bad commit is an ancester of \n(the integration branch) G.\n\n>\n>> This is exactly what I do when I bisect in Git history: I mark the latest\n>> commits on git-gui and gitk sub-histories as good, because I know they can't\n>> possibly be bad. (In my setup, these two histories are ahead of pu and\n>> next.)\n>\n> Yeah, it is safe to do that in this case as we test the merge bases.\n\nThe idea of marking git-gui and gitk histories that none of their \ncommits is checked out: it erases all Git source code from the working \ndirectory, and a later bisection step places all code back and it \nrequires a full build. Not a big deal with Git, but there are much \nlarger code bases.\n\nThe current bisect behavior makes this idea unworkable. For me, it was a \nbig step backwards when it was implemented. :-(\n\n-- Hannes\n\n"},{"id":"317786","messageId":"xmqqa875uggj.fsf@gitster.mtv.corp.google.com","threadId":"45752","inReplyTo":"3bd4a2d7-ada9-6198-8cf1-573d80cae1b4@kdbg.org","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-25T06:52:28Z","receivedAt":"2017-04-25T06:52:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> The idea of marking git-gui and gitk histories that none of their\n> commits is checked out: it erases all Git source code from the working\n> directory, and a later bisection step places all code back and it\n> requires a full build. Not a big deal with Git, but there are much\n> larger code bases.\n>\n> The current bisect behavior makes this idea unworkable. For me, it was\n> a big step backwards when it was implemented. :-(\n\nI think it is sort-of unfair to blame bisect for that. It talks\nmore about how \"coolest merge evar!\" cross project merges are\nunworkable in practice. With a proper submodule support, nobody\nshould be doing it, but we started the cross project merge way\nbefore we had submodules, so...\n"},{"id":"317825","messageId":"1336f7a6-4785-d60d-d100-df38e22aa9e8@kdbg.org","threadId":"45752","inReplyTo":"xmqqa875uggj.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-04-25T18:26:52Z","receivedAt":"2017-04-25T18:27:11Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 25.04.2017 um 08:52 schrieb Junio C Hamano:\n> Johannes Sixt writes:\n>\n>> The idea of marking git-gui and gitk histories that none of their\n>> commits is checked out: it erases all Git source code from the working\n>> directory, and a later bisection step places all code back and it\n>> requires a full build. Not a big deal with Git, but there are much\n>> larger code bases.\n>>\n>> The current bisect behavior makes this idea unworkable. For me, it was\n>> a big step backwards when it was implemented. :-(\n>\n> I think it is sort-of unfair to blame bisect for that. It talks\n> more about how \"coolest merge evar!\" cross project merges are\n> unworkable in practice.\n\nNo, it has nothing to do with the \"coolest merge ever\". The same problem \noccurs when I'm working on a topic branch:\n\n A--....--B <- topic\n /\n --g--....--G <- integration branch (\"good by default\")\n\nWhile fiddling with B, I find a bug and suspect it somewhere on the \ntopic from A to B. When A has a change that causes a substantial or \ncomplete rebuild, testing g causes burden for no good reason.\n\nBut, as I said, this is a tangent. I have no mission to change git bisect.\n\n-- Hannes\n\n"}]}