What's cooking in git.git (Dec 2015, #01; Tue, 1)

What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Jeff King]

What's cooking in git.git (Dec 2015, #01; Tue, 1)
--------------------------------------------------

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

This should by my final whats-cooking before handing things back to
Junio. Thanks all for review help and for your patience during the past
few weeks.

You can find the normal integration branches at:

    https://github.com/git/git/

and all topic branches at:

    https://github.com/peff/git/

But note that I will _not_ be pushing to kernel.org.

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

* bc/object-id (2015-11-20) 12 commits
 - remote: convert functions to struct object_id
 - Remove get_object_hash.
 - Convert struct object to object_id
 - Add several uses of get_object_hash.
 - object: introduce get_object_hash macro.
 - ref_newer: convert to use struct object_id
 - push_refs_with_export: convert to struct object_id
 - get_remote_heads: convert to struct object_id
 - parse_fetch: convert to use struct object_id
 - add_sought_entry_mem: convert to struct object_id
 - Convert struct ref to use object_id.
 - sha1_file: introduce has_object_file helper.

 More transition from "unsigned char[40]" to "struct object_id".

 This needed a few merge fixups, but is mostly disentangled from other
 topics.

 Will merge to 'next'.


* dt/fsck-verify-pack-error (2015-12-01) 1 commit
 - verify_pack: do not ignore return value of verification function

 The exit code of git-fsck would not reflect some types of errors found
 in packed objects.

 Will merge to 'next'.


* kn/ref-filter-atom-parsing (2015-12-01) 10 commits
 - ref-filter: introduce objectname_atom_parser()
 - ref-filter: introduce contents_atom_parser()
 - ref-filter: introduce remote_ref_atom_parser()
 - ref-filter: introduce align_atom_parser()
 - strbuf: introduce strbuf_split_str_without_term()
 - ref-filter: introduce color_atom_parser()
 - ref-filter: skip deref specifier in match_atom_name()
 - ref-fitler: bump match_atom() name to the top
 - ref-filter: introduce struct used_atom
 - ref-filter: introduce a parsing function for each atom in valid_atom

 Refactoring of ref-filter's format-parsing code, in preparation
 for "branch --format" and friends.

 This replaces (for now) kn/for-each-ref-remainder, which will be built
 on top.

 Waiting for review.


* ls/travis-yaml (2015-11-28) 1 commit
 - Add Travis CI support

 Provides the necessary infrastructure to build topics using the free
 Travis CI. Developers forking from this topic (and enabling Travis) can
 do their own builds, and we can turn on auto-builds for git/git
 (including build-status for pull requests that people open).

 I'm inclined to merge this up, as the worst case is that it becomes
 dormant cruft in the repository root.

 Will merge to 'next'.


* rs/status-detached-head-memcmp (2015-11-28) 1 commit
 - wt-status: correct and simplify check for detached HEAD

 Fix some string-matching corner cases when digging in the reflog for
 "git status".

 Will merge to 'next', then 'maint'.


* sg/lock-file-commit-error (2015-12-01) 1 commit
 - Make error message after failing commit_lock_file() less confusing

 Cosmetic improvement to lock-file error messages.

 Comments on the new messages?

 Will merge to 'next' after giving time for bikeshedding.


--------------------------------------------------
[Graduated to "master"]

* ar/doc-env-variable-format (2015-11-11) 1 commit
  (merged to 'next' on 2015-11-24 at 5ddf33e)
 + Documentation: make environment variable formatting more consistent

 Minor documentation fixup.

 Will merge to 'master'.


* cb/hook-sigpipe (2015-11-16) 1 commit
  (merged to 'next' on 2015-11-24 at 0bf4228)
 + allow hooks to ignore their standard input stream

 We now consistently allow all hooks to ignore their standard input,
 rather than having git complain of SIGPIPE.

 Will merge to 'master'.


* cb/ssl-config-pathnames (2015-11-24) 1 commit
  (merged to 'next' on 2015-11-24 at 658a9c9)
 + http: treat config options sslCAPath and sslCAInfo as paths

 Allow tilde-expansion in some http config variables.

 Will merge to 'master'.


* dg/subtree-test-cleanup (2015-11-13) 7 commits
  (merged to 'next' on 2015-11-24 at 1297941)
 + contrib/subtree: Handle '--prefix' argument with a slash appended
 + contrib/subtree: Make each test self-contained
 + contrib/subtree: Add split tests
 + contrib/subtree: Add merge tests
 + contrib/subtree: Add tests for subtree add
 + contrib/subtree: Add test for missing subtree
 + contrib/subtree: Clean and refactor test code

 Test cleanups for the subtree project.

 Will merge to 'master'.


* dk/check-ignore-docs (2015-11-24) 1 commit
  (merged to 'next' on 2015-11-24 at 0cce5c5)
 + check-ignore: correct documentation about output

 Documentation clarification for "check-ignore" without "--verbose".

 Will merge to 'master'.


* dk/rerere-train-quoting (2015-11-20) 1 commit
  (merged to 'next' on 2015-11-24 at f9fa96e)
 + Escape Git's exec path in contrib/rerere-train.sh script

 Fix shell quoting in contrib script.

 Will merge to 'master'.


* dk/t5813-unc-paths (2015-11-20) 1 commit
  (merged to 'next' on 2015-11-24 at 204e4a8)
 + t5813: avoid creating urls that break on cygwin

 Test portability fix for a topic in v2.6.1.

 Will merge to 'master'.


* dt/http-range (2015-11-11) 1 commit
  (merged to 'next' on 2015-11-24 at d342999)
 + http: fix some printf format warnings

 Portability fix for a topic already in 'master'.

 Will merge to 'master'.


* eg/p4-submit-catch-failure (2015-11-24) 1 commit
  (merged to 'next' on 2015-11-24 at cf2dc76)
 + git-p4: clean up after p4 submit failure

 Just like the working tree is cleaned up when the user cancelled
 submission in P4Submit.applyCommit(), clean up the mess if "p4
 submit" fails.

 Will merge to 'master'.


* fm/shell-path-whitespace (2015-11-13) 1 commit
  (merged to 'next' on 2015-11-24 at c2b8bdf)
 + rebase-i-exec: Allow space in SHELL_PATH

 Portability fix for Windows, which may rewrite $SHELL variable using
 non-POSIX paths.

 Will merge to 'master'.


* jk/send-email-ca-path (2015-11-24) 1 commit
  (merged to 'next' on 2015-11-24 at 923b803)
 + send-email: die if CA path doesn't exist

 Use a safer behavior when we hit errors verifying remote certificates.

 Will merge to 'master'.


* jk/send-email-expand-paths (2015-11-20) 1 commit
  (merged to 'next' on 2015-11-24 at d32fa4d)
 + send-email: expand path in sendemail.smtpsslcertpath config

 Expand paths in some send-email config variables.

 Will merge to 'master'.


* js/test-modernize-t9300 (2015-11-20) 7 commits
  (merged to 'next' on 2015-11-24 at d399494)
 + modernize t9300: move test preparations into test_expect_success
 + modernize t9300: mark here-doc words to ignore tab indentation
 + modernize t9300: use test_when_finished for clean-up
 + modernize t9300: wrap lines after &&
 + modernize t9300: use test_must_be_empty
 + modernize t9300: use test_must_fail
 + modernize t9300: single-quote placement and indentation

 Clean up style in an ancient test.

 Will merge to 'master'.


* ld/p4-detached-head (2015-11-24) 3 commits
  (merged to 'next' on 2015-11-24 at 36ab36a)
 + git-p4: work with a detached head
 + git-p4: add option to system() to return subshell status
 + git-p4: add failing test for submit from detached head

 Make git-p4 work on a detached head.

 Will merge to 'master'.


* ls/p4-test-timeouts (2015-11-20) 3 commits
  (merged to 'next' on 2015-11-24 at 905cff8)
 + git-p4: add trap to kill p4d on test exit
 + git-p4: add p4d timeout in tests
 + git-p4: retry kill/cleanup operations in tests with timeout

 Work around some test flakiness with p4d.

 Will merge to 'master'.


* mg/doc-word-diff-example (2015-11-24) 1 commit
  (merged to 'next' on 2015-11-24 at 5ba28db)
 + Documentation/diff: give --word-diff-regex=. example

 Will merge to 'master'.


* mk/blame-first-parent (2015-11-24) 1 commit
  (merged to 'next' on 2015-11-24 at a2ee2a4)
 + blame: fix object casting regression

 Regression fix for a topic already in master.

 Will merge to 'master'.


* pt/http-socks-proxy (2015-11-20) 1 commit
  (merged to 'next' on 2015-11-20 at dc6ae48)
 + remote-http(s): support SOCKS proxies

 Add support for talking http/https over socks proxy.

 Will merge to 'master'.


* rs/fsck-nul-header (2015-11-20) 2 commits
  (merged to 'next' on 2015-11-24 at 093b3d6)
 + fsck: treat a NUL in a tag header as an error
 + t1450: add tests for NUL in headers of commits and tags

 Fsck did not correctly detect a NUL-truncated header in a tag.

 Will merge to 'master'.


* sg/filter-branch-dwim-ambiguity (2015-11-24) 1 commit
  (merged to 'next' on 2015-11-24 at fe596a6)
 + filter-branch: deal with object name vs. pathname ambiguity in tree-filter

 Fix for a corner case in filter-branch.

 Will merge to 'master'.

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

* nd/ita-cleanup (2015-09-06) 6 commits
 - grep: make it clear i-t-a entries are ignored
 - checkout(-index): do not checkout i-t-a entries
 - apply: make sure check_preimage() does not leave empty file on error
 - apply: fix adding new files on i-t-a entries
 - add and use a convenience macro ce_intent_to_add()
 - blame: remove obsolete comment

 Paths that have been told the index about with "add -N" are not yet
 in the index, but various commands behaved as if they already are.

 Some commits need better explanation.

 Waiting for a reroll.


* mg/httpd-tests-update-for-apache-2.4 (2015-04-08) 2 commits
 - t/lib-git-svn: check same httpd module dirs as lib-httpd
 - t/lib-httpd: load mod_unixd

 This is the first two commits in a three-patch series $gmane/266962

 Becoming tired of waiting for a reroll.
 with updated log message ($gmane/268061).


* wp/sha1-name-negative-match (2015-06-08) 2 commits
 - sha1_name.c: introduce '^{/!-<negative pattern>}' notation
 - test for '!' handling in rev-parse's named commits

 Introduce "branch^{/!-<pattern>}" notation to name a commit
 reachable from branch that does not match the given pattern.

 Becoming tired of waiting for a reroll.
 ($gmane/271213).


* ak/format-patch-odir-config (2015-06-19) 1 commit
 - format-patch: introduce format.outputDirectory configuration

 Reroll exists but didn't pick it up as it seemed to be still
 collecting review comments.

 Becoming tired of waiting for a reroll.
 ($gmane/272180).


* jc/diff-b-m (2015-02-23) 5 commits
 . WIPWIP
 . WIP: diff-b-m
 - diffcore-rename: allow easier debugging
 - diffcore-rename.c: add locate_rename_src()
 - diffcore-break: allow debugging

 "git diff -B -M" produced incorrect patch when the postimage of a
 completely rewritten file is similar to the preimage of a removed
 file; such a resulting file must not be expressed as a rename from
 other place.

 The fix in this patch is broken, unfortunately.

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

* bb/merge-marker-crlf (2015-11-24) 1 commit
 - merge-file: consider core.crlf when writing merge markers

 Write out merge markers using system end-of-line convention.

 Waiting for a re-roll to handle gitattributes.


* dk/gc-more-wo-pack (2015-11-24) 3 commits
 - gc: Clean garbage .bitmap files from pack dir
 - t5304: Add test for .bitmap garbage files
 - prepare_packed_git(): find more garbage

 Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
 .bitmap and .keep files.

 Waiting for review.


* jk/send-email-ssl-errors (2015-11-24) 1 commit
 - send-email: enable SSL level 1 debug output

 Improve error reporting when SMTP TLS fails.

 Waiting for re-roll.


* mr/ff-refs (2015-11-28) 6 commits
 - builtin/ff-refs.c: mark some file-local variables static
 - ff-refs: Add tests
 - ff-refs: Add documentation
 - ff-refs: add --dry-run and --skip-worktree options
 - ff-refs: update each updatable ref
 - ff-refs: builtin cmd to check and fast forward local refs to their upstream

 Specialized command to fast-forward refs to match their upstream.

 I remain skeptical that this is necessary or sufficient. Comments
 welcome.

 Will hold.


* ps/rebase-keep-empty (2015-11-24) 2 commits
 - rebase: fix preserving commits with --keep-empty
 - rebase: test broken behavior with --keep-empty

 Keep duplicate commits via rebase --keep-empty.

 I'm not sure if I agree with this interpretation of the "rebase
 --keep-empty" documentation, but I haven't thought too hard about it.
 Comments welcome.

 Waiting for review.


* rm/subtree-unwrap-tags (2015-11-24) 1 commit
 - contrib/subtree: unwrap tag refs

 Waiting for review from subtree folks.


* sg/bash-prompt-dirty-orphan (2015-11-24) 3 commits
  (merged to 'next' on 2015-11-24 at ac6eb1c)
 + bash prompt: indicate dirty index even on orphan branches
 + bash prompt: remove a redundant 'git diff' option
 + bash prompt: test dirty index and worktree while on an orphan branch

 Produce correct "dirty" marker for shell prompts, even when we
 are on an orphan branch.

 Will merge to 'master'.


* sg/sh-require-clean-orphan (2015-11-24) 2 commits
 - sh-setup: make require_clean_work_tree() work on orphan branches
 - Add tests for git-sh-setup's require_clean_work_tree()

 Allow users of git-sh-setup to handle orphan branch state.

 This series takes the conservative route of requiring scripts to opt
 into the looser behavior, at the expense of carrying around a new
 option-flag forever. I'm not sure if we need to do so. Comments
 welcome.

 Waiting for re-roll?


* tb/ls-files-eol (2015-11-28) 2 commits
 - convert.c: mark a file-local function static
 - ls-files: Add eol diagnostics

 Add options to ls-files to help diagnose end-of-line problems.

 This latest round hasn't gotten any review yet.

 Waiting for review.


* ec/annotate-deleted (2015-11-20) 1 commit
 - annotate: skip checking working tree if a revision is provided

 Usability fix for annotate-specific "<file> <rev>" syntax with deleted
 files.

 Needs review.


* jk/filter-branch-no-index (2015-11-06) 1 commit
  (merged to 'next' on 2015-11-24 at e31946e)
 + filter-branch: skip index read/write when possible

 Speed up filter-branch for cases where we only care about rewriting
 commits, not tree data.

 Will merge to 'master'.


* jk/send-email-complete-aliases (2015-11-20) 2 commits
  (merged to 'next' on 2015-11-24 at a50094f)
 + completion: add support for completing email aliases
 + sendemail: teach git-send-email to dump alias names

 Teach send-email to dump mail aliases, so that we can do tab completion
 on the command line.

 Will merge to 'master'.


* ls/test-must-fail-sigpipe (2015-11-28) 2 commits
  (merged to 'next' on 2015-12-01 at d374686)
 + add "ok=sigpipe" to test_must_fail and use it to fix flaky tests
 + implement test_might_fail using a refactored test_must_fail

 Fix some racy client/server tests by treating SIGPIPE the same as a
 normal non-zero exit.

 Will merge to 'master' two cycles from now.


* mc/push-recurse-submodules-config (2015-11-20) 1 commit
  (merged to 'next' on 2015-11-24 at 3644d4b)
 + push: add recurseSubmodules config option

 Add new config to avoid typing "--recurse-submodules" on each push.

 Waiting for review from submodule folks.


* np/credential-cache-sighup (2015-11-20) 1 commit
  (merged to 'next' on 2015-11-24 at 410167f)
 + credential-cache: new option to ignore sighup

 Workaround for using credential-cache with emacs.

 Will merge to 'master'.


* rs/parseopt-short-help (2015-11-20) 5 commits
  (merged to 'next' on 2015-11-24 at f22b6e0)
 + show-ref: stop using PARSE_OPT_NO_INTERNAL_HELP
 + grep: stop using PARSE_OPT_NO_INTERNAL_HELP
 + parse-options: allow -h as a short option
 + parse-options: inline parse_options_usage() at its only remaining caller
 + parse-options: deduplicate parse_options_usage() calls

 Make "-h" command line option work more consistently in all commands.

 Will merge to 'master'.


* dt/refs-backend-pre-vtable (2015-11-20) 10 commits
  (merged to 'next' on 2015-11-24 at 8fd7293)
 + refs: break out ref conflict checks
 + files_log_ref_write: new function
 + initdb: make safe_create_dir public
 + refs: split filesystem-based refs code into a new file
 + refs/refs-internal.h: new header file
 + refname_is_safe(): improve docstring
 + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()
 + copy_msg(): rename to copy_reflog_msg()
 + verify_refname_available(): new function
 + verify_refname_available(): rename function

 Code preparation for pluggable ref backends.

 Will merge to 'master' two cycles from now.


* ad/sha1-update-chunked (2015-11-05) 2 commits
  (merged to 'next' on 2015-12-01 at a22bf47)
 + sha1: allow limiting the size of the data passed to SHA1_Update()
 + sha1: provide another level of indirection for the SHA-1 functions

 Apple's common crypto implementation of SHA1_Update() does not take
 more than 4GB at a time, and we now have a compile-time workaround
 for it.

 Will merge to 'master'.


* vl/grep-configurable-threads (2015-11-01) 1 commit
 - grep: add --threads=<num> option and grep.threads configuration

 "git grep" can now be configured (or told from the command line)
 how many threads to use when searching in the working tree files.

 There was some review from Eric.

 Waiting for re-roll?


* kf/http-proxy-auth-methods (2015-11-04) 3 commits
 . SQUASH???
 . http: use credential API to handle proxy authentication
 . http: allow selection of proxy authentication method

 New http.proxyAuthMethod configuration variable can be used to
 specify what authentication method to use, as a way to work around
 proxies that do not give error response expected by libcurl when
 CURLAUTH_ANY is used.  Also, the codepath for proxy authentication
 has been taught to use credential API to store the authentication
 material in user's keyrings.

 I ejected this from pu for the moment, as it conflicts with the
 pt/http-socks-proxy topic. That is now in master, so it can
 be re-rolled on top.

 Still being worked on.
 ($gmane/280925).


* sb/submodule-parallel-update (2015-11-20) 27 commits
 - clone: allow an explicit argument for parallel submodule clones
 - submodule update: expose parallelism to the user
 - git submodule update: have a dedicated helper for cloning
 - fetching submodules: respect `submodule.jobs` config option
 - submodule-config: introduce parse_generic_submodule_config
 - submodule-config: remove name_and_item_from_var
 - submodule-config: drop check against NULL
 - submodule-config: keep update strategy around
 - run_processes_parallel: delimit intermixed task output
 - Merge branch 'rs/daemon-plug-child-leak' into sb/submodule-parallel-update
 - Merge branch 'sb/submodule-parallel-fetch' into sb/submodule-parallel-update
  (merged to 'next' on 2015-11-20 at 89fc723)
 + strbuf: update documentation for strbuf_read_once()
 + run-command: remove set_nonblocking()
  (merged to 'next' on 2015-10-23 at 8f04bbd)
 + run-command: fix missing output from late callbacks
 + test-run-command: increase test coverage
 + test-run-command: test for gracefully aborting
 + run-command: initialize the shutdown flag
 + run-command: clear leftover state from child_process structure
 + run-command: fix early shutdown
  (merged to 'next' on 2015-10-15 at df63590)
 + submodules: allow parallel fetching, add tests and documentation
 + fetch_populated_submodules: use new parallel job processing
 + run-command: add an asynchronous parallel child processor
 + sigchain: add command to pop all common signals
 + strbuf: add strbuf_read_once to read without blocking
 + xread_nonblock: add functionality to read from fds without blocking
 + xread: poll on non blocking fds
 + submodule.c: write "Fetching submodule <foo>" to stderr
 (this branch is tangled with sb/submodule-parallel-fetch.)

 Builds on top of the "fetch --recurse-submodules" work to introduce
 parallel downloading into multiple submodules for "submodule update".

 Waiting for sb/submodule-parallel-fetch to stabilize.

 It would be the cleanest to rebuild sb/submodule-parallel-fetch on
 top of 2.7.0 once it ships and then build this directly on top;
 that way, we do not have to have merges in this topic that
 distracting (besides, some part of the other topic can be updated
 in-place instead of this follow-up topic tweaking them as past
 mistakes and inflexibilities).

 I picked up v4 from the list, but it needs review.


* jc/strbuf-gets (2015-10-28) 17 commits
 - test-sha1-array: read command stream with strbuf_gets()
 - grep: read -f file with strbuf_gets()
 - send-pack: read list of refs with strbuf_gets()
 - column: read lines with strbuf_gets()
 - cat-file: read batch stream with strbuf_gets()
 - transport-helper: read helper response with strbuf_gets()
 - clone/sha1_file: read info/alternates with strbuf_gets()
 - remote.c: read $GIT_DIR/remotes/* with strbuf_gets()
 - ident.c: read /etc/mailname with strbuf_gets()
 - rev-parse: read parseopt spec with strbuf_gets()
 - revision: read --stdin with strbuf_gets()
 - hash-object: read --stdin-paths with strbuf_gets()
 - mktree: read textual tree representation with strbuf_gets()
 - update-index: read list of paths with strbuf_gets() under --stdin
 - update-index: read --index-info with strbuf_gets()
 - check-attr, check-ignore, checkout-index: read paths with strbuf_gets()
 - strbuf: add strbuf_gets()

 Teach codepaths that communicate with users by reading text files
 to be more lenient to editors that write CRLF-terminated lines.
 Note that this is only about communication with Git, like feeding
 list of object names from the standard input instead of from the
 command line, and does not involve files in the working tree.

 Waiting for reviews.


* ep/ident-with-getaddrinfo (2015-11-28) 1 commit
  (merged to 'next' on 2015-12-01 at 0775d4c)
 + ident.c: add support for IPv6

 A build without NO_IPv6 used to use gethostbyname() when guessing
 user's hostname, instead of getaddrinfo() that is used in other
 codepaths in such a build.

 Will merge to 'master' two cycles from now.


* mh/notes-allow-reading-treeish (2015-10-08) 3 commits
  (merged to 'next' on 2015-10-23 at 8a697f0)
 + notes: allow treeish expressions as notes ref
 + Merge branch 'jk/notes-dwim-doc' into next
 + Merge branch 'jc/merge-drop-old-syntax' into next
 (this branch uses jc/merge-drop-old-syntax.)

 Some "git notes" operations, e.g. "git log --notes=<note>", should
 be able to read notes from any tree-ish that is shaped like a notes
 tree, but the notes infrastructure required that the argument must
 be a ref under refs/notes/.  Loosen it to require a valid ref only
 when the operation would update the notes (in which case we must
 have a place to store the updated notes tree, iow, a ref).

 As the patch was done on top of the 'drop old-syntax from merge',
 this has to wait until that other topic can graduate, unfortunately.
 It can be redone in a way that does not depend on that topic after
 this cycle, though.

 Will keep in 'next'.


* jc/mailinfo (2015-10-21) 1 commit
 - mailinfo: ignore in-body header that we do not care about

 Some people write arbitrary garbage at the beginning of a piece of
 e-mail (or after -- >8 -- scissors -- >8 -- line) in the commit log
 message and expect them to be discarded, even though "From:" and
 "Subject:" are the only documented in-body headers that you are
 supposed to have there.  Allow some garbage (specifically, what may
 look like RFC2822 headers like "MIME-Version: ...") to be there and
 ignore them.

 I have a feeling that that this is a step in a wrong direction.
 Comments?


* js/am-3-merge-recursive-direct (2015-10-12) 2 commits
  (merged to 'next' on 2015-10-23 at dc631e5)
 + am: make a direct call to merge_recursive
 + merge_recursive_options: introduce the "gently" flag

 The merge_recursive_generic() function has been made a bit safer to
 call from inside a process.  "git am -3" was taught to make a direct
 call to the function when falling back to three-way merge.

 Being able to make a direct call would be good in general, but as a
 performance thing, we would want to see it backed up by numbers.

 I haven't gone through the "gently" change with fine toothed comb;
 I can see that the change avoids calling die(), but I haven't made
 sure that the program states (e.g. what's in the in-core index) are
 adjusted sensibly when it returns to the caller instead of dying,
 or the codepaths that used to die() are free of resource leaks.
 The original code certainly did not care the program states at the
 point of dying exactly because it knew it is going to exit, but now
 they have to care, and they need to be audited.

 Will keep in 'next'.


* sg/pretty-more-date-mode-format (2015-10-07) 1 commit
 - pretty: add format specifiers for short and raw date formats

 Introduce "%as" and "%aR" placeholders for "log --format" to show
 the author date in the short and raw formats.

 I have a feeling that that this is a step in a wrong direction.
 Comments?


* kn/for-each-branch-remainder (2015-10-02) 9 commits
 . branch: implement '--format' option
 . branch: use ref-filter printing APIs
 . ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
 . ref-filter: introduce format_ref_array_item()
 . ref-filter: adopt get_head_description() from branch.c
 . ref-filter: modify "%(objectname:short)" to take length
 . ref-filter: add support for %(path) atom
 . ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
 . ref-filter: implement %(if), %(then), and %(else) atoms

 More unification among "branch -l", "tag -l" and "for-each-ref --format".

 Ejected from pu for now, as a re-roll should come on top of
 kn/ref-filter-atom-parsing.

 Expecting a reroll.
 ($gmane/278926)


* jk/graph-format-padding (2015-09-14) 1 commit
 - pretty: pass graph width to pretty formatting for use in '%>|(N)'

 Redefine the way '%>|(N)' padding and the "--graph" option
 interacts.  It has been that the available columns to display the
 log message was measured from the edge of the area the graph ended,
 but with this it becomes the beginning of the entire output.

 I have a suspicion that 50% of the users would appreciate this
 change, and the remainder see this break their expectation.  If
 that is the case, we might need to introduce a similar but
 different alignment operator so that this new behaviour is
 available to those who want to use it, without negatively affecting
 existing uses.

 Undecided.
 ($gmane/278326)


* sb/submodule-parallel-fetch (2015-11-24) 17 commits
 - run-command: detect finished children by closed pipe rather than waitpid
  (merged to 'next' on 2015-11-20 at 89fc723)
 + strbuf: update documentation for strbuf_read_once()
 + run-command: remove set_nonblocking()
  (merged to 'next' on 2015-10-23 at 8f04bbd)
 + run-command: fix missing output from late callbacks
 + test-run-command: increase test coverage
 + test-run-command: test for gracefully aborting
 + run-command: initialize the shutdown flag
 + run-command: clear leftover state from child_process structure
 + run-command: fix early shutdown
  (merged to 'next' on 2015-10-15 at df63590)
 + submodules: allow parallel fetching, add tests and documentation
 + fetch_populated_submodules: use new parallel job processing
 + run-command: add an asynchronous parallel child processor
 + sigchain: add command to pop all common signals
 + strbuf: add strbuf_read_once to read without blocking
 + xread_nonblock: add functionality to read from fds without blocking
 + xread: poll on non blocking fds
 + submodule.c: write "Fetching submodule <foo>" to stderr
 (this branch is tangled with sb/submodule-parallel-update.)

 Add a framework to spawn a group of processes in parallel, and use
 it to run "git fetch --recurse-submodules" in parallel.

 Will merge top commit to 'next'.


* ad/cygwin-wants-rename (2015-08-07) 1 commit
 - config.mak.uname: Cygwin needs OBJECT_CREATION_USES_RENAMES

 Will hold.
 ($gmane/275680).


* jc/rerere-multi (2015-09-14) 7 commits
 - rerere: do use multiple variants
 - t4200: rerere a merge with two identical conflicts
 - rerere: allow multiple variants to exist
 - rerere: delay the recording of preimage
 - rerere: handle leftover rr-cache/$ID directory and postimage files
 - rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id
 - rerere: split conflict ID further

 "git rerere" can encounter two or more files with the same conflict
 signature that have to be resolved in different ways, but there was
 no way to record these separate resolutions.


* jc/merge-drop-old-syntax (2015-04-29) 1 commit
  (merged to 'next' on 2015-10-07 at 50fed71)
 + merge: drop 'git merge <message> HEAD <commit>' syntax
 (this branch is used by mh/notes-allow-reading-treeish.)

 Originally merged to 'next' on 2015-05-28

 Stop supporting "git merge <message> HEAD <commit>" syntax that has
 been deprecated since October 2007.  It has been reported that
 git-gui still uses the deprecated syntax, which needs to be fixed
 before this final step can proceed.

 Will keep in 'next'.

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> What's cooking in git.git (Dec 2015, #01; Tue, 1)
> --------------------------------------------------
>
> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
>
> This should by my final whats-cooking before handing things back to
> Junio. Thanks all for review help and for your patience during the past
> few weeks.

I think I managed to get my working area (together with a handful of
new entries in the rerere database and a few merge-fix/ entries) in
sync with what you pushed out well enough that my automated
procedure would recreate the status of various branches you pushed
out exactly.

I haven't caught up with the changes in the component branches,
though, so it may take a few days until I start picking up new
topics from the list traffic.

> * bc/object-id (2015-11-20) 12 commits
>  - remote: convert functions to struct object_id
>  - Remove get_object_hash.
>  - Convert struct object to object_id
>  - Add several uses of get_object_hash.
>  - object: introduce get_object_hash macro.
>  - ref_newer: convert to use struct object_id
>  - push_refs_with_export: convert to struct object_id
>  - get_remote_heads: convert to struct object_id
>  - parse_fetch: convert to use struct object_id
>  - add_sought_entry_mem: convert to struct object_id
>  - Convert struct ref to use object_id.
>  - sha1_file: introduce has_object_file helper.
>
>  More transition from "unsigned char[40]" to "struct object_id".
>
>  This needed a few merge fixups, but is mostly disentangled from other
>  topics.
>
>  Will merge to 'next'.

Aside from niggles on titles of a handful of changes in this topic,
I have a bit of concern with this one and dt/refs-backend-pre-vtable
topic (marked as "Will merge to 'master' two cycles from now.",
which I am reading as "two cycles" means 2 x (8-10 week release
cycle), not "two integration cycles by the maintainer, aka two
issues of What's cooking report", which is typically less than a
week).

The merge resolution in 'pu' discards what this topic did to refs.c
because much of the original goes away from there, but does it mean
(remember, I haven't caught up with the contents of the topics yet)
that the merge reverts part of what this topic did, and in an ideal
world, if the other one were more mature when this topic got
started, more use of "unsigned char[40]" would have been migrated to
"struct object_id" in new files the other one introduced?  Or
perhaps we would want to go the other way around, i.e. as this topic
conceptually is fairly straight-forward, merge this to 'next' and
then down to 'master' (which would not take two release cycles) and
then redo the other topic on top?

> * mr/ff-refs (2015-11-28) 6 commits
>  - builtin/ff-refs.c: mark some file-local variables static
>  - ff-refs: Add tests
>  - ff-refs: Add documentation
>  - ff-refs: add --dry-run and --skip-worktree options
>  - ff-refs: update each updatable ref
>  - ff-refs: builtin cmd to check and fast forward local refs to their upstream
>
>  Specialized command to fast-forward refs to match their upstream.
>
>  I remain skeptical that this is necessary or sufficient. Comments
>  welcome.
>
>  Will hold.

This is another one that needs some evil-merge interaction with
bc/object-id, but I have a feeling that this is not such a good
addition to our workflow elements, so I am not worried too much
about it.  I'm inclined to eject this topic (and will welcome if
people come up with an alternative, perhaps based on the "let fetch
do so instead" approach discussed there).

> * ps/rebase-keep-empty (2015-11-24) 2 commits
>  - rebase: fix preserving commits with --keep-empty
>  - rebase: test broken behavior with --keep-empty
>
>  Keep duplicate commits via rebase --keep-empty.
>
>  I'm not sure if I agree with this interpretation of the "rebase
>  --keep-empty" documentation, but I haven't thought too hard about it.
>  Comments welcome.

"--keep-empty" has always been about keeping an originally empty
commit, not a commit that becomes empty because of rebasing
(i.e. what has already been applied to the updated base).  The
documentation, if it leads to any other interpretation, needs to be
fixed.

Besides, if "--keep-empty" were to mean "keep redundant ones that
are already in the updated base", the patch must do a lot more,
e.g. stop filtering with git-cherry patch equivalence.

I'm inclined to eject this topic.


> * ls/test-must-fail-sigpipe (2015-11-28) 2 commits
>   (merged to 'next' on 2015-12-01 at d374686)
>  + add "ok=sigpipe" to test_must_fail and use it to fix flaky tests
>  + implement test_might_fail using a refactored test_must_fail
>
>  Fix some racy client/server tests by treating SIGPIPE the same as a
>  normal non-zero exit.
>
>  Will merge to 'master' two cycles from now.

Hmm, perhaps I misread what you meant by "two cycles", as this is
only the test suite and I cannot imagine we would want to be
ultra-safe to cook that for two release cycles, and you did mean two
issues of "What's cooking" report?

If so, I'll have to rethink the comment on bc/object-id I made
earlier...

> * dt/refs-backend-pre-vtable (2015-11-20) 10 commits
>   (merged to 'next' on 2015-11-24 at 8fd7293)
>  + refs: break out ref conflict checks
>  + files_log_ref_write: new function
>  + initdb: make safe_create_dir public
>  + refs: split filesystem-based refs code into a new file
>  + refs/refs-internal.h: new header file
>  + refname_is_safe(): improve docstring
>  + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()
>  + copy_msg(): rename to copy_reflog_msg()
>  + verify_refname_available(): new function
>  + verify_refname_available(): rename function
>
>  Code preparation for pluggable ref backends.
>
>  Will merge to 'master' two cycles from now.

... that is, I'd very much prefer bc/object-id redone on top of an
updated codebase that already has dt/refs-backend-pre-vtable in it.

Thanks.

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Jeff King]

On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:

> I think I managed to get my working area (together with a handful of
> new entries in the rerere database and a few merge-fix/ entries) in
> sync with what you pushed out well enough that my automated
> procedure would recreate the status of various branches you pushed
> out exactly.
> 
> I haven't caught up with the changes in the component branches,
> though, so it may take a few days until I start picking up new
> topics from the list traffic.

My whole workspace is at https://github.com/peff/git, if fetching that
directly is easier. I just noticed that my refspecs were not configured
to push up refs/merge-fix. I've just fixed that and pushed again.

I'll leave it that way for a few more days, but then will probably take
it back to my usual contributor setup (i.e., just my topics and personal
integration branches).

Let me know if there's anything else I can do to help with the handoff.

> > * bc/object-id (2015-11-20) 12 commits
> [...]
> 
> Aside from niggles on titles of a handful of changes in this topic,
> I have a bit of concern with this one and dt/refs-backend-pre-vtable
> topic (marked as "Will merge to 'master' two cycles from now.",
> which I am reading as "two cycles" means 2 x (8-10 week release
> cycle), not "two integration cycles by the maintainer, aka two
> issues of What's cooking report", which is typically less than a
> week).

My "two cycles from now" meant "two integration cycles". I seemed to do
only about two per week. You can take those all with a grain of salt. It
was meant only as a note to myself that the topic seemed risky enough to
allow extra cooking time in next.

Since your "Meta/cook -w" output shows dates of merges, I imagine you
are in the habit of simply looking at those dates and saying "eh, this
has been in next for 2 weeks and nobody has complained; that's enough
cooking time".

> The merge resolution in 'pu' discards what this topic did to refs.c
> because much of the original goes away from there, but does it mean
> (remember, I haven't caught up with the contents of the topics yet)
> that the merge reverts part of what this topic did, and in an ideal
> world, if the other one were more mature when this topic got
> started, more use of "unsigned char[40]" would have been migrated to
> "struct object_id" in new files the other one introduced?  Or
> perhaps we would want to go the other way around, i.e. as this topic
> conceptually is fairly straight-forward, merge this to 'next' and
> then down to 'master' (which would not take two release cycles) and
> then redo the other topic on top?

I took the resolution proposed by brian, which was that the refs.c code
went away. There was some evil-merge required to make the new
refs/files-backend.c compile (in my refs/merge-fix/bc/object-id) for
code that moved. I was surprised there wasn't more, but I think it's
right. We dropped the _users_ of some sha1/object_id transition code
(which is why it doesn't need more fixup to compile). We did not drop
any actual function conversions (which might have been wrong but still
compiled, if both the function signature and its callers all moved).

As it's all part of an incremental conversion anyway, my feeling was
that it was OK to move forward as long as it wasn't disturbing topics in
flight (assuming we're agreed on the overall direction, which I think is
the case).

> > * mr/ff-refs (2015-11-28) 6 commits
> [...]
> 
> This is another one that needs some evil-merge interaction with
> bc/object-id, but I have a feeling that this is not such a good
> addition to our workflow elements, so I am not worried too much
> about it.  I'm inclined to eject this topic (and will welcome if
> people come up with an alternative, perhaps based on the "let fetch
> do so instead" approach discussed there).

Right. There's another merge-fix for this.

I explicitly put this after bc/object-id (requiring another merge-fix,
rather than rolling it into the bc/object-id merge fix), because I
expected bc/object-id to graduate, and this one to languish in pu or get
re-rolled.

I agree that ejecting is fine here.

> > * ps/rebase-keep-empty (2015-11-24) 2 commits
> >  - rebase: fix preserving commits with --keep-empty
> >  - rebase: test broken behavior with --keep-empty
> >
> >  Keep duplicate commits via rebase --keep-empty.
> >
> >  I'm not sure if I agree with this interpretation of the "rebase
> >  --keep-empty" documentation, but I haven't thought too hard about it.
> >  Comments welcome.
> 
> "--keep-empty" has always been about keeping an originally empty
> commit, not a commit that becomes empty because of rebasing
> (i.e. what has already been applied to the updated base).  The
> documentation, if it leads to any other interpretation, needs to be
> fixed.
> 
> Besides, if "--keep-empty" were to mean "keep redundant ones that
> are already in the updated base", the patch must do a lot more,
> e.g. stop filtering with git-cherry patch equivalence.
> 
> I'm inclined to eject this topic.

That was my thinking too (and I notice it didn't get any review from
anybody else).

> > * ls/test-must-fail-sigpipe (2015-11-28) 2 commits
> >   (merged to 'next' on 2015-12-01 at d374686)
> >  + add "ok=sigpipe" to test_must_fail and use it to fix flaky tests
> >  + implement test_might_fail using a refactored test_must_fail
> >
> >  Fix some racy client/server tests by treating SIGPIPE the same as a
> >  normal non-zero exit.
> >
> >  Will merge to 'master' two cycles from now.
> 
> Hmm, perhaps I misread what you meant by "two cycles", as this is
> only the test suite and I cannot imagine we would want to be
> ultra-safe to cook that for two release cycles, and you did mean two
> issues of "What's cooking" report?

Yes, the latter. Even though it is "only" the test suite, it gave us
enough trouble that I did not want to go to next and then immediately to
master in the next cycle (i.e., I wanted to give people time enough to
complain if it breaks their "make test" in next).

> > * dt/refs-backend-pre-vtable (2015-11-20) 10 commits
> >   (merged to 'next' on 2015-11-24 at 8fd7293)
> >  + refs: break out ref conflict checks
> >  + files_log_ref_write: new function
> >  + initdb: make safe_create_dir public
> >  + refs: split filesystem-based refs code into a new file
> >  + refs/refs-internal.h: new header file
> >  + refname_is_safe(): improve docstring
> >  + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()
> >  + copy_msg(): rename to copy_reflog_msg()
> >  + verify_refname_available(): new function
> >  + verify_refname_available(): rename function
> >
> >  Code preparation for pluggable ref backends.
> >
> >  Will merge to 'master' two cycles from now.
> 
> ... that is, I'd very much prefer bc/object-id redone on top of an
> updated codebase that already has dt/refs-backend-pre-vtable in it.

I think that is OK to do, though I'm not sure the end result will be
all that different.

-Peff

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:
>
>> I think I managed to get my working area (together with a handful of
>> new entries in the rerere database and a few merge-fix/ entries) in
>> sync with what you pushed out well enough that my automated
>> procedure would recreate the status of various branches you pushed
>> out exactly.
>> 
>> I haven't caught up with the changes in the component branches,
>> though, so it may take a few days until I start picking up new
>> topics from the list traffic.
>
> My whole workspace is at https://github.com/peff/git, if fetching that
> directly is easier. I just noticed that my refspecs were not configured
> to push up refs/merge-fix. I've just fixed that and pushed again.
>
> I'll leave it that way for a few more days, but then will probably take
> it back to my usual contributor setup (i.e., just my topics and personal
> integration branches).

Thanks.  I haven't re-fetched from you, but I think I am good.

> My "two cycles from now" meant "two integration cycles". I seemed to do
> only about two per week. You can take those all with a grain of salt. It
> was meant only as a note to myself that the topic seemed risky enough to
> allow extra cooking time in next.
>
> Since your "Meta/cook -w" output shows dates of merges, I imagine you
> are in the habit of simply looking at those dates and saying "eh, this
> has been in next for 2 weeks and nobody has complained; that's enough
> cooking time".

Yup ;-)

> (which is why it doesn't need more fixup to compile). We did not drop
> any actual function conversions (which might have been wrong but still
> compiled, if both the function signature and its callers all moved).

OK, good to know.

I just finished my first pass of going through "cook -w" output and
had trouble judging jk/send-email-ssl-errors topic, which is marked
as "waiting for re-roll", but I cannot seem to find any discussion
on it, just the original patch $gmane/281655.  Are there concerns?

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Jeff King]

On Wed, Dec 02, 2015 at 03:31:41PM -0800, Junio C Hamano wrote:

> I just finished my first pass of going through "cook -w" output and
> had trouble judging jk/send-email-ssl-errors topic, which is marked
> as "waiting for re-roll", but I cannot seem to find any discussion
> on it, just the original patch $gmane/281655.  Are there concerns?

Looks like it needs a slight tweak:

  http://article.gmane.org/gmane.comp.version-control.git/281693

-Peff

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Dec 02, 2015 at 03:31:41PM -0800, Junio C Hamano wrote:
>
>> I just finished my first pass of going through "cook -w" output and
>> had trouble judging jk/send-email-ssl-errors topic, which is marked
>> as "waiting for re-roll", but I cannot seem to find any discussion
>> on it, just the original patch $gmane/281655.  Are there concerns?
>
> Looks like it needs a slight tweak:
>
>   http://article.gmane.org/gmane.comp.version-control.git/281693
>
> -Peff

Thanks.  I added a note to myself after the "waiting for re-roll"
comment to remind me.

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[David Turner]

On Wed, 2015-12-02 at 14:11 -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > What's cooking in git.git (Dec 2015, #01; Tue, 1)
> > --------------------------------------------------
> >
> > Here are the topics that have been cooking.  Commits prefixed with
> > '-' are only in 'pu' (proposed updates) while commits prefixed with
> > '+' are in 'next'.
> >
> > This should by my final whats-cooking before handing things back to
> > Junio. Thanks all for review help and for your patience during the past
> > few weeks.
> 
> I think I managed to get my working area (together with a handful of
> new entries in the rerere database and a few merge-fix/ entries) in
> sync with what you pushed out well enough that my automated
> procedure would recreate the status of various branches you pushed
> out exactly.
> 
> I haven't caught up with the changes in the component branches,
> though, so it may take a few days until I start picking up new
> topics from the list traffic.
> 
> > * bc/object-id (2015-11-20) 12 commits
> >  - remote: convert functions to struct object_id
> >  - Remove get_object_hash.
> >  - Convert struct object to object_id
> >  - Add several uses of get_object_hash.
> >  - object: introduce get_object_hash macro.
> >  - ref_newer: convert to use struct object_id
> >  - push_refs_with_export: convert to struct object_id
> >  - get_remote_heads: convert to struct object_id
> >  - parse_fetch: convert to use struct object_id
> >  - add_sought_entry_mem: convert to struct object_id
> >  - Convert struct ref to use object_id.
> >  - sha1_file: introduce has_object_file helper.
> >
> >  More transition from "unsigned char[40]" to "struct object_id".
> >
> >  This needed a few merge fixups, but is mostly disentangled from other
> >  topics.
> >
> >  Will merge to 'next'.
> 
> Aside from niggles on titles of a handful of changes in this topic,
> I have a bit of concern with this one and dt/refs-backend-pre-vtable
> topic (marked as "Will merge to 'master' two cycles from now.",
> which I am reading as "two cycles" means 2 x (8-10 week release
> cycle), not "two integration cycles by the maintainer, aka two
> issues of What's cooking report", which is typically less than a
> week).
> 
> The merge resolution in 'pu' discards what this topic did to refs.c
> because much of the original goes away from there, but does it mean
> (remember, I haven't caught up with the contents of the topics yet)
> that the merge reverts part of what this topic did, and in an ideal
> world, if the other one were more mature when this topic got
> started, more use of "unsigned char[40]" would have been migrated to
> "struct object_id" in new files the other one introduced?  Or
> perhaps we would want to go the other way around, i.e. as this topic
> conceptually is fairly straight-forward, merge this to 'next' and
> then down to 'master' (which would not take two release cycles) and
> then redo the other topic on top?
> 
> > * mr/ff-refs (2015-11-28) 6 commits
> >  - builtin/ff-refs.c: mark some file-local variables static
> >  - ff-refs: Add tests
> >  - ff-refs: Add documentation
> >  - ff-refs: add --dry-run and --skip-worktree options
> >  - ff-refs: update each updatable ref
> >  - ff-refs: builtin cmd to check and fast forward local refs to their upstream
> >
> >  Specialized command to fast-forward refs to match their upstream.
> >
> >  I remain skeptical that this is necessary or sufficient. Comments
> >  welcome.
> >
> >  Will hold.
> 
> This is another one that needs some evil-merge interaction with
> bc/object-id, but I have a feeling that this is not such a good
> addition to our workflow elements, so I am not worried too much
> about it.  I'm inclined to eject this topic (and will welcome if
> people come up with an alternative, perhaps based on the "let fetch
> do so instead" approach discussed there).
> 
> > * ps/rebase-keep-empty (2015-11-24) 2 commits
> >  - rebase: fix preserving commits with --keep-empty
> >  - rebase: test broken behavior with --keep-empty
> >
> >  Keep duplicate commits via rebase --keep-empty.
> >
> >  I'm not sure if I agree with this interpretation of the "rebase
> >  --keep-empty" documentation, but I haven't thought too hard about it.
> >  Comments welcome.
> 
> "--keep-empty" has always been about keeping an originally empty
> commit, not a commit that becomes empty because of rebasing
> (i.e. what has already been applied to the updated base).  The
> documentation, if it leads to any other interpretation, needs to be
> fixed.
> 
> Besides, if "--keep-empty" were to mean "keep redundant ones that
> are already in the updated base", the patch must do a lot more,
> e.g. stop filtering with git-cherry patch equivalence.
> 
> I'm inclined to eject this topic.
> 
> 
> > * ls/test-must-fail-sigpipe (2015-11-28) 2 commits
> >   (merged to 'next' on 2015-12-01 at d374686)
> >  + add "ok=sigpipe" to test_must_fail and use it to fix flaky tests
> >  + implement test_might_fail using a refactored test_must_fail
> >
> >  Fix some racy client/server tests by treating SIGPIPE the same as a
> >  normal non-zero exit.
> >
> >  Will merge to 'master' two cycles from now.
> 
> Hmm, perhaps I misread what you meant by "two cycles", as this is
> only the test suite and I cannot imagine we would want to be
> ultra-safe to cook that for two release cycles, and you did mean two
> issues of "What's cooking" report?
> 
> If so, I'll have to rethink the comment on bc/object-id I made
> earlier...
> 
> > * dt/refs-backend-pre-vtable (2015-11-20) 10 commits
> >   (merged to 'next' on 2015-11-24 at 8fd7293)
> >  + refs: break out ref conflict checks
> >  + files_log_ref_write: new function
> >  + initdb: make safe_create_dir public
> >  + refs: split filesystem-based refs code into a new file
> >  + refs/refs-internal.h: new header file
> >  + refname_is_safe(): improve docstring
> >  + pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref()
> >  + copy_msg(): rename to copy_reflog_msg()
> >  + verify_refname_available(): new function
> >  + verify_refname_available(): rename function
> >
> >  Code preparation for pluggable ref backends.
> >
> >  Will merge to 'master' two cycles from now.
> 
> ... that is, I'd very much prefer bc/object-id redone on top of an
> updated codebase that already has dt/refs-backend-pre-vtable in it.

>From a selfish perspective, I, would prefer for object-ids to not happen
quite yet for the refs code.  I have already prepared (but not yet sent)
a new version of the refs backend vtable (and lmdb) code on top of
refs-backend-pre-vtable, and it'll be a hassle to reroll it on top of
new object-id stuff.

I guess I'll go ahead and send mine now, and we can later make a
decision about how to deal with the object-id stuff.

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:
>
>> I think I managed to get my working area (together with a handful of
>> new entries in the rerere database and a few merge-fix/ entries) in
>> sync with what you pushed out well enough that my automated
>> procedure would recreate the status of various branches you pushed
>> out exactly.
>> 
>> I haven't caught up with the changes in the component branches,
>> though, so it may take a few days until I start picking up new
>> topics from the list traffic.
>
> My whole workspace is at https://github.com/peff/git, if fetching that
> directly is easier. I just noticed that my refspecs were not configured
> to push up refs/merge-fix. I've just fixed that and pushed again.
>
> I'll leave it that way for a few more days, but then will probably take
> it back to my usual contributor setup (i.e., just my topics and personal
> integration branches).
>
> Let me know if there's anything else I can do to help with the handoff.

I've rebuilt 'pu' (and 'jch') with the component topics myself,
following the exact order of merges you had between master..pu, in
order to make sure that I fully made my working area in sync with
your merge resolutions, meaning that there shouldn't be any
differences between trees of the tips of integration branches.

The result has been pushed out to various places.  The push to
https://github.com/git/git/ resulted in a single 'pu' update (the
trees did not change, the merge history was rebuilt as stated in the
previous paragraph).  Other repositories, i.e.

  git://git.kernel.org/pub/scm/git/git.git/
  git://repo.or.cz/alt-git.git/
  git://git.sourceforge.jp/gitroot/git-core/git.git/
  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/

received various updates to match your last integration results.

So it is OK for you to set your workspace back to your usual
contributor settings.  I can continue from here on.

Note that I haven't made any new merges, picked up any new topics or
replaced an old patch on an existing topic with a new one (yet).
Hopefully I can get to that tomorrow.

Thanks.

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[brian m. carlson]

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

On Wed, Dec 02, 2015 at 07:29:40PM -0500, David Turner wrote:
> From a selfish perspective, I, would prefer for object-ids to not happen
> quite yet for the refs code.  I have already prepared (but not yet sent)
> a new version of the refs backend vtable (and lmdb) code on top of
> refs-backend-pre-vtable, and it'll be a hassle to reroll it on top of
> new object-id stuff.
> 
> I guess I'll go ahead and send mine now, and we can later make a
> decision about how to deal with the object-id stuff.

As Jeff pointed out, the patches to refs.c were mostly dropped, as the
code that they modified had been removed.  The likelihood of conflict is
therefore low unless you're using struct object a lot.

My preference is that new code use object_id where possible, because
otherwise I'm going to have to go through it later and fix it up.
Keeping in mind that the refs code is likely to undergo a lot of
changes, I'll try to keep away from it for now, but it will need to be
converted at some point.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Patrick Steinhardt]

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

On Wed, Dec 02, 2015 at 05:31:14PM -0500, Jeff King wrote:
> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:
[snip]
> > "--keep-empty" has always been about keeping an originally empty
> > commit, not a commit that becomes empty because of rebasing
> > (i.e. what has already been applied to the updated base).  The
> > documentation, if it leads to any other interpretation, needs to be
> > fixed.
> > 
> > Besides, if "--keep-empty" were to mean "keep redundant ones that
> > are already in the updated base", the patch must do a lot more,
> > e.g. stop filtering with git-cherry patch equivalence.
> > 
> > I'm inclined to eject this topic.
> 
> That was my thinking too (and I notice it didn't get any review from
> anybody else).
[snip]

Well, I kind of agree. The cherry-pick command has both
--allow-empty and --keep-redundant flags, where the second one is
the kind of behavior I want to achieve in my case. As an
alternative to the proposed change to `--keep-empty` I could
instead introduce a new flag `--keep-redundant-commits` to `git
rebase` which would then pass the flag through to the
cherry-pick.

Any opinions on this?

Patrick

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Junio C Hamano]

Patrick Steinhardt <ps@pks.im> writes:

> On Wed, Dec 02, 2015 at 05:31:14PM -0500, Jeff King wrote:
>> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:
> [snip]
>> > "--keep-empty" has always been about keeping an originally empty
>> > commit, not a commit that becomes empty because of rebasing
>> > (i.e. what has already been applied to the updated base).  The
>> > documentation, if it leads to any other interpretation, needs to be
>> > fixed.
>> > 
>> > Besides, if "--keep-empty" were to mean "keep redundant ones that
>> > are already in the updated base", the patch must do a lot more,
>> > e.g. stop filtering with git-cherry patch equivalence.
>> > 
>> > I'm inclined to eject this topic.
>> 
>> That was my thinking too (and I notice it didn't get any review from
>> anybody else).
> [snip]
>
> Well, I kind of agree. The cherry-pick command has both
> --allow-empty and --keep-redundant flags, where the second one is
> the kind of behavior I want to achieve in my case. As an
> alternative to the proposed change to `--keep-empty` I could
> instead introduce a new flag `--keep-redundant-commits` to `git
> rebase` which would then pass the flag through to the
> cherry-pick.
>
> Any opinions on this?

Honestly, I am not interested if that is only about passing that
option and doing nothing else.

Imagine that you have two changes from the branch being rebased
already in the updated base, one was accepted verbatim, while the
other one was accepted with a slight tweak.  Perhaps there were some
conflicts in the context, or something.

When you run your rebase, the former will not even be considered
because command will notice, via patch equivalence, that you do not
need it, even before it attempts to replay it.  But not the latter.
The command will attempt to replay it, and only in this step it may
notice, by seeing that the result becomes a no-op change, that the
change has already been included in the updated base.

I cannot quite see how adding "--keep-redundant-commits" to the
command would help anybody by allowing the latter in the history but
not the former.  That is primarily because you can imagine a future
in which the patch equivalence determination becomes smarter.  With
or without "--keep-redundant-commits", both of these two changes
would not appear in the resulting history when that happens.

The "--keep-redundant" option to "cherry-pick" makes sense, as the
user will be the one who is deciding which commit to replay on top
of a new base.  If the user fed a commit that is already in the new
base, and the command is run with the option, that is a deliberate
request to leave a no-op cruft.

We cannot say the same thing for "rebase", as it tries to avoid
redundant cruft, and it cannot do as good a job as humans in doing
so.  The "--keep-redundant-commits" option will become a way to make
a distinction between what got dropped by the command automatically
and what didn't get dropped because the command did not look deeply
enough.  That distinction is not at all useful, as that can change
as the tool improves.

A "--keep-redundant-commits" to "rebase" that also disables the
patch equivalence filtering (not just keeping empty crufts in the
resulting history) might make sense, but I do not see myself (or
anybody sane) using it.  "In what situation would such a feature be
useful?" is a question I cannot answer offhand.

Re: What's cooking in git.git (Dec 2015, #01; Tue, 1)

[Patrick Steinhardt]

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

On Mon, Dec 07, 2015 at 11:24:52AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Wed, Dec 02, 2015 at 05:31:14PM -0500, Jeff King wrote:
> >> On Wed, Dec 02, 2015 at 02:11:32PM -0800, Junio C Hamano wrote:
> > [snip]
> >> > "--keep-empty" has always been about keeping an originally empty
> >> > commit, not a commit that becomes empty because of rebasing
> >> > (i.e. what has already been applied to the updated base).  The
> >> > documentation, if it leads to any other interpretation, needs to be
> >> > fixed.
> >> > 
> >> > Besides, if "--keep-empty" were to mean "keep redundant ones that
> >> > are already in the updated base", the patch must do a lot more,
> >> > e.g. stop filtering with git-cherry patch equivalence.
> >> > 
> >> > I'm inclined to eject this topic.
> >> 
> >> That was my thinking too (and I notice it didn't get any review from
> >> anybody else).
> > [snip]
> >
> > Well, I kind of agree. The cherry-pick command has both
> > --allow-empty and --keep-redundant flags, where the second one is
> > the kind of behavior I want to achieve in my case. As an
> > alternative to the proposed change to `--keep-empty` I could
> > instead introduce a new flag `--keep-redundant-commits` to `git
> > rebase` which would then pass the flag through to the
> > cherry-pick.
> >
> > Any opinions on this?
> 
> Honestly, I am not interested if that is only about passing that
> option and doing nothing else.
> 
> Imagine that you have two changes from the branch being rebased
> already in the updated base, one was accepted verbatim, while the
> other one was accepted with a slight tweak.  Perhaps there were some
> conflicts in the context, or something.
> 
> When you run your rebase, the former will not even be considered
> because command will notice, via patch equivalence, that you do not
> need it, even before it attempts to replay it.  But not the latter.
> The command will attempt to replay it, and only in this step it may
> notice, by seeing that the result becomes a no-op change, that the
> change has already been included in the updated base.
> 
> I cannot quite see how adding "--keep-redundant-commits" to the
> command would help anybody by allowing the latter in the history but
> not the former.  That is primarily because you can imagine a future
> in which the patch equivalence determination becomes smarter.  With
> or without "--keep-redundant-commits", both of these two changes
> would not appear in the resulting history when that happens.
> 
> The "--keep-redundant" option to "cherry-pick" makes sense, as the
> user will be the one who is deciding which commit to replay on top
> of a new base.  If the user fed a commit that is already in the new
> base, and the command is run with the option, that is a deliberate
> request to leave a no-op cruft.
> 
> We cannot say the same thing for "rebase", as it tries to avoid
> redundant cruft, and it cannot do as good a job as humans in doing
> so.  The "--keep-redundant-commits" option will become a way to make
> a distinction between what got dropped by the command automatically
> and what didn't get dropped because the command did not look deeply
> enough.  That distinction is not at all useful, as that can change
> as the tool improves.
> 
> A "--keep-redundant-commits" to "rebase" that also disables the
> patch equivalence filtering (not just keeping empty crufts in the
> resulting history) might make sense, but I do not see myself (or
> anybody sane) using it.  "In what situation would such a feature be
> useful?" is a question I cannot answer offhand.

The scenario I require this feature for is somewhat more exotic,
yes. We've got a CI where published branches can be rebased but
should not be modified in their commit history. That is, the CI
determines in a hook wether the branch that is being pushed drops
or re-orders commits and if so, rejects the branch.

So when a commit that is already included in origin/master gets
rebased `git-rebase` currently simply drops the commit, which
causes the CI to refuse the branch on a push.

So obviously you are right in your conclusion that
`--keep-redundant-commits` has to skip the patch equivalence
determination in order to not drop any commits. Otherwise my
change would only work for certain scenarios.

That said, I do not care too deeply about this patch, especially
as my scenario is rather uncommon. If you deem this to not have
any greater benefit you may simply drop it.

Patrick

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]