{"thread":{"id":"40918","subject":"What's cooking in git.git (Dec 2015, #01; Tue, 1)","startedAt":"2015-12-02T00:24:50Z","lastAt":"2015-12-08T10:05:34Z","messageCount":12,"participants":["Jeff King","Junio C Hamano","David Turner","brian m. carlson","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"273887","messageId":"20151202002450.GA27994@sigill.intra.peff.net","threadId":"40918","inReplyTo":null,"subject":"What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-12-02T00:24:50Z","receivedAt":"2015-12-02T00:24:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"What's cooking in git.git (Dec 2015, #01; Tue, 1)\n--------------------------------------------------\n\nHere 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'.\n\nThis should by my final whats-cooking before handing things back to\nJunio. Thanks all for review help and for your patience during the past\nfew weeks.\n\nYou can find the normal integration branches at:\n\n    https://github.com/git/git/\n\nand all topic branches at:\n\n    https://github.com/peff/git/\n\nBut note that I will _not_ be pushing to kernel.org.\n\n--------------------------------------------------\n[New Topics]\n\n* bc/object-id (2015-11-20) 12 commits\n - remote: convert functions to struct object_id\n - Remove get_object_hash.\n - Convert struct object to object_id\n - Add several uses of get_object_hash.\n - object: introduce get_object_hash macro.\n - ref_newer: convert to use struct object_id\n - push_refs_with_export: convert to struct object_id\n - get_remote_heads: convert to struct object_id\n - parse_fetch: convert to use struct object_id\n - add_sought_entry_mem: convert to struct object_id\n - Convert struct ref to use object_id.\n - sha1_file: introduce has_object_file helper.\n\n More transition from \"unsigned char[40]\" to \"struct object_id\".\n\n This needed a few merge fixups, but is mostly disentangled from other\n topics.\n\n Will merge to 'next'.\n\n\n* dt/fsck-verify-pack-error (2015-12-01) 1 commit\n - verify_pack: do not ignore return value of verification function\n\n The exit code of git-fsck would not reflect some types of errors found\n in packed objects.\n\n Will merge to 'next'.\n\n\n* kn/ref-filter-atom-parsing (2015-12-01) 10 commits\n - ref-filter: introduce objectname_atom_parser()\n - ref-filter: introduce contents_atom_parser()\n - ref-filter: introduce remote_ref_atom_parser()\n - ref-filter: introduce align_atom_parser()\n - strbuf: introduce strbuf_split_str_without_term()\n - ref-filter: introduce color_atom_parser()\n - ref-filter: skip deref specifier in match_atom_name()\n - ref-fitler: bump match_atom() name to the top\n - ref-filter: introduce struct used_atom\n - ref-filter: introduce a parsing function for each atom in valid_atom\n\n Refactoring of ref-filter's format-parsing code, in preparation\n for \"branch --format\" and friends.\n\n This replaces (for now) kn/for-each-ref-remainder, which will be built\n on top.\n\n Waiting for review.\n\n\n* ls/travis-yaml (2015-11-28) 1 commit\n - Add Travis CI support\n\n Provides the necessary infrastructure to build topics using the free\n Travis CI. Developers forking from this topic (and enabling Travis) can\n do their own builds, and we can turn on auto-builds for git/git\n (including build-status for pull requests that people open).\n\n I'm inclined to merge this up, as the worst case is that it becomes\n dormant cruft in the repository root.\n\n Will merge to 'next'.\n\n\n* rs/status-detached-head-memcmp (2015-11-28) 1 commit\n - wt-status: correct and simplify check for detached HEAD\n\n Fix some string-matching corner cases when digging in the reflog for\n \"git status\".\n\n Will merge to 'next', then 'maint'.\n\n\n* sg/lock-file-commit-error (2015-12-01) 1 commit\n - Make error message after failing commit_lock_file() less confusing\n\n Cosmetic improvement to lock-file error messages.\n\n Comments on the new messages?\n\n Will merge to 'next' after giving time for bikeshedding.\n\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* ar/doc-env-variable-format (2015-11-11) 1 commit\n  (merged to 'next' on 2015-11-24 at 5ddf33e)\n + Documentation: make environment variable formatting more consistent\n\n Minor documentation fixup.\n\n Will merge to 'master'.\n\n\n* cb/hook-sigpipe (2015-11-16) 1 commit\n  (merged to 'next' on 2015-11-24 at 0bf4228)\n + allow hooks to ignore their standard input stream\n\n We now consistently allow all hooks to ignore their standard input,\n rather than having git complain of SIGPIPE.\n\n Will merge to 'master'.\n\n\n* cb/ssl-config-pathnames (2015-11-24) 1 commit\n  (merged to 'next' on 2015-11-24 at 658a9c9)\n + http: treat config options sslCAPath and sslCAInfo as paths\n\n Allow tilde-expansion in some http config variables.\n\n Will merge to 'master'.\n\n\n* dg/subtree-test-cleanup (2015-11-13) 7 commits\n  (merged to 'next' on 2015-11-24 at 1297941)\n + contrib/subtree: Handle '--prefix' argument with a slash appended\n + contrib/subtree: Make each test self-contained\n + contrib/subtree: Add split tests\n + contrib/subtree: Add merge tests\n + contrib/subtree: Add tests for subtree add\n + contrib/subtree: Add test for missing subtree\n + contrib/subtree: Clean and refactor test code\n\n Test cleanups for the subtree project.\n\n Will merge to 'master'.\n\n\n* dk/check-ignore-docs (2015-11-24) 1 commit\n  (merged to 'next' on 2015-11-24 at 0cce5c5)\n + check-ignore: correct documentation about output\n\n Documentation clarification for \"check-ignore\" without \"--verbose\".\n\n Will merge to 'master'.\n\n\n* dk/rerere-train-quoting (2015-11-20) 1 commit\n  (merged to 'next' on 2015-11-24 at f9fa96e)\n + Escape Git's exec path in contrib/rerere-train.sh script\n\n Fix shell quoting in contrib script.\n\n Will merge to 'master'.\n\n\n* dk/t5813-unc-paths (2015-11-20) 1 commit\n  (merged to 'next' on 2015-11-24 at 204e4a8)\n + t5813: avoid creating urls that break on cygwin\n\n Test portability fix for a topic in v2.6.1.\n\n Will merge to 'master'.\n\n\n* dt/http-range (2015-11-11) 1 commit\n  (merged to 'next' on 2015-11-24 at d342999)\n + http: fix some printf format warnings\n\n Portability fix for a topic already in 'master'.\n\n Will merge to 'master'.\n\n\n* eg/p4-submit-catch-failure (2015-11-24) 1 commit\n  (merged to 'next' on 2015-11-24 at cf2dc76)\n + git-p4: clean up after p4 submit failure\n\n Just like the working tree is cleaned up when the user cancelled\n submission in P4Submit.applyCommit(), clean up the mess if \"p4\n submit\" fails.\n\n Will merge to 'master'.\n\n\n* fm/shell-path-whitespace (2015-11-13) 1 commit\n  (merged to 'next' on 2015-11-24 at c2b8bdf)\n + rebase-i-exec: Allow space in SHELL_PATH\n\n Portability fix for Windows, which may rewrite $SHELL variable using\n non-POSIX paths.\n\n Will merge to 'master'.\n\n\n* jk/send-email-ca-path (2015-11-24) 1 commit\n  (merged to 'next' on 2015-11-24 at 923b803)\n + send-email: die if CA path doesn't exist\n\n Use a safer behavior when we hit errors verifying remote certificates.\n\n Will merge to 'master'.\n\n\n* jk/send-email-expand-paths (2015-11-20) 1 commit\n  (merged to 'next' on 2015-11-24 at d32fa4d)\n + send-email: expand path in sendemail.smtpsslcertpath config\n\n Expand paths in some send-email config variables.\n\n Will merge to 'master'.\n\n\n* js/test-modernize-t9300 (2015-11-20) 7 commits\n  (merged to 'next' on 2015-11-24 at d399494)\n + modernize t9300: move test preparations into test_expect_success\n + modernize t9300: mark here-doc words to ignore tab indentation\n + modernize t9300: use test_when_finished for clean-up\n + modernize t9300: wrap lines after &&\n + modernize t9300: use test_must_be_empty\n + modernize t9300: use test_must_fail\n + modernize t9300: single-quote placement and indentation\n\n Clean up style in an ancient test.\n\n Will merge to 'master'.\n\n\n* ld/p4-detached-head (2015-11-24) 3 commits\n  (merged to 'next' on 2015-11-24 at 36ab36a)\n + git-p4: work with a detached head\n + git-p4: add option to system() to return subshell status\n + git-p4: add failing test for submit from detached head\n\n Make git-p4 work on a detached head.\n\n Will merge to 'master'.\n\n\n* ls/p4-test-timeouts (2015-11-20) 3 commits\n  (merged to 'next' on 2015-11-24 at 905cff8)\n + git-p4: add trap to kill p4d on test exit\n + git-p4: add p4d timeout in tests\n + git-p4: retry kill/cleanup operations in tests with timeout\n\n Work around some test flakiness with p4d.\n\n Will merge to 'master'.\n\n\n* mg/doc-word-diff-example (2015-11-24) 1 commit\n  (merged to 'next' on 2015-11-24 at 5ba28db)\n + Documentation/diff: give --word-diff-regex=. example\n\n Will merge to 'master'.\n\n\n* mk/blame-first-parent (2015-11-24) 1 commit\n  (merged to 'next' on 2015-11-24 at a2ee2a4)\n + blame: fix object casting regression\n\n Regression fix for a topic already in master.\n\n Will merge to 'master'.\n\n\n* pt/http-socks-proxy (2015-11-20) 1 commit\n  (merged to 'next' on 2015-11-20 at dc6ae48)\n + remote-http(s): support SOCKS proxies\n\n Add support for talking http/https over socks proxy.\n\n Will merge to 'master'.\n\n\n* rs/fsck-nul-header (2015-11-20) 2 commits\n  (merged to 'next' on 2015-11-24 at 093b3d6)\n + fsck: treat a NUL in a tag header as an error\n + t1450: add tests for NUL in headers of commits and tags\n\n Fsck did not correctly detect a NUL-truncated header in a tag.\n\n Will merge to 'master'.\n\n\n* sg/filter-branch-dwim-ambiguity (2015-11-24) 1 commit\n  (merged to 'next' on 2015-11-24 at fe596a6)\n + filter-branch: deal with object name vs. pathname ambiguity in tree-filter\n\n Fix for a corner case in filter-branch.\n\n Will merge to 'master'.\n\n--------------------------------------------------\n[Stalled]\n\n* nd/ita-cleanup (2015-09-06) 6 commits\n - grep: make it clear i-t-a entries are ignored\n - checkout(-index): do not checkout i-t-a entries\n - apply: make sure check_preimage() does not leave empty file on error\n - apply: fix adding new files on i-t-a entries\n - add and use a convenience macro ce_intent_to_add()\n - blame: remove obsolete comment\n\n Paths that have been told the index about with \"add -N\" are not yet\n in the index, but various commands behaved as if they already are.\n\n Some commits need better explanation.\n\n Waiting for a reroll.\n\n\n* mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits\n - t/lib-git-svn: check same httpd module dirs as lib-httpd\n - t/lib-httpd: load mod_unixd\n\n This is the first two commits in a three-patch series $gmane/266962\n\n Becoming tired of waiting for a reroll.\n with updated log message ($gmane/268061).\n\n\n* wp/sha1-name-negative-match (2015-06-08) 2 commits\n - sha1_name.c: introduce '^{/!-<negative pattern>}' notation\n - test for '!' handling in rev-parse's named commits\n\n Introduce \"branch^{/!-<pattern>}\" notation to name a commit\n reachable from branch that does not match the given pattern.\n\n Becoming tired of waiting for a reroll.\n ($gmane/271213).\n\n\n* ak/format-patch-odir-config (2015-06-19) 1 commit\n - format-patch: introduce format.outputDirectory configuration\n\n Reroll exists but didn't pick it up as it seemed to be still\n collecting review comments.\n\n Becoming tired of waiting for a reroll.\n ($gmane/272180).\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--------------------------------------------------\n[Cooking]\n\n* bb/merge-marker-crlf (2015-11-24) 1 commit\n - merge-file: consider core.crlf when writing merge markers\n\n Write out merge markers using system end-of-line convention.\n\n Waiting for a re-roll to handle gitattributes.\n\n\n* dk/gc-more-wo-pack (2015-11-24) 3 commits\n - gc: Clean garbage .bitmap files from pack dir\n - t5304: Add test for .bitmap garbage files\n - prepare_packed_git(): find more garbage\n\n Follow-on to dk/gc-idx-wo-pack topic, to clean up stale\n .bitmap and .keep files.\n\n Waiting for review.\n\n\n* jk/send-email-ssl-errors (2015-11-24) 1 commit\n - send-email: enable SSL level 1 debug output\n\n Improve error reporting when SMTP TLS fails.\n\n Waiting for re-roll.\n\n\n* mr/ff-refs (2015-11-28) 6 commits\n - builtin/ff-refs.c: mark some file-local variables static\n - ff-refs: Add tests\n - ff-refs: Add documentation\n - ff-refs: add --dry-run and --skip-worktree options\n - ff-refs: update each updatable ref\n - ff-refs: builtin cmd to check and fast forward local refs to their upstream\n\n Specialized command to fast-forward refs to match their upstream.\n\n I remain skeptical that this is necessary or sufficient. Comments\n welcome.\n\n Will hold.\n\n\n* ps/rebase-keep-empty (2015-11-24) 2 commits\n - rebase: fix preserving commits with --keep-empty\n - rebase: test broken behavior with --keep-empty\n\n Keep duplicate commits via rebase --keep-empty.\n\n I'm not sure if I agree with this interpretation of the \"rebase\n --keep-empty\" documentation, but I haven't thought too hard about it.\n Comments welcome.\n\n Waiting for review.\n\n\n* rm/subtree-unwrap-tags (2015-11-24) 1 commit\n - contrib/subtree: unwrap tag refs\n\n Waiting for review from subtree folks.\n\n\n* sg/bash-prompt-dirty-orphan (2015-11-24) 3 commits\n  (merged to 'next' on 2015-11-24 at ac6eb1c)\n + bash prompt: indicate dirty index even on orphan branches\n + bash prompt: remove a redundant 'git diff' option\n + bash prompt: test dirty index and worktree while on an orphan branch\n\n Produce correct \"dirty\" marker for shell prompts, even when we\n are on an orphan branch.\n\n Will merge to 'master'.\n\n\n* sg/sh-require-clean-orphan (2015-11-24) 2 commits\n - sh-setup: make require_clean_work_tree() work on orphan branches\n - Add tests for git-sh-setup's require_clean_work_tree()\n\n Allow users of git-sh-setup to handle orphan branch state.\n\n This series takes the conservative route of requiring scripts to opt\n into the looser behavior, at the expense of carrying around a new\n option-flag forever. I'm not sure if we need to do so. Comments\n welcome.\n\n Waiting for re-roll?\n\n\n* tb/ls-files-eol (2015-11-28) 2 commits\n - convert.c: mark a file-local function static\n - ls-files: Add eol diagnostics\n\n Add options to ls-files to help diagnose end-of-line problems.\n\n This latest round hasn't gotten any review yet.\n\n Waiting for review.\n\n\n* ec/annotate-deleted (2015-11-20) 1 commit\n - annotate: skip checking working tree if a revision is provided\n\n Usability fix for annotate-specific \"<file> <rev>\" syntax with deleted\n files.\n\n Needs review.\n\n\n* jk/filter-branch-no-index (2015-11-06) 1 commit\n  (merged to 'next' on 2015-11-24 at e31946e)\n + filter-branch: skip index read/write when possible\n\n Speed up filter-branch for cases where we only care about rewriting\n commits, not tree data.\n\n Will merge to 'master'.\n\n\n* jk/send-email-complete-aliases (2015-11-20) 2 commits\n  (merged to 'next' on 2015-11-24 at a50094f)\n + completion: add support for completing email aliases\n + sendemail: teach git-send-email to dump alias names\n\n Teach send-email to dump mail aliases, so that we can do tab completion\n on the command line.\n\n Will merge to 'master'.\n\n\n* ls/test-must-fail-sigpipe (2015-11-28) 2 commits\n  (merged to 'next' on 2015-12-01 at d374686)\n + add \"ok=sigpipe\" to test_must_fail and use it to fix flaky tests\n + implement test_might_fail using a refactored test_must_fail\n\n Fix some racy client/server tests by treating SIGPIPE the same as a\n normal non-zero exit.\n\n Will merge to 'master' two cycles from now.\n\n\n* mc/push-recurse-submodules-config (2015-11-20) 1 commit\n  (merged to 'next' on 2015-11-24 at 3644d4b)\n + push: add recurseSubmodules config option\n\n Add new config to avoid typing \"--recurse-submodules\" on each push.\n\n Waiting for review from submodule folks.\n\n\n* np/credential-cache-sighup (2015-11-20) 1 commit\n  (merged to 'next' on 2015-11-24 at 410167f)\n + credential-cache: new option to ignore sighup\n\n Workaround for using credential-cache with emacs.\n\n Will merge to 'master'.\n\n\n* rs/parseopt-short-help (2015-11-20) 5 commits\n  (merged to 'next' on 2015-11-24 at f22b6e0)\n + show-ref: stop using PARSE_OPT_NO_INTERNAL_HELP\n + grep: stop using PARSE_OPT_NO_INTERNAL_HELP\n + parse-options: allow -h as a short option\n + parse-options: inline parse_options_usage() at its only remaining caller\n + parse-options: deduplicate parse_options_usage() calls\n\n Make \"-h\" command line option work more consistently in all commands.\n\n Will merge to 'master'.\n\n\n* dt/refs-backend-pre-vtable (2015-11-20) 10 commits\n  (merged to 'next' on 2015-11-24 at 8fd7293)\n + refs: break out ref conflict checks\n + files_log_ref_write: new function\n + initdb: make safe_create_dir public\n + refs: split filesystem-based refs code into a new file\n + refs/refs-internal.h: new header file\n + refname_is_safe(): improve docstring\n + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()\n + copy_msg(): rename to copy_reflog_msg()\n + verify_refname_available(): new function\n + verify_refname_available(): rename function\n\n Code preparation for pluggable ref backends.\n\n Will merge to 'master' two cycles from now.\n\n\n* ad/sha1-update-chunked (2015-11-05) 2 commits\n  (merged to 'next' on 2015-12-01 at a22bf47)\n + sha1: allow limiting the size of the data passed to SHA1_Update()\n + sha1: provide another level of indirection for the SHA-1 functions\n\n Apple's common crypto implementation of SHA1_Update() does not take\n more than 4GB at a time, and we now have a compile-time workaround\n for it.\n\n Will merge to 'master'.\n\n\n* vl/grep-configurable-threads (2015-11-01) 1 commit\n - grep: add --threads=<num> option and grep.threads configuration\n\n \"git grep\" can now be configured (or told from the command line)\n how many threads to use when searching in the working tree files.\n\n There was some review from Eric.\n\n Waiting for re-roll?\n\n\n* kf/http-proxy-auth-methods (2015-11-04) 3 commits\n . SQUASH???\n . http: use credential API to handle proxy authentication\n . http: allow selection of proxy authentication method\n\n New http.proxyAuthMethod configuration variable can be used to\n specify what authentication method to use, as a way to work around\n proxies that do not give error response expected by libcurl when\n CURLAUTH_ANY is used.  Also, the codepath for proxy authentication\n has been taught to use credential API to store the authentication\n material in user's keyrings.\n\n I ejected this from pu for the moment, as it conflicts with the\n pt/http-socks-proxy topic. That is now in master, so it can\n be re-rolled on top.\n\n Still being worked on.\n ($gmane/280925).\n\n\n* sb/submodule-parallel-update (2015-11-20) 27 commits\n - clone: allow an explicit argument for parallel submodule clones\n - submodule update: expose parallelism to the user\n - git submodule update: have a dedicated helper for cloning\n - fetching submodules: respect `submodule.jobs` config option\n - submodule-config: introduce parse_generic_submodule_config\n - submodule-config: remove name_and_item_from_var\n - submodule-config: drop check against NULL\n - submodule-config: keep update strategy around\n - run_processes_parallel: delimit intermixed task output\n - Merge branch 'rs/daemon-plug-child-leak' into sb/submodule-parallel-update\n - Merge branch 'sb/submodule-parallel-fetch' into sb/submodule-parallel-update\n  (merged to 'next' on 2015-11-20 at 89fc723)\n + strbuf: update documentation for strbuf_read_once()\n + run-command: remove set_nonblocking()\n  (merged to 'next' on 2015-10-23 at 8f04bbd)\n + run-command: fix missing output from late callbacks\n + test-run-command: increase test coverage\n + test-run-command: test for gracefully aborting\n + run-command: initialize the shutdown flag\n + run-command: clear leftover state from child_process structure\n + run-command: fix early shutdown\n  (merged to 'next' on 2015-10-15 at df63590)\n + submodules: allow parallel fetching, add tests and documentation\n + fetch_populated_submodules: use new parallel job processing\n + run-command: add an asynchronous parallel child processor\n + sigchain: add command to pop all common signals\n + strbuf: add strbuf_read_once to read without blocking\n + xread_nonblock: add functionality to read from fds without blocking\n + xread: poll on non blocking fds\n + submodule.c: write \"Fetching submodule <foo>\" to stderr\n (this branch is tangled with sb/submodule-parallel-fetch.)\n\n Builds on top of the \"fetch --recurse-submodules\" work to introduce\n parallel downloading into multiple submodules for \"submodule update\".\n\n Waiting for sb/submodule-parallel-fetch to stabilize.\n\n It would be the cleanest to rebuild sb/submodule-parallel-fetch on\n top of 2.7.0 once it ships and then build this directly on top;\n that way, we do not have to have merges in this topic that\n distracting (besides, some part of the other topic can be updated\n in-place instead of this follow-up topic tweaking them as past\n mistakes and inflexibilities).\n\n I picked up v4 from the list, but it needs review.\n\n\n* jc/strbuf-gets (2015-10-28) 17 commits\n - test-sha1-array: read command stream with strbuf_gets()\n - grep: read -f file with strbuf_gets()\n - send-pack: read list of refs with strbuf_gets()\n - column: read lines with strbuf_gets()\n - cat-file: read batch stream with strbuf_gets()\n - transport-helper: read helper response with strbuf_gets()\n - clone/sha1_file: read info/alternates with strbuf_gets()\n - remote.c: read $GIT_DIR/remotes/* with strbuf_gets()\n - ident.c: read /etc/mailname with strbuf_gets()\n - rev-parse: read parseopt spec with strbuf_gets()\n - revision: read --stdin with strbuf_gets()\n - hash-object: read --stdin-paths with strbuf_gets()\n - mktree: read textual tree representation with strbuf_gets()\n - update-index: read list of paths with strbuf_gets() under --stdin\n - update-index: read --index-info with strbuf_gets()\n - check-attr, check-ignore, checkout-index: read paths with strbuf_gets()\n - strbuf: add strbuf_gets()\n\n Teach codepaths that communicate with users by reading text files\n to be more lenient to editors that write CRLF-terminated lines.\n Note that this is only about communication with Git, like feeding\n list of object names from the standard input instead of from the\n command line, and does not involve files in the working tree.\n\n Waiting for reviews.\n\n\n* ep/ident-with-getaddrinfo (2015-11-28) 1 commit\n  (merged to 'next' on 2015-12-01 at 0775d4c)\n + ident.c: add support for IPv6\n\n A build without NO_IPv6 used to use gethostbyname() when guessing\n user's hostname, instead of getaddrinfo() that is used in other\n codepaths in such a build.\n\n Will merge to 'master' two cycles from now.\n\n\n* mh/notes-allow-reading-treeish (2015-10-08) 3 commits\n  (merged to 'next' on 2015-10-23 at 8a697f0)\n + notes: allow treeish expressions as notes ref\n + Merge branch 'jk/notes-dwim-doc' into next\n + Merge branch 'jc/merge-drop-old-syntax' into next\n (this branch uses jc/merge-drop-old-syntax.)\n\n Some \"git notes\" operations, e.g. \"git log --notes=<note>\", should\n be able to read notes from any tree-ish that is shaped like a notes\n tree, but the notes infrastructure required that the argument must\n be a ref under refs/notes/.  Loosen it to require a valid ref only\n when the operation would update the notes (in which case we must\n have a place to store the updated notes tree, iow, a ref).\n\n As the patch was done on top of the 'drop old-syntax from merge',\n this has to wait until that other topic can graduate, unfortunately.\n It can be redone in a way that does not depend on that topic after\n this cycle, though.\n\n Will keep in 'next'.\n\n\n* jc/mailinfo (2015-10-21) 1 commit\n - mailinfo: ignore in-body header that we do not care about\n\n Some people write arbitrary garbage at the beginning of a piece of\n e-mail (or after -- >8 -- scissors -- >8 -- line) in the commit log\n message and expect them to be discarded, even though \"From:\" and\n \"Subject:\" are the only documented in-body headers that you are\n supposed to have there.  Allow some garbage (specifically, what may\n look like RFC2822 headers like \"MIME-Version: ...\") to be there and\n ignore them.\n\n I have a feeling that that this is a step in a wrong direction.\n Comments?\n\n\n* js/am-3-merge-recursive-direct (2015-10-12) 2 commits\n  (merged to 'next' on 2015-10-23 at dc631e5)\n + am: make a direct call to merge_recursive\n + merge_recursive_options: introduce the \"gently\" flag\n\n The merge_recursive_generic() function has been made a bit safer to\n call from inside a process.  \"git am -3\" was taught to make a direct\n call to the function when falling back to three-way merge.\n\n Being able to make a direct call would be good in general, but as a\n performance thing, we would want to see it backed up by numbers.\n\n I haven't gone through the \"gently\" change with fine toothed comb;\n I can see that the change avoids calling die(), but I haven't made\n sure that the program states (e.g. what's in the in-core index) are\n adjusted sensibly when it returns to the caller instead of dying,\n or the codepaths that used to die() are free of resource leaks.\n The original code certainly did not care the program states at the\n point of dying exactly because it knew it is going to exit, but now\n they have to care, and they need to be audited.\n\n Will keep in 'next'.\n\n\n* sg/pretty-more-date-mode-format (2015-10-07) 1 commit\n - pretty: add format specifiers for short and raw date formats\n\n Introduce \"%as\" and \"%aR\" placeholders for \"log --format\" to show\n the author date in the short and raw formats.\n\n I have a feeling that that this is a step in a wrong direction.\n Comments?\n\n\n* kn/for-each-branch-remainder (2015-10-02) 9 commits\n . branch: implement '--format' option\n . branch: use ref-filter printing APIs\n . ref-filter: make %(upstream:track) prints \"[gone]\" for invalid upstreams\n . ref-filter: introduce format_ref_array_item()\n . ref-filter: adopt get_head_description() from branch.c\n . ref-filter: modify \"%(objectname:short)\" to take length\n . ref-filter: add support for %(path) atom\n . ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)\n . ref-filter: implement %(if), %(then), and %(else) atoms\n\n More unification among \"branch -l\", \"tag -l\" and \"for-each-ref --format\".\n\n Ejected from pu for now, as a re-roll should come on top of\n kn/ref-filter-atom-parsing.\n\n Expecting a reroll.\n ($gmane/278926)\n\n\n* jk/graph-format-padding (2015-09-14) 1 commit\n - pretty: pass graph width to pretty formatting for use in '%>|(N)'\n\n Redefine the way '%>|(N)' padding and the \"--graph\" option\n interacts.  It has been that the available columns to display the\n log message was measured from the edge of the area the graph ended,\n but with this it becomes the beginning of the entire output.\n\n I have a suspicion that 50% of the users would appreciate this\n change, and the remainder see this break their expectation.  If\n that is the case, we might need to introduce a similar but\n different alignment operator so that this new behaviour is\n available to those who want to use it, without negatively affecting\n existing uses.\n\n Undecided.\n ($gmane/278326)\n\n\n* sb/submodule-parallel-fetch (2015-11-24) 17 commits\n - run-command: detect finished children by closed pipe rather than waitpid\n  (merged to 'next' on 2015-11-20 at 89fc723)\n + strbuf: update documentation for strbuf_read_once()\n + run-command: remove set_nonblocking()\n  (merged to 'next' on 2015-10-23 at 8f04bbd)\n + run-command: fix missing output from late callbacks\n + test-run-command: increase test coverage\n + test-run-command: test for gracefully aborting\n + run-command: initialize the shutdown flag\n + run-command: clear leftover state from child_process structure\n + run-command: fix early shutdown\n  (merged to 'next' on 2015-10-15 at df63590)\n + submodules: allow parallel fetching, add tests and documentation\n + fetch_populated_submodules: use new parallel job processing\n + run-command: add an asynchronous parallel child processor\n + sigchain: add command to pop all common signals\n + strbuf: add strbuf_read_once to read without blocking\n + xread_nonblock: add functionality to read from fds without blocking\n + xread: poll on non blocking fds\n + submodule.c: write \"Fetching submodule <foo>\" to stderr\n (this branch is tangled with sb/submodule-parallel-update.)\n\n Add a framework to spawn a group of processes in parallel, and use\n it to run \"git fetch --recurse-submodules\" in parallel.\n\n Will merge top commit to 'next'.\n\n\n* ad/cygwin-wants-rename (2015-08-07) 1 commit\n - config.mak.uname: Cygwin needs OBJECT_CREATION_USES_RENAMES\n\n Will hold.\n ($gmane/275680).\n\n\n* jc/rerere-multi (2015-09-14) 7 commits\n - rerere: do use multiple variants\n - t4200: rerere a merge with two identical conflicts\n - rerere: allow multiple variants to exist\n - rerere: delay the recording of preimage\n - rerere: handle leftover rr-cache/$ID directory and postimage files\n - rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id\n - rerere: split conflict ID further\n\n \"git rerere\" can encounter two or more files with the same conflict\n signature that have to be resolved in different ways, but there was\n no way to record these separate resolutions.\n\n\n* jc/merge-drop-old-syntax (2015-04-29) 1 commit\n  (merged to 'next' on 2015-10-07 at 50fed71)\n + merge: drop 'git merge <message> HEAD <commit>' syntax\n (this branch is used by mh/notes-allow-reading-treeish.)\n\n Originally merged to 'next' on 2015-05-28\n\n Stop supporting \"git merge <message> HEAD <commit>\" syntax that has\n been deprecated since October 2007.  It has been reported that\n git-gui still uses the deprecated syntax, which needs to be fixed\n before this final step can proceed.\n\n Will keep in 'next'.\n"},{"id":"273938","messageId":"xmqq4mg05wmj.fsf@gitster.mtv.corp.google.com","threadId":"40918","inReplyTo":"20151202002450.GA27994@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-02T22:11:32Z","receivedAt":"2015-12-02T22:11:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> What's cooking in git.git (Dec 2015, #01; Tue, 1)\n> --------------------------------------------------\n>\n> Here are the topics that have been cooking.  Commits prefixed with\n> '-' are only in 'pu' (proposed updates) while commits prefixed with\n> '+' are in 'next'.\n>\n> This should by my final whats-cooking before handing things back to\n> Junio. Thanks all for review help and for your patience during the past\n> few weeks.\n\nI think I managed to get my working area (together with a handful of\nnew entries in the rerere database and a few merge-fix/ entries) in\nsync with what you pushed out well enough that my automated\nprocedure would recreate the status of various branches you pushed\nout exactly.\n\nI haven't caught up with the changes in the component branches,\nthough, so it may take a few days until I start picking up new\ntopics from the list traffic.\n\n> * bc/object-id (2015-11-20) 12 commits\n>  - remote: convert functions to struct object_id\n>  - Remove get_object_hash.\n>  - Convert struct object to object_id\n>  - Add several uses of get_object_hash.\n>  - object: introduce get_object_hash macro.\n>  - ref_newer: convert to use struct object_id\n>  - push_refs_with_export: convert to struct object_id\n>  - get_remote_heads: convert to struct object_id\n>  - parse_fetch: convert to use struct object_id\n>  - add_sought_entry_mem: convert to struct object_id\n>  - Convert struct ref to use object_id.\n>  - sha1_file: introduce has_object_file helper.\n>\n>  More transition from \"unsigned char[40]\" to \"struct object_id\".\n>\n>  This needed a few merge fixups, but is mostly disentangled from other\n>  topics.\n>\n>  Will merge to 'next'.\n\nAside from niggles on titles of a handful of changes in this topic,\nI have a bit of concern with this one and dt/refs-backend-pre-vtable\ntopic (marked as \"Will merge to 'master' two cycles from now.\",\nwhich I am reading as \"two cycles\" means 2 x (8-10 week release\ncycle), not \"two integration cycles by the maintainer, aka two\nissues of What's cooking report\", which is typically less than a\nweek).\n\nThe merge resolution in 'pu' discards what this topic did to refs.c\nbecause much of the original goes away from there, but does it mean\n(remember, I haven't caught up with the contents of the topics yet)\nthat the merge reverts part of what this topic did, and in an ideal\nworld, if the other one were more mature when this topic got\nstarted, more use of \"unsigned char[40]\" would have been migrated to\n\"struct object_id\" in new files the other one introduced?  Or\nperhaps we would want to go the other way around, i.e. as this topic\nconceptually is fairly straight-forward, merge this to 'next' and\nthen down to 'master' (which would not take two release cycles) and\nthen redo the other topic on top?\n\n> * mr/ff-refs (2015-11-28) 6 commits\n>  - builtin/ff-refs.c: mark some file-local variables static\n>  - ff-refs: Add tests\n>  - ff-refs: Add documentation\n>  - ff-refs: add --dry-run and --skip-worktree options\n>  - ff-refs: update each updatable ref\n>  - ff-refs: builtin cmd to check and fast forward local refs to their upstream\n>\n>  Specialized command to fast-forward refs to match their upstream.\n>\n>  I remain skeptical that this is necessary or sufficient. Comments\n>  welcome.\n>\n>  Will hold.\n\nThis is another one that needs some evil-merge interaction with\nbc/object-id, but I have a feeling that this is not such a good\naddition to our workflow elements, so I am not worried too much\nabout it.  I'm inclined to eject this topic (and will welcome if\npeople come up with an alternative, perhaps based on the \"let fetch\ndo so instead\" approach discussed there).\n\n> * ps/rebase-keep-empty (2015-11-24) 2 commits\n>  - rebase: fix preserving commits with --keep-empty\n>  - rebase: test broken behavior with --keep-empty\n>\n>  Keep duplicate commits via rebase --keep-empty.\n>\n>  I'm not sure if I agree with this interpretation of the \"rebase\n>  --keep-empty\" documentation, but I haven't thought too hard about it.\n>  Comments welcome.\n\n\"--keep-empty\" has always been about keeping an originally empty\ncommit, not a commit that becomes empty because of rebasing\n(i.e. what has already been applied to the updated base).  The\ndocumentation, if it leads to any other interpretation, needs to be\nfixed.\n\nBesides, if \"--keep-empty\" were to mean \"keep redundant ones that\nare already in the updated base\", the patch must do a lot more,\ne.g. stop filtering with git-cherry patch equivalence.\n\nI'm inclined to eject this topic.\n\n\n> * ls/test-must-fail-sigpipe (2015-11-28) 2 commits\n>   (merged to 'next' on 2015-12-01 at d374686)\n>  + add \"ok=sigpipe\" to test_must_fail and use it to fix flaky tests\n>  + implement test_might_fail using a refactored test_must_fail\n>\n>  Fix some racy client/server tests by treating SIGPIPE the same as a\n>  normal non-zero exit.\n>\n>  Will merge to 'master' two cycles from now.\n\nHmm, perhaps I misread what you meant by \"two cycles\", as this is\nonly the test suite and I cannot imagine we would want to be\nultra-safe to cook that for two release cycles, and you did mean two\nissues of \"What's cooking\" report?\n\nIf so, I'll have to rethink the comment on bc/object-id I made\nearlier...\n\n> * dt/refs-backend-pre-vtable (2015-11-20) 10 commits\n>   (merged to 'next' on 2015-11-24 at 8fd7293)\n>  + refs: break out ref conflict checks\n>  + files_log_ref_write: new function\n>  + initdb: make safe_create_dir public\n>  + refs: split filesystem-based refs code into a new file\n>  + refs/refs-internal.h: new header file\n>  + refname_is_safe(): improve docstring\n>  + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()\n>  + copy_msg(): rename to copy_reflog_msg()\n>  + verify_refname_available(): new function\n>  + verify_refname_available(): rename function\n>\n>  Code preparation for pluggable ref backends.\n>\n>  Will merge to 'master' two cycles from now.\n\n... that is, I'd very much prefer bc/object-id redone on top of an\nupdated codebase that already has dt/refs-backend-pre-vtable in it.\n\nThanks.\n"},{"id":"273939","messageId":"20151202223114.GA20542@sigill.intra.peff.net","threadId":"40918","inReplyTo":"xmqq4mg05wmj.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-12-02T22:31:14Z","receivedAt":"2015-12-02T22:31:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:\n\n> I think I managed to get my working area (together with a handful of\n> new entries in the rerere database and a few merge-fix/ entries) in\n> sync with what you pushed out well enough that my automated\n> procedure would recreate the status of various branches you pushed\n> out exactly.\n> \n> I haven't caught up with the changes in the component branches,\n> though, so it may take a few days until I start picking up new\n> topics from the list traffic.\n\nMy whole workspace is at https://github.com/peff/git, if fetching that\ndirectly is easier. I just noticed that my refspecs were not configured\nto push up refs/merge-fix. I've just fixed that and pushed again.\n\nI'll leave it that way for a few more days, but then will probably take\nit back to my usual contributor setup (i.e., just my topics and personal\nintegration branches).\n\nLet me know if there's anything else I can do to help with the handoff.\n\n> > * bc/object-id (2015-11-20) 12 commits\n> [...]\n> \n> Aside from niggles on titles of a handful of changes in this topic,\n> I have a bit of concern with this one and dt/refs-backend-pre-vtable\n> topic (marked as \"Will merge to 'master' two cycles from now.\",\n> which I am reading as \"two cycles\" means 2 x (8-10 week release\n> cycle), not \"two integration cycles by the maintainer, aka two\n> issues of What's cooking report\", which is typically less than a\n> week).\n\nMy \"two cycles from now\" meant \"two integration cycles\". I seemed to do\nonly about two per week. You can take those all with a grain of salt. It\nwas meant only as a note to myself that the topic seemed risky enough to\nallow extra cooking time in next.\n\nSince your \"Meta/cook -w\" output shows dates of merges, I imagine you\nare in the habit of simply looking at those dates and saying \"eh, this\nhas been in next for 2 weeks and nobody has complained; that's enough\ncooking time\".\n\n> The merge resolution in 'pu' discards what this topic did to refs.c\n> because much of the original goes away from there, but does it mean\n> (remember, I haven't caught up with the contents of the topics yet)\n> that the merge reverts part of what this topic did, and in an ideal\n> world, if the other one were more mature when this topic got\n> started, more use of \"unsigned char[40]\" would have been migrated to\n> \"struct object_id\" in new files the other one introduced?  Or\n> perhaps we would want to go the other way around, i.e. as this topic\n> conceptually is fairly straight-forward, merge this to 'next' and\n> then down to 'master' (which would not take two release cycles) and\n> then redo the other topic on top?\n\nI took the resolution proposed by brian, which was that the refs.c code\nwent away. There was some evil-merge required to make the new\nrefs/files-backend.c compile (in my refs/merge-fix/bc/object-id) for\ncode that moved. I was surprised there wasn't more, but I think it's\nright. We dropped the _users_ of some sha1/object_id transition code\n(which is why it doesn't need more fixup to compile). We did not drop\nany actual function conversions (which might have been wrong but still\ncompiled, if both the function signature and its callers all moved).\n\nAs it's all part of an incremental conversion anyway, my feeling was\nthat it was OK to move forward as long as it wasn't disturbing topics in\nflight (assuming we're agreed on the overall direction, which I think is\nthe case).\n\n> > * mr/ff-refs (2015-11-28) 6 commits\n> [...]\n> \n> This is another one that needs some evil-merge interaction with\n> bc/object-id, but I have a feeling that this is not such a good\n> addition to our workflow elements, so I am not worried too much\n> about it.  I'm inclined to eject this topic (and will welcome if\n> people come up with an alternative, perhaps based on the \"let fetch\n> do so instead\" approach discussed there).\n\nRight. There's another merge-fix for this.\n\nI explicitly put this after bc/object-id (requiring another merge-fix,\nrather than rolling it into the bc/object-id merge fix), because I\nexpected bc/object-id to graduate, and this one to languish in pu or get\nre-rolled.\n\nI agree that ejecting is fine here.\n\n> > * ps/rebase-keep-empty (2015-11-24) 2 commits\n> >  - rebase: fix preserving commits with --keep-empty\n> >  - rebase: test broken behavior with --keep-empty\n> >\n> >  Keep duplicate commits via rebase --keep-empty.\n> >\n> >  I'm not sure if I agree with this interpretation of the \"rebase\n> >  --keep-empty\" documentation, but I haven't thought too hard about it.\n> >  Comments welcome.\n> \n> \"--keep-empty\" has always been about keeping an originally empty\n> commit, not a commit that becomes empty because of rebasing\n> (i.e. what has already been applied to the updated base).  The\n> documentation, if it leads to any other interpretation, needs to be\n> fixed.\n> \n> Besides, if \"--keep-empty\" were to mean \"keep redundant ones that\n> are already in the updated base\", the patch must do a lot more,\n> e.g. stop filtering with git-cherry patch equivalence.\n> \n> I'm inclined to eject this topic.\n\nThat was my thinking too (and I notice it didn't get any review from\nanybody else).\n\n> > * ls/test-must-fail-sigpipe (2015-11-28) 2 commits\n> >   (merged to 'next' on 2015-12-01 at d374686)\n> >  + add \"ok=sigpipe\" to test_must_fail and use it to fix flaky tests\n> >  + implement test_might_fail using a refactored test_must_fail\n> >\n> >  Fix some racy client/server tests by treating SIGPIPE the same as a\n> >  normal non-zero exit.\n> >\n> >  Will merge to 'master' two cycles from now.\n> \n> Hmm, perhaps I misread what you meant by \"two cycles\", as this is\n> only the test suite and I cannot imagine we would want to be\n> ultra-safe to cook that for two release cycles, and you did mean two\n> issues of \"What's cooking\" report?\n\nYes, the latter. Even though it is \"only\" the test suite, it gave us\nenough trouble that I did not want to go to next and then immediately to\nmaster in the next cycle (i.e., I wanted to give people time enough to\ncomplain if it breaks their \"make test\" in next).\n\n> > * dt/refs-backend-pre-vtable (2015-11-20) 10 commits\n> >   (merged to 'next' on 2015-11-24 at 8fd7293)\n> >  + refs: break out ref conflict checks\n> >  + files_log_ref_write: new function\n> >  + initdb: make safe_create_dir public\n> >  + refs: split filesystem-based refs code into a new file\n> >  + refs/refs-internal.h: new header file\n> >  + refname_is_safe(): improve docstring\n> >  + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()\n> >  + copy_msg(): rename to copy_reflog_msg()\n> >  + verify_refname_available(): new function\n> >  + verify_refname_available(): rename function\n> >\n> >  Code preparation for pluggable ref backends.\n> >\n> >  Will merge to 'master' two cycles from now.\n> \n> ... that is, I'd very much prefer bc/object-id redone on top of an\n> updated codebase that already has dt/refs-backend-pre-vtable in it.\n\nI think that is OK to do, though I'm not sure the end result will be\nall that different.\n\n-Peff\n"},{"id":"273942","messageId":"xmqqoae84eci.fsf@gitster.mtv.corp.google.com","threadId":"40918","inReplyTo":"20151202223114.GA20542@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-02T23:31:41Z","receivedAt":"2015-12-02T23:31:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:\n>\n>> I think I managed to get my working area (together with a handful of\n>> new entries in the rerere database and a few merge-fix/ entries) in\n>> sync with what you pushed out well enough that my automated\n>> procedure would recreate the status of various branches you pushed\n>> out exactly.\n>> \n>> I haven't caught up with the changes in the component branches,\n>> though, so it may take a few days until I start picking up new\n>> topics from the list traffic.\n>\n> My whole workspace is at https://github.com/peff/git, if fetching that\n> directly is easier. I just noticed that my refspecs were not configured\n> to push up refs/merge-fix. I've just fixed that and pushed again.\n>\n> I'll leave it that way for a few more days, but then will probably take\n> it back to my usual contributor setup (i.e., just my topics and personal\n> integration branches).\n\nThanks.  I haven't re-fetched from you, but I think I am good.\n\n> My \"two cycles from now\" meant \"two integration cycles\". I seemed to do\n> only about two per week. You can take those all with a grain of salt. It\n> was meant only as a note to myself that the topic seemed risky enough to\n> allow extra cooking time in next.\n>\n> Since your \"Meta/cook -w\" output shows dates of merges, I imagine you\n> are in the habit of simply looking at those dates and saying \"eh, this\n> has been in next for 2 weeks and nobody has complained; that's enough\n> cooking time\".\n\nYup ;-)\n\n> (which is why it doesn't need more fixup to compile). We did not drop\n> any actual function conversions (which might have been wrong but still\n> compiled, if both the function signature and its callers all moved).\n\nOK, good to know.\n\nI just finished my first pass of going through \"cook -w\" output and\nhad trouble judging jk/send-email-ssl-errors topic, which is marked\nas \"waiting for re-roll\", but I cannot seem to find any discussion\non it, just the original patch $gmane/281655.  Are there concerns?\n"},{"id":"273943","messageId":"20151203000705.GA22067@sigill.intra.peff.net","threadId":"40918","inReplyTo":"xmqqoae84eci.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-12-03T00:07:05Z","receivedAt":"2015-12-03T00:07:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 02, 2015 at 03:31:41PM -0800, Junio C Hamano wrote:\n\n> I just finished my first pass of going through \"cook -w\" output and\n> had trouble judging jk/send-email-ssl-errors topic, which is marked\n> as \"waiting for re-roll\", but I cannot seem to find any discussion\n> on it, just the original patch $gmane/281655.  Are there concerns?\n\nLooks like it needs a slight tweak:\n\n  http://article.gmane.org/gmane.comp.version-control.git/281693\n\n-Peff\n"},{"id":"273944","messageId":"xmqqk2ow4cfj.fsf@gitster.mtv.corp.google.com","threadId":"40918","inReplyTo":"20151203000705.GA22067@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-03T00:13:04Z","receivedAt":"2015-12-03T00:13:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Dec 02, 2015 at 03:31:41PM -0800, Junio C Hamano wrote:\n>\n>> I just finished my first pass of going through \"cook -w\" output and\n>> had trouble judging jk/send-email-ssl-errors topic, which is marked\n>> as \"waiting for re-roll\", but I cannot seem to find any discussion\n>> on it, just the original patch $gmane/281655.  Are there concerns?\n>\n> Looks like it needs a slight tweak:\n>\n>   http://article.gmane.org/gmane.comp.version-control.git/281693\n>\n> -Peff\n\nThanks.  I added a note to myself after the \"waiting for re-roll\"\ncomment to remind me.\n"},{"id":"273945","messageId":"1449102580.14908.2.camel@twopensource.com","threadId":"40918","inReplyTo":"xmqq4mg05wmj.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"David Turner","fromEmail":"dturner@twopensource.com","sentAt":"2015-12-03T00:29:40Z","receivedAt":"2015-12-03T00:29:40Z","isPatch":false,"sender":{"key":"novalis@novalis.org","avatar":"https://avatars.githubusercontent.com/u/77003?v=4"},"body":"On Wed, 2015-12-02 at 14:11 -0800, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n> > What's cooking in git.git (Dec 2015, #01; Tue, 1)\n> > --------------------------------------------------\n> >\n> > Here are the topics that have been cooking.  Commits prefixed with\n> > '-' are only in 'pu' (proposed updates) while commits prefixed with\n> > '+' are in 'next'.\n> >\n> > This should by my final whats-cooking before handing things back to\n> > Junio. Thanks all for review help and for your patience during the past\n> > few weeks.\n> \n> I think I managed to get my working area (together with a handful of\n> new entries in the rerere database and a few merge-fix/ entries) in\n> sync with what you pushed out well enough that my automated\n> procedure would recreate the status of various branches you pushed\n> out exactly.\n> \n> I haven't caught up with the changes in the component branches,\n> though, so it may take a few days until I start picking up new\n> topics from the list traffic.\n> \n> > * bc/object-id (2015-11-20) 12 commits\n> >  - remote: convert functions to struct object_id\n> >  - Remove get_object_hash.\n> >  - Convert struct object to object_id\n> >  - Add several uses of get_object_hash.\n> >  - object: introduce get_object_hash macro.\n> >  - ref_newer: convert to use struct object_id\n> >  - push_refs_with_export: convert to struct object_id\n> >  - get_remote_heads: convert to struct object_id\n> >  - parse_fetch: convert to use struct object_id\n> >  - add_sought_entry_mem: convert to struct object_id\n> >  - Convert struct ref to use object_id.\n> >  - sha1_file: introduce has_object_file helper.\n> >\n> >  More transition from \"unsigned char[40]\" to \"struct object_id\".\n> >\n> >  This needed a few merge fixups, but is mostly disentangled from other\n> >  topics.\n> >\n> >  Will merge to 'next'.\n> \n> Aside from niggles on titles of a handful of changes in this topic,\n> I have a bit of concern with this one and dt/refs-backend-pre-vtable\n> topic (marked as \"Will merge to 'master' two cycles from now.\",\n> which I am reading as \"two cycles\" means 2 x (8-10 week release\n> cycle), not \"two integration cycles by the maintainer, aka two\n> issues of What's cooking report\", which is typically less than a\n> week).\n> \n> The merge resolution in 'pu' discards what this topic did to refs.c\n> because much of the original goes away from there, but does it mean\n> (remember, I haven't caught up with the contents of the topics yet)\n> that the merge reverts part of what this topic did, and in an ideal\n> world, if the other one were more mature when this topic got\n> started, more use of \"unsigned char[40]\" would have been migrated to\n> \"struct object_id\" in new files the other one introduced?  Or\n> perhaps we would want to go the other way around, i.e. as this topic\n> conceptually is fairly straight-forward, merge this to 'next' and\n> then down to 'master' (which would not take two release cycles) and\n> then redo the other topic on top?\n> \n> > * mr/ff-refs (2015-11-28) 6 commits\n> >  - builtin/ff-refs.c: mark some file-local variables static\n> >  - ff-refs: Add tests\n> >  - ff-refs: Add documentation\n> >  - ff-refs: add --dry-run and --skip-worktree options\n> >  - ff-refs: update each updatable ref\n> >  - ff-refs: builtin cmd to check and fast forward local refs to their upstream\n> >\n> >  Specialized command to fast-forward refs to match their upstream.\n> >\n> >  I remain skeptical that this is necessary or sufficient. Comments\n> >  welcome.\n> >\n> >  Will hold.\n> \n> This is another one that needs some evil-merge interaction with\n> bc/object-id, but I have a feeling that this is not such a good\n> addition to our workflow elements, so I am not worried too much\n> about it.  I'm inclined to eject this topic (and will welcome if\n> people come up with an alternative, perhaps based on the \"let fetch\n> do so instead\" approach discussed there).\n> \n> > * ps/rebase-keep-empty (2015-11-24) 2 commits\n> >  - rebase: fix preserving commits with --keep-empty\n> >  - rebase: test broken behavior with --keep-empty\n> >\n> >  Keep duplicate commits via rebase --keep-empty.\n> >\n> >  I'm not sure if I agree with this interpretation of the \"rebase\n> >  --keep-empty\" documentation, but I haven't thought too hard about it.\n> >  Comments welcome.\n> \n> \"--keep-empty\" has always been about keeping an originally empty\n> commit, not a commit that becomes empty because of rebasing\n> (i.e. what has already been applied to the updated base).  The\n> documentation, if it leads to any other interpretation, needs to be\n> fixed.\n> \n> Besides, if \"--keep-empty\" were to mean \"keep redundant ones that\n> are already in the updated base\", the patch must do a lot more,\n> e.g. stop filtering with git-cherry patch equivalence.\n> \n> I'm inclined to eject this topic.\n> \n> \n> > * ls/test-must-fail-sigpipe (2015-11-28) 2 commits\n> >   (merged to 'next' on 2015-12-01 at d374686)\n> >  + add \"ok=sigpipe\" to test_must_fail and use it to fix flaky tests\n> >  + implement test_might_fail using a refactored test_must_fail\n> >\n> >  Fix some racy client/server tests by treating SIGPIPE the same as a\n> >  normal non-zero exit.\n> >\n> >  Will merge to 'master' two cycles from now.\n> \n> Hmm, perhaps I misread what you meant by \"two cycles\", as this is\n> only the test suite and I cannot imagine we would want to be\n> ultra-safe to cook that for two release cycles, and you did mean two\n> issues of \"What's cooking\" report?\n> \n> If so, I'll have to rethink the comment on bc/object-id I made\n> earlier...\n> \n> > * dt/refs-backend-pre-vtable (2015-11-20) 10 commits\n> >   (merged to 'next' on 2015-11-24 at 8fd7293)\n> >  + refs: break out ref conflict checks\n> >  + files_log_ref_write: new function\n> >  + initdb: make safe_create_dir public\n> >  + refs: split filesystem-based refs code into a new file\n> >  + refs/refs-internal.h: new header file\n> >  + refname_is_safe(): improve docstring\n> >  + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()\n> >  + copy_msg(): rename to copy_reflog_msg()\n> >  + verify_refname_available(): new function\n> >  + verify_refname_available(): rename function\n> >\n> >  Code preparation for pluggable ref backends.\n> >\n> >  Will merge to 'master' two cycles from now.\n> \n> ... that is, I'd very much prefer bc/object-id redone on top of an\n> updated codebase that already has dt/refs-backend-pre-vtable in it.\n\n>From a selfish perspective, I, would prefer for object-ids to not happen\nquite yet for the refs code.  I have already prepared (but not yet sent)\na new version of the refs backend vtable (and lmdb) code on top of\nrefs-backend-pre-vtable, and it'll be a hassle to reroll it on top of\nnew object-id stuff.\n\nI guess I'll go ahead and send mine now, and we can later make a\ndecision about how to deal with the object-id stuff.\n"},{"id":"273963","messageId":"xmqqtwo0tk24.fsf@gitster.mtv.corp.google.com","threadId":"40918","inReplyTo":"20151202223114.GA20542@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-03T01:09:07Z","receivedAt":"2015-12-03T01:09:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:\n>\n>> I think I managed to get my working area (together with a handful of\n>> new entries in the rerere database and a few merge-fix/ entries) in\n>> sync with what you pushed out well enough that my automated\n>> procedure would recreate the status of various branches you pushed\n>> out exactly.\n>> \n>> I haven't caught up with the changes in the component branches,\n>> though, so it may take a few days until I start picking up new\n>> topics from the list traffic.\n>\n> My whole workspace is at https://github.com/peff/git, if fetching that\n> directly is easier. I just noticed that my refspecs were not configured\n> to push up refs/merge-fix. I've just fixed that and pushed again.\n>\n> I'll leave it that way for a few more days, but then will probably take\n> it back to my usual contributor setup (i.e., just my topics and personal\n> integration branches).\n>\n> Let me know if there's anything else I can do to help with the handoff.\n\nI've rebuilt 'pu' (and 'jch') with the component topics myself,\nfollowing the exact order of merges you had between master..pu, in\norder to make sure that I fully made my working area in sync with\nyour merge resolutions, meaning that there shouldn't be any\ndifferences between trees of the tips of integration branches.\n\nThe result has been pushed out to various places.  The push to\nhttps://github.com/git/git/ resulted in a single 'pu' update (the\ntrees did not change, the merge history was rebuilt as stated in the\nprevious paragraph).  Other repositories, i.e.\n\n  git://git.kernel.org/pub/scm/git/git.git/\n  git://repo.or.cz/alt-git.git/\n  git://git.sourceforge.jp/gitroot/git-core/git.git/\n  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/\n\nreceived various updates to match your last integration results.\n\nSo it is OK for you to set your workspace back to your usual\ncontributor settings.  I can continue from here on.\n\nNote that I haven't made any new merges, picked up any new topics or\nreplaced an old patch on an existing topic with a new one (yet).\nHopefully I can get to that tomorrow.\n\nThanks.\n"},{"id":"273964","messageId":"20151203030220.GB25412@vauxhall.crustytoothpaste.net","threadId":"40918","inReplyTo":"1449102580.14908.2.camel@twopensource.com","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2015-12-03T03:02:20Z","receivedAt":"2015-12-03T03:02:20Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Wed, Dec 02, 2015 at 07:29:40PM -0500, David Turner wrote:\n> From a selfish perspective, I, would prefer for object-ids to not happen\n> quite yet for the refs code.  I have already prepared (but not yet sent)\n> a new version of the refs backend vtable (and lmdb) code on top of\n> refs-backend-pre-vtable, and it'll be a hassle to reroll it on top of\n> new object-id stuff.\n> \n> I guess I'll go ahead and send mine now, and we can later make a\n> decision about how to deal with the object-id stuff.\n\nAs Jeff pointed out, the patches to refs.c were mostly dropped, as the\ncode that they modified had been removed.  The likelihood of conflict is\ntherefore low unless you're using struct object a lot.\n\nMy preference is that new code use object_id where possible, because\notherwise I'm going to have to go through it later and fix it up.\nKeeping in mind that the refs code is likely to undergo a lot of\nchanges, I'll try to keep away from it for now, but it will need to be\nconverted at some point.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"274109","messageId":"20151207134014.GA1105@pks-xps.fritz.box","threadId":"40918","inReplyTo":"20151202223114.GA20542@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-12-07T13:40:14Z","receivedAt":"2015-12-07T13:40:14Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Dec 02, 2015 at 05:31:14PM -0500, Jeff King wrote:\n> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:\n[snip]\n> > \"--keep-empty\" has always been about keeping an originally empty\n> > commit, not a commit that becomes empty because of rebasing\n> > (i.e. what has already been applied to the updated base).  The\n> > documentation, if it leads to any other interpretation, needs to be\n> > fixed.\n> > \n> > Besides, if \"--keep-empty\" were to mean \"keep redundant ones that\n> > are already in the updated base\", the patch must do a lot more,\n> > e.g. stop filtering with git-cherry patch equivalence.\n> > \n> > I'm inclined to eject this topic.\n> \n> That was my thinking too (and I notice it didn't get any review from\n> anybody else).\n[snip]\n\nWell, I kind of agree. The cherry-pick command has both\n--allow-empty and --keep-redundant flags, where the second one is\nthe kind of behavior I want to achieve in my case. As an\nalternative to the proposed change to `--keep-empty` I could\ninstead introduce a new flag `--keep-redundant-commits` to `git\nrebase` which would then pass the flag through to the\ncherry-pick.\n\nAny opinions on this?\n\nPatrick\n"},{"id":"274124","messageId":"xmqqvb8am58b.fsf@gitster.mtv.corp.google.com","threadId":"40918","inReplyTo":"20151207134014.GA1105@pks-xps.fritz.box","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-12-07T19:24:52Z","receivedAt":"2015-12-07T19:24:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> On Wed, Dec 02, 2015 at 05:31:14PM -0500, Jeff King wrote:\n>> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:\n> [snip]\n>> > \"--keep-empty\" has always been about keeping an originally empty\n>> > commit, not a commit that becomes empty because of rebasing\n>> > (i.e. what has already been applied to the updated base).  The\n>> > documentation, if it leads to any other interpretation, needs to be\n>> > fixed.\n>> > \n>> > Besides, if \"--keep-empty\" were to mean \"keep redundant ones that\n>> > are already in the updated base\", the patch must do a lot more,\n>> > e.g. stop filtering with git-cherry patch equivalence.\n>> > \n>> > I'm inclined to eject this topic.\n>> \n>> That was my thinking too (and I notice it didn't get any review from\n>> anybody else).\n> [snip]\n>\n> Well, I kind of agree. The cherry-pick command has both\n> --allow-empty and --keep-redundant flags, where the second one is\n> the kind of behavior I want to achieve in my case. As an\n> alternative to the proposed change to `--keep-empty` I could\n> instead introduce a new flag `--keep-redundant-commits` to `git\n> rebase` which would then pass the flag through to the\n> cherry-pick.\n>\n> Any opinions on this?\n\nHonestly, I am not interested if that is only about passing that\noption and doing nothing else.\n\nImagine that you have two changes from the branch being rebased\nalready in the updated base, one was accepted verbatim, while the\nother one was accepted with a slight tweak.  Perhaps there were some\nconflicts in the context, or something.\n\nWhen you run your rebase, the former will not even be considered\nbecause command will notice, via patch equivalence, that you do not\nneed it, even before it attempts to replay it.  But not the latter.\nThe command will attempt to replay it, and only in this step it may\nnotice, by seeing that the result becomes a no-op change, that the\nchange has already been included in the updated base.\n\nI cannot quite see how adding \"--keep-redundant-commits\" to the\ncommand would help anybody by allowing the latter in the history but\nnot the former.  That is primarily because you can imagine a future\nin which the patch equivalence determination becomes smarter.  With\nor without \"--keep-redundant-commits\", both of these two changes\nwould not appear in the resulting history when that happens.\n\nThe \"--keep-redundant\" option to \"cherry-pick\" makes sense, as the\nuser will be the one who is deciding which commit to replay on top\nof a new base.  If the user fed a commit that is already in the new\nbase, and the command is run with the option, that is a deliberate\nrequest to leave a no-op cruft.\n\nWe cannot say the same thing for \"rebase\", as it tries to avoid\nredundant cruft, and it cannot do as good a job as humans in doing\nso.  The \"--keep-redundant-commits\" option will become a way to make\na distinction between what got dropped by the command automatically\nand what didn't get dropped because the command did not look deeply\nenough.  That distinction is not at all useful, as that can change\nas the tool improves.\n\nA \"--keep-redundant-commits\" to \"rebase\" that also disables the\npatch equivalence filtering (not just keeping empty crufts in the\nresulting history) might make sense, but I do not see myself (or\nanybody sane) using it.  \"In what situation would such a feature be\nuseful?\" is a question I cannot answer offhand.\n"},{"id":"274171","messageId":"20151208100534.GA1504@pks-pc","threadId":"40918","inReplyTo":"xmqqvb8am58b.fsf@gitster.mtv.corp.google.com","subject":"Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2015-12-08T10:05:34Z","receivedAt":"2015-12-08T10:05:34Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Mon, Dec 07, 2015 at 11:24:52AM -0800, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > On Wed, Dec 02, 2015 at 05:31:14PM -0500, Jeff King wrote:\n> >> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:\n> > [snip]\n> >> > \"--keep-empty\" has always been about keeping an originally empty\n> >> > commit, not a commit that becomes empty because of rebasing\n> >> > (i.e. what has already been applied to the updated base).  The\n> >> > documentation, if it leads to any other interpretation, needs to be\n> >> > fixed.\n> >> > \n> >> > Besides, if \"--keep-empty\" were to mean \"keep redundant ones that\n> >> > are already in the updated base\", the patch must do a lot more,\n> >> > e.g. stop filtering with git-cherry patch equivalence.\n> >> > \n> >> > I'm inclined to eject this topic.\n> >> \n> >> That was my thinking too (and I notice it didn't get any review from\n> >> anybody else).\n> > [snip]\n> >\n> > Well, I kind of agree. The cherry-pick command has both\n> > --allow-empty and --keep-redundant flags, where the second one is\n> > the kind of behavior I want to achieve in my case. As an\n> > alternative to the proposed change to `--keep-empty` I could\n> > instead introduce a new flag `--keep-redundant-commits` to `git\n> > rebase` which would then pass the flag through to the\n> > cherry-pick.\n> >\n> > Any opinions on this?\n> \n> Honestly, I am not interested if that is only about passing that\n> option and doing nothing else.\n> \n> Imagine that you have two changes from the branch being rebased\n> already in the updated base, one was accepted verbatim, while the\n> other one was accepted with a slight tweak.  Perhaps there were some\n> conflicts in the context, or something.\n> \n> When you run your rebase, the former will not even be considered\n> because command will notice, via patch equivalence, that you do not\n> need it, even before it attempts to replay it.  But not the latter.\n> The command will attempt to replay it, and only in this step it may\n> notice, by seeing that the result becomes a no-op change, that the\n> change has already been included in the updated base.\n> \n> I cannot quite see how adding \"--keep-redundant-commits\" to the\n> command would help anybody by allowing the latter in the history but\n> not the former.  That is primarily because you can imagine a future\n> in which the patch equivalence determination becomes smarter.  With\n> or without \"--keep-redundant-commits\", both of these two changes\n> would not appear in the resulting history when that happens.\n> \n> The \"--keep-redundant\" option to \"cherry-pick\" makes sense, as the\n> user will be the one who is deciding which commit to replay on top\n> of a new base.  If the user fed a commit that is already in the new\n> base, and the command is run with the option, that is a deliberate\n> request to leave a no-op cruft.\n> \n> We cannot say the same thing for \"rebase\", as it tries to avoid\n> redundant cruft, and it cannot do as good a job as humans in doing\n> so.  The \"--keep-redundant-commits\" option will become a way to make\n> a distinction between what got dropped by the command automatically\n> and what didn't get dropped because the command did not look deeply\n> enough.  That distinction is not at all useful, as that can change\n> as the tool improves.\n> \n> A \"--keep-redundant-commits\" to \"rebase\" that also disables the\n> patch equivalence filtering (not just keeping empty crufts in the\n> resulting history) might make sense, but I do not see myself (or\n> anybody sane) using it.  \"In what situation would such a feature be\n> useful?\" is a question I cannot answer offhand.\n\nThe scenario I require this feature for is somewhat more exotic,\nyes. We've got a CI where published branches can be rebased but\nshould not be modified in their commit history. That is, the CI\ndetermines in a hook wether the branch that is being pushed drops\nor re-orders commits and if so, rejects the branch.\n\nSo when a commit that is already included in origin/master gets\nrebased `git-rebase` currently simply drops the commit, which\ncauses the CI to refuse the branch on a push.\n\nSo obviously you are right in your conclusion that\n`--keep-redundant-commits` has to skip the patch equivalence\ndetermination in order to not drop any commits. Otherwise my\nchange would only work for certain scenarios.\n\nThat said, I do not care too deeply about this patch, especially\nas my scenario is rather uncommon. If you deem this to not have\nany greater benefit you may simply drop it.\n\nPatrick\n"}]}