What's cooking in git.git (Apr 2018, #02; Tue, 17)

What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

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

I try to summarize what each topic is about immediately after the
list of commits on the topic, which may be followed by a short term
plan for the topic ("Will merge to 'next'", etc.), possibly followed
by a reminder (e.g. "cf. <message-id>") to help me recall the reason
behind the plan.  Please do not read more than that into "cf." (e.g.
the ones listed are not more important than other messages in the
same thread).

You can find the changes described here in the integration branches
of the repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

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

* bt/gpg-interface (2018-04-16) 7 commits
 - gpg-interface: find the last gpg signature line
 - gpg-interface: extract gpg line matching helper
 - gpg-interface: fix const-correctness of "eol" pointer
 - gpg-interface: use size_t for signature buffer size
 - gpg-interface: modernize function declarations
 - gpg-interface: handle bool user.signingkey
 - t7004: fix mistaken tag name

 What is queued here is only the obviously correct and
 uncontroversial code clean-up part, which is an earlier 7 patches,
 of a larger series.

 The remainder that is not queued introuces a few configuration
 variables to deal with e-signature backends with different
 signature format.

 I am not sure if this is going in a good direction.  Wouldn't it
 encourage fragmenting the world even more?


* cb/bash-completion-ls-files-processing (2018-04-10) 1 commit
  (merged to 'next' on 2018-04-17 at 956b155366)
 + completion: improve ls-files filter performance

 Shell completion (in contrib) that gives list of paths have been
 optimized somewhat.

 Will merge to 'master'.


* ds/generation-numbers (2018-04-11) 10 commits
 - commit: add short-circuit to paint_down_to_common()
 - commit: use generation numbers for in_merge_bases()
 - ref-filter: use generation number for --contains
 - commit-graph.txt: update future work
 - commit.c: use generation to halt paint walk
 - commit: use generations in paint_down_to_common()
 - commit-graph: compute generation numbers
 - commit: add generation number to struct commmit
 - merge: check config before loading commits
 - object.c: parse commit in graph first
 (this branch uses ds/commit-graph; is tangled with ds/lazy-load-trees.)

 A recently added "commit-graph" datafile has learned to store
 pre-computed generation numbers to speed up the decisions to stop
 history traversal.

 Expecting a reroll.
 cf. <cc58d8c1-f8de-4841-934f-56e4ad7729aa@gmail.com>


* bp/fsexcludes (2018-04-16) 2 commits
 - fsmonitor: switch to use new fsexcludes logic and remove unused untracked cache based logic
 - fsexcludes: add a programmatic way to exclude files from git's working directory traversal logic

 Can we have a few lines summary here, just like we have for other
 topic ;-) I personally take the overlong title of these commits as
 a sign that they can further be simplified and cleaned up by
 splitting, focusing the scope, etc.

 Waiting for a bit more discussion.
 cf. <CACsJy8B+fTfUiGA-cFE5QEipa_4pSfC4_GhUSJvCKL82G21xWw@mail.gmail.com>


* bp/fsmonitor-bufsize-fix (2018-04-11) 1 commit
  (merged to 'next' on 2018-04-17 at 70a7091e06)
 + fsmonitor: fix incorrect buffer size when printing version number

 Fix an unexploitable (because the oversized contents are not under
 attacker's control) buffer overflow.

 Will merge to 'master'.


* bp/fsmonitor-prime-index (2018-04-11) 1 commit
  (merged to 'next' on 2018-04-17 at 765edccdf0)
 + fsmonitor: force index write after full scan

 The index file is updated to record the fsmonitor section after a
 full scan was made, to avoid wasting the effort that has already
 spent.

 Will merge to 'master'.


* cc/perf-bisect (2018-04-11) 2 commits
  (merged to 'next' on 2018-04-17 at 62a1498dd0)
 + t/perf: add scripts to bisect performance regressions
 + perf/run: add --subsection option

 Performance measuring framework in t/perf learned to help bisecting
 performance regressions.

 Will merge to 'master'.


* en/rename-directory-detection-reboot (2018-04-16) 32 commits
 - merge-recursive: fix check for skipability of working tree updates
 - merge-recursive: Fix was_tracked() to quit lying with some renamed paths
 - t6046: testcases checking whether updates can be skipped in a merge
 - merge-recursive: improve output precision around skipping updates
 - merge-recursive: avoid spurious rename/rename conflict from dir renames
 - directory rename detection: new testcases showcasing a pair of bugs
 - merge-recursive: fix remaining directory rename + dirty overwrite cases
 - merge-recursive: fix overwriting dirty files involved in renames
 - merge-recursive: avoid clobbering untracked files with directory renames
 - merge-recursive: apply necessary modifications for directory renames
 - merge-recursive: when comparing files, don't include trees
 - merge-recursive: check for file level conflicts then get new name
 - merge-recursive: add computation of collisions due to dir rename & merging
 - merge-recursive: check for directory level conflicts
 - merge-recursive: add get_directory_renames()
 - merge-recursive: make a helper function for cleanup for handle_renames
 - merge-recursive: split out code for determining diff_filepairs
 - merge-recursive: make !o->detect_rename codepath more obvious
 - merge-recursive: fix leaks of allocated renames and diff_filepairs
 - merge-recursive: introduce new functions to handle rename logic
 - merge-recursive: move the get_renames() function
 - directory rename detection: tests for handling overwriting dirty files
 - directory rename detection: tests for handling overwriting untracked files
 - directory rename detection: miscellaneous testcases to complete coverage
 - directory rename detection: testcases exploring possibly suboptimal merges
 - directory rename detection: more involved edge/corner testcases
 - directory rename detection: testcases checking which side did the rename
 - directory rename detection: files/directories in the way of some renames
 - directory rename detection: partially renamed directory testcase/discussion
 - directory rename detection: testcases to avoid taking detection too far
 - directory rename detection: directory splitting testcases
 - directory rename detection: basic testcases

 Reboot of an attempt to detect wholesale directory renames and use
 it while merging.


* fg/completion-external (2018-04-11) 1 commit
 - completion: load completion file for external subcommand

 The command line completion mechanism (in contrib/) learned to load
 custom completion file for "git $command" where $command is a
 custom "git-$command" that the end user has on the $PATH when using
 newer version of bash.

 Will merge to 'next'.


* nd/command-list (2018-04-16) 7 commits
 - SQUASH???
 - help: use command-list.txt for the source of guides
 - help: add "-a --verbose" to list all commands with synopsis
 - git.c: implement --list-cmds=porcelain
 - generate-cmdlist.sh: keep all information in common-cmds.h
 - git.c: implement --list-cmds=all and use it in git-completion.bash
 - git.c: convert --list-builtins to --list-cmds=builtins

 The list of commands with their various attributes were spread
 across a few places in the build procedure, but it now is getting a
 bit more consolidated to allow more automation.

 Expecting a reroll.
 Bash-isms and other things need to be fixed.


* sb/filenames-with-dashes (2018-04-11) 6 commits
  (merged to 'next' on 2018-04-17 at 45fdeb5cb1)
 + replace_object.c: rename to use dash in file name
 + sha1_file.c: rename to use dash in file name
 + sha1_name.c: rename to use dash in file name
 + exec_cmd: rename to use dash in file name
 + unicode_width.h: rename to use dash in file name
 + write_or_die.c: rename to use dashes in file name

 Rename bunch of source files to more consistently use dashes
 instead of underscores to connect words.

 Will merge to 'master'.


* sb/object-store-replace (2018-04-12) 15 commits
 - replace-object: allow lookup_replace_object to handle arbitrary repositories
 - replace-object: allow do_lookup_replace_object to handle arbitrary repositories
 - replace-object: allow prepare_replace_object to handle arbitrary repositories
 - refs: allow for_each_replace_ref to handle arbitrary repositories
 - refs: store the main ref store inside the repository struct
 - replace-object: add repository argument to lookup_replace_object
 - replace-object: add repository argument to do_lookup_replace_object
 - replace-object: add repository argument to prepare_replace_object
 - refs: add repository argument to for_each_replace_ref
 - refs: add repository argument to get_main_ref_store
 - replace-object: check_replace_refs is safe in multi repo environment
 - replace-object: eliminate replace objects prepared flag
 - object-store: move lookup_replace_object to replace-object.h
 - replace-object: move replace_map to object store
 - replace_object: use oidmap

 The effort to pass the repository in-core structure throughout the
 API continues.  This round deals with the code that implements the
 refs/replace/ mechanism.

 What's the doneness of this thing?  I didn't recall seeing any
 response, especially ones that demonstrated the reviewer carefully
 read and thought about the issues surrounding the code.  Not that I
 spotted any problems in these patches myself, though.


* tg/use-git-contacts (2018-04-12) 1 commit
  (merged to 'next' on 2018-04-17 at 26cf8c1d8c)
 + SubmittingPatches: mention the git contacts command

 Doc update.

 Will merge to 'master'.


* hn/bisect-first-parent (2018-04-17) 1 commit
 - bisect: create 'bisect_flags' parameter in find_bisection()

 Preliminary code update to allow passing more flags down the
 bisection codepath in the future.

 We do not add random code that does not have real users to our
 codebase, so let's have it wait until such a real code materializes
 before too long.


* sg/complete-paths (2018-04-17) 11 commits
 - completion: fill COMPREPLY directly when completing paths
 - completion: improve handling quoted paths in 'git ls-files's output
 - completion: remove repeated dirnames with 'awk' during path completion
 - t9902-completion: ignore COMPREPLY element order in some tests
 - completion: use 'awk' to strip trailing path components
 - completion: let 'ls-files' and 'diff-index' filter matching paths
 - completion: improve handling quoted paths on the command line
 - completion: support completing non-ASCII pathnames
 - completion: simplify prefix path component handling during path completion
 - completion: move __git_complete_index_file() next to its helpers
 - t9902-completion: add tests demonstrating issues with quoted pathnames

 Command line completion (in contrib/) learned to complete pathnames
 for various commands better.


* so/grossary-ancestor (2018-04-17) 1 commit
 - glossary: substitute "ancestor" for "direct ancestor" in 'push' description.

 Docfix.

 Will merge to 'next'.


* tq/t1510 (2018-04-17) 1 commit
 - t1510-repo-setup.sh: remove useless mkdir

 Test cleanup.

 Will merge to 'next'.

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

* ab/doc-hash-brokenness (2018-03-27) 2 commits
  (merged to 'next' on 2018-03-29 at e9b2f5cf4a)
 + doc hash-function-transition: clarify what SHAttered means
 + doc hash-function-transition: clarify how older gits die on NewHash

 Doc updates.


* ab/drop-contrib-examples (2018-03-26) 1 commit
  (merged to 'next' on 2018-03-29 at 9d8a7603b5)
 + Remove contrib/examples/*


* ab/install-symlinks (2018-03-15) 3 commits
  (merged to 'next' on 2018-03-15 at 99d6bd6cb3)
 + Makefile: optionally symlink libexec/git-core binaries to bin/git
 + Makefile: add a gitexecdir_relative variable
 + Makefile: fix broken bindir_relative variable

 The build procedure learned to optionally use symbolic links
 (instead of hardlinks and copies) to install "git-foo" for built-in
 commands, whose binaries are all identical.


* ab/pcre-v2 (2018-03-14) 3 commits
  (merged to 'next' on 2018-03-15 at e77b116903)
 + Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1
 + configure: detect redundant --with-libpcre & --with-libpcre1
 + configure: fix a regression in PCRE v1 detection

 Git can be built to use either v1 or v2 of the PCRE library, and so
 far, the build-time configuration USE_LIBPCRE=YesPlease instructed
 the build procedure to use v1, but now it means v2.  USE_LIBPCRE1
 and USE_LIBPCRE2 can be used to explicitly choose which version to
 use, as before.


* bc/hash-independent-tests (2018-03-26) 10 commits
  (merged to 'next' on 2018-03-29 at 11179d9b71)
 + t2107: abstract away SHA-1-specific constants
 + t2101: abstract away SHA-1-specific constants
 + t2101: modernize test style
 + t2020: abstract away SHA-1 specific constants
 + t1507: abstract away SHA-1-specific constants
 + t1411: abstract away SHA-1-specific constants
 + t1405: sort reflog entries in a hash-independent way
 + t1300: abstract away SHA-1-specific constants
 + t1304: abstract away SHA-1-specific constants
 + t1011: abstract away SHA-1-specific constants

 Tests that rely on the exact hardcoded values of object names have
 been updated in preparation for hash function migration.


* bc/object-id (2018-03-14) 36 commits
  (merged to 'next' on 2018-03-20 at f1800a33ff)
 + convert: convert to struct object_id
 + sha1_file: introduce a constant for max header length
 + Convert lookup_replace_object to struct object_id
 + sha1_file: convert read_sha1_file to struct object_id
 + sha1_file: convert read_object_with_reference to object_id
 + tree-walk: convert tree entry functions to object_id
 + streaming: convert istream internals to struct object_id
 + tree-walk: convert get_tree_entry_follow_symlinks internals to object_id
 + builtin/notes: convert static functions to object_id
 + builtin/fmt-merge-msg: convert remaining code to object_id
 + sha1_file: convert sha1_object_info* to object_id
 + Convert remaining callers of sha1_object_info_extended to object_id
 + packfile: convert unpack_entry to struct object_id
 + sha1_file: convert retry_bad_packed_offset to struct object_id
 + sha1_file: convert assert_sha1_type to object_id
 + builtin/mktree: convert to struct object_id
 + streaming: convert open_istream to use struct object_id
 + sha1_file: convert check_sha1_signature to struct object_id
 + sha1_file: convert read_loose_object to use struct object_id
 + builtin/index-pack: convert struct ref_delta_entry to object_id
 + archive: convert sha1_file_to_archive to struct object_id
 + archive: convert write_archive_entry_fn_t to object_id
 + builtin/mktag: convert to struct object_id
 + replace_object: convert struct replace_object to object_id
 + send-pack: convert remaining functions to struct object_id
 + http-walker: convert struct object_request to use struct object_id
 + Convert find_unique_abbrev* to struct object_id
 + wt-status: convert struct wt_status_state to object_id
 + strbuf: convert strbuf_add_unique_abbrev to use struct object_id
 + ref-filter: convert grab_objectname to struct object_id
 + tree: convert read_tree_recursive to struct object_id
 + resolve-undo: convert struct resolve_undo_info to object_id
 + cache-tree: convert remnants to struct object_id
 + cache-tree: convert write_*_as_tree to object_id
 + builtin/write-tree: convert to struct object_id
 + bulk-checkin: convert index_bulk_checkin to struct object_id
 (this branch is used by ds/bsearch-hash.)

 Conversion from uchar[20] to struct object_id continues.


* cc/perf-aggregate-sort (2018-03-27) 2 commits
  (merged to 'next' on 2018-03-29 at 0251068bac)
 + perf/aggregate: add --sort-by=regression option
 + perf/aggregate: add display_dir()

 Perf-test update.


* ds/bsearch-hash (2018-03-25) 4 commits
  (merged to 'next' on 2018-03-29 at 561d5577a7)
 + sha1_name: use bsearch_pack() in unique_in_pack()
 + sha1_name: use bsearch_pack() for abbreviations
 + packfile: define and use bsearch_pack()
 + sha1_name: convert struct min_abbrev_data to object_id

 Code to find the length to uniquely abbreviate object names based
 on packfile content, which is a relatively recent addtion, has been
 optimized to use the same fan-out table.


* eb/cred-helper-ignore-sigpipe (2018-03-29) 1 commit
  (merged to 'next' on 2018-03-30 at c48e98c1b1)
 + credential: ignore SIGPIPE when writing to credential helpers

 When credential helper exits very quickly without reading its
 input, it used to cause Git to die with SIGPIPE, which has been
 fixed.


* en/rename-directory-detection (2018-02-27) 29 commits
  (merged to 'next' on 2018-03-06 at d42470f86e)
 + merge-recursive: ensure we write updates for directory-renamed file
 + merge-recursive: avoid spurious rename/rename conflict from dir renames
 + directory rename detection: new testcases showcasing a pair of bugs
 + merge-recursive: fix remaining directory rename + dirty overwrite cases
 + merge-recursive: fix overwriting dirty files involved in renames
 + merge-recursive: avoid clobbering untracked files with directory renames
 + merge-recursive: apply necessary modifications for directory renames
 + merge-recursive: when comparing files, don't include trees
 + merge-recursive: check for file level conflicts then get new name
 + merge-recursive: add computation of collisions due to dir rename & merging
 + merge-recursive: check for directory level conflicts
 + merge-recursive: add get_directory_renames()
 + merge-recursive: make a helper function for cleanup for handle_renames
 + merge-recursive: split out code for determining diff_filepairs
 + merge-recursive: make !o->detect_rename codepath more obvious
 + merge-recursive: fix leaks of allocated renames and diff_filepairs
 + merge-recursive: introduce new functions to handle rename logic
 + merge-recursive: move the get_renames() function
 + directory rename detection: tests for handling overwriting dirty files
 + directory rename detection: tests for handling overwriting untracked files
 + directory rename detection: miscellaneous testcases to complete coverage
 + directory rename detection: testcases exploring possibly suboptimal merges
 + directory rename detection: more involved edge/corner testcases
 + directory rename detection: testcases checking which side did the rename
 + directory rename detection: files/directories in the way of some renames
 + directory rename detection: partially renamed directory testcase/discussion
 + directory rename detection: testcases to avoid taking detection too far
 + directory rename detection: directory splitting testcases
 + directory rename detection: basic testcases

 Rename detection logic in "diff" family that is used in "merge" has
 learned to guess when all of x/a, x/b and x/c have moved to z/a,
 z/b and z/c, it is likely that x/d added in the meantime would also
 want to move to z/d by taking the hint that the entire directory
 'x' moved to 'z'.  A bug causing dirty files involved in a rename
 to be overwritten during merge has also been fixed as part of this
 work.


* jc/test-must-be-empty (2018-03-27) 1 commit
  (merged to 'next' on 2018-03-29 at 2e64650f23)
 + test_must_be_empty: simplify file existence check

 Test helper update.


* jk/diff-highlight-graph-fix (2018-03-21) 7 commits
  (merged to 'next' on 2018-03-29 at eb995f66e3)
 + diff-highlight: detect --graph by indent
 + diff-highlight: use flush() helper consistently
 + diff-highlight: test graphs with --color
 + diff-highlight: test interleaved parallel lines of history
 + diff-highlight: prefer "echo" to "cat" in tests
 + diff-highlight: use test_tick in graph test
 + diff-highlight: correct test graph diagram

 "diff-highlight" filter (in contrib/) learned to undertand "git log
 --graph" output better.


* lv/tls-1.3 (2018-03-29) 1 commit
  (merged to 'next' on 2018-03-30 at 4f13731408)
 + http: allow use of TLS 1.3

 When built with more recent cURL, GIT_SSL_VERSION can now specify
 "tlsv1.3" as its value.


* ma/shortlog-revparse (2018-03-15) 3 commits
  (merged to 'next' on 2018-03-15 at 2c2de7eb95)
 + shortlog: disallow left-over arguments outside repo
 + shortlog: add usage-string for stdin-reading
 + git-shortlog.txt: reorder usages

 "git shortlog cruft" aborted with a BUG message when run outside a
 Git repository.  The command has been taught to complain about
 extra and unwanted arguments on its command line instead in such a
 case.


* ml/filter-branch-no-op-error (2018-03-15) 1 commit
  (merged to 'next' on 2018-03-15 at ba8ac48dec)
 + filter-branch: return 2 when nothing to rewrite

 "git filter-branch" learned to use a different exit code to allow
 the callers to tell the case where there was no new commits to
 rewrite from other error cases.


* nd/combined-test-helper (2018-03-27) 36 commits
  (merged to 'next' on 2018-03-30 at ea73d57c30)
 + t/helper: merge test-write-cache into test-tool
 + t/helper: merge test-wildmatch into test-tool
 + t/helper: merge test-urlmatch-normalization into test-tool
 + t/helper: merge test-subprocess into test-tool
 + t/helper: merge test-submodule-config into test-tool
 + t/helper: merge test-string-list into test-tool
 + t/helper: merge test-strcmp-offset into test-tool
 + t/helper: merge test-sigchain into test-tool
 + t/helper: merge test-sha1-array into test-tool
 + t/helper: merge test-scrap-cache-tree into test-tool
 + t/helper: merge test-run-command into test-tool
 + t/helper: merge test-revision-walking into test-tool
 + t/helper: merge test-regex into test-tool
 + t/helper: merge test-ref-store into test-tool
 + t/helper: merge test-read-cache into test-tool
 + t/helper: merge test-prio-queue into test-tool
 + t/helper: merge test-path-utils into test-tool
 + t/helper: merge test-online-cpus into test-tool
 + t/helper: merge test-mktemp into test-tool
 + t/helper: merge (unused) test-mergesort into test-tool
 + t/helper: merge (unused) test-match-trees into test-tool
 + t/helper: merge test-index-version into test-tool
 + t/helper: merge test-hashmap into test-tool
 + t/helper: merge test-genrandom into test-tool
 + t/helper: merge test-example-decorate into test-tool
 + t/helper: merge test-dump-split-index into test-tool
 + t/helper: merge test-dump-cache-tree into test-tool
 + t/helper: merge test-drop-caches into test-tool
 + t/helper: merge (unused) test-delta into test-tool
 + t/helper: merge test-date into test-tool
 + t/helper: merge test-ctype into test-tool
 + t/helper: merge test-config into test-tool
 + t/helper: merge test-lazy-init-name-hash into test-tool
 + t/helper: merge test-sha1 into test-tool
 + t/helper: merge test-chmtime into test-tool
 + t/helper: add an empty test-tool program

 Small test-helper programs have been consolidated into a single
 binary.


* nd/parseopt-completion-more (2018-03-25) 8 commits
  (merged to 'next' on 2018-03-29 at 9007b165e2)
 + completion: use __gitcomp_builtin in _git_cherry
 + completion: use __gitcomp_builtin in _git_ls_tree
 + completion: delete option-only completion commands
 + completion: add --option completion for most builtin commands
 + completion: factor out _git_xxx calling code
 + completion: mention the oldest version we need to support
 + git.c: add hidden option --list-parseopt-builtins
 + git.c: move cmd_struct declaration up

 The mechanism to use parse-options API to automate the command line
 completion continues to get extended and polished.


* nd/remove-ignore-env-field (2018-03-23) 6 commits
  (merged to 'next' on 2018-03-23 at ba9d0f2565)
 + repository.h: add comment and clarify repo_set_gitdir
  (merged to 'next' on 2018-03-15 at 802b6ea1cb)
 + repository: delete ignore_env member
 + sha1_file.c: move delayed getenv(altdb) back to setup_git_env()
 + repository.c: delete dead functions
 + repository.c: move env-related setup code back to environment.c
 + repository: initialize the_repository in main()
 (this branch is used by sb/object-store, sb/packfiles-in-repository and sb/submodule-move-nested.)

 Code clean-up for the "repository" abstraction.


* nd/trace-with-env (2018-03-25) 1 commit
  (merged to 'next' on 2018-03-29 at 6890e2c39b)
 + run-command: use strbuf_addstr() for adding a string to a strbuf

 Code cleanup.


* nd/worktree-prune (2018-03-15) 3 commits
  (merged to 'next' on 2018-03-20 at e2d9677b20)
 + worktree prune: improve prune logic when worktree is moved
 + worktree: delete dead code
 + gc.txt: more details about what gc does

 The way "git worktree prune" worked internally has been simplified,
 by assuming how "git worktree move" moves an existing worktree to a
 different place.


* pk/test-avoid-pipe-hiding-exit-status (2018-03-28) 1 commit
  (merged to 'next' on 2018-03-30 at 4f3df09139)
 + test: avoid pipes in git related commands for test

 Test cleanup.


* ps/contains-id-error-message (2018-03-22) 1 commit
  (merged to 'next' on 2018-03-22 at 3bb1dcd506)
 + parse-options: do not show usage upon invalid option value

 "git tag --contains no-such-commit" gave a full list of options
 after giving an error message.


* rs/status-with-removed-submodule (2018-03-28) 1 commit
  (merged to 'next' on 2018-03-30 at 8a7b618bc1)
 + submodule: check for NULL return of get_submodule_ref_store()

 "git submodule status" misbehaved on a submodule that has been
 removed from the working tree.


* sb/object-store (2018-03-26) 27 commits
  (merged to 'next' on 2018-03-30 at 93e3475178)
 + sha1_file: allow sha1_loose_object_info to handle arbitrary repositories
 + sha1_file: allow map_sha1_file to handle arbitrary repositories
 + sha1_file: allow map_sha1_file_1 to handle arbitrary repositories
 + sha1_file: allow open_sha1_file to handle arbitrary repositories
 + sha1_file: allow stat_sha1_file to handle arbitrary repositories
 + sha1_file: allow sha1_file_name to handle arbitrary repositories
 + sha1_file: add repository argument to sha1_loose_object_info
 + sha1_file: add repository argument to map_sha1_file
 + sha1_file: add repository argument to map_sha1_file_1
 + sha1_file: add repository argument to open_sha1_file
 + sha1_file: add repository argument to stat_sha1_file
 + sha1_file: add repository argument to sha1_file_name
 + sha1_file: allow prepare_alt_odb to handle arbitrary repositories
 + sha1_file: allow link_alt_odb_entries to handle arbitrary repositories
 + sha1_file: add repository argument to prepare_alt_odb
 + sha1_file: add repository argument to link_alt_odb_entries
 + sha1_file: add repository argument to read_info_alternates
 + sha1_file: add repository argument to link_alt_odb_entry
 + sha1_file: add raw_object_store argument to alt_odb_usable
 + pack: move approximate object count to object store
 + pack: move prepare_packed_git_run_once to object store
 + object-store: close all packs upon clearing the object store
 + object-store: move packed_git and packed_git_mru to object store
 + object-store: free alt_odb_list
 + object-store: move alt_odb_list and alt_odb_tail to object store
 + object-store: migrate alternates struct and functions from cache.h
 + repository: introduce raw object store field
 (this branch is used by sb/packfiles-in-repository and sb/submodule-move-nested.)

 Refactoring the internal global data structure to make it possible
 to open multiple repositories, work with and then close them.

 Rerolled by Duy on top of a separate preliminary clean-up topic.
 The resulting structure of the topics looked very sensible.


* sb/packfiles-in-repository (2018-03-26) 12 commits
  (merged to 'next' on 2018-03-30 at caa68db14d)
 + packfile: keep prepare_packed_git() private
 + packfile: allow find_pack_entry to handle arbitrary repositories
 + packfile: add repository argument to find_pack_entry
 + packfile: allow reprepare_packed_git to handle arbitrary repositories
 + packfile: allow prepare_packed_git to handle arbitrary repositories
 + packfile: allow prepare_packed_git_one to handle arbitrary repositories
 + packfile: add repository argument to reprepare_packed_git
 + packfile: add repository argument to prepare_packed_git
 + packfile: add repository argument to prepare_packed_git_one
 + packfile: allow install_packed_git to handle arbitrary repositories
 + packfile: allow rearrange_packed_git to handle arbitrary repositories
 + packfile: allow prepare_packed_git_mru to handle arbitrary repositories
 (this branch uses sb/object-store; is tangled with sb/submodule-move-nested.)

 Refactoring of the internal global data structure continues.


* tg/stash-untracked-with-pathspec-fix (2018-03-21) 4 commits
  (merged to 'next' on 2018-03-22 at 73c4bef74f)
 + stash: drop superfluos pathspec parameter
  (merged to 'next' on 2018-03-21 at 8f5b5ab131)
 + stash push -u: don't create empty stash
 + stash push: avoid printing errors
 + stash: fix nonsense pipeline

 "git stash push -u -- <pathspec>" gave an unnecessary and confusing
 error message when there was no tracked files that match the
 <pathspec>, which has been fixed.


* ti/fetch-everything-local-optim (2018-03-14) 1 commit
  (merged to 'next' on 2018-03-15 at 2be87aa7a7)
 + fetch-pack.c: use oidset to check existence of loose object

 A "git fetch" from a repository with insane number of refs into a
 repository that is already up-to-date still wasted too many cycles
 making many lstat(2) calls to see if these objects at the tips
 exist as loose objects locally.  These lstat(2) calls are optimized
 away by enumerating all loose objects beforehand.

 It is unknown if the new strategy negatively affects existing use
 cases, fetching into a repository with many loose objects from a
 repository with small number of refs.


* ws/rebase-p (2018-03-23) 8 commits
  (merged to 'next' on 2018-03-29 at d20ae8510e)
 + rebase: remove merges_option and a blank line
 + rebase: remove unused code paths from git_rebase__interactive__preserve_merges
 + rebase: remove unused code paths from git_rebase__interactive
 + rebase: add and use git_rebase__interactive__preserve_merges
 + rebase: extract functions out of git_rebase__interactive
 + rebase: reindent function git_rebase__interactive
 + rebase: update invocation of rebase dot-sourced scripts
 + rebase-interactive: simplify pick_on_preserving_merges

 Code clean-up.


* yk/filter-branch-non-committish-refs (2018-03-25) 1 commit
  (merged to 'next' on 2018-03-29 at 8ac3806bcf)
 + filter-branch: fix errors caused by refs that point at non-committish

 when refs that do not point at committish are given, "git
 filter-branch" gave a misleading error messages.  This has been
 corrected.


* ys/bisect-object-id-missing-conversion-fix (2018-03-25) 1 commit
  (merged to 'next' on 2018-03-29 at 7d988b57d4)
 + bisect: use oid_to_hex() for converting object_id hashes to hex strings

 Code clean-up.

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

* ld/p4-unshelve (2018-02-22) 1 commit
 - git-p4: add unshelve command

 "git p4" learned to "unshelve" shelved commit from P4.

 Will hold, perhaps drop and use format-change that uses a proper "diff".
 cf. <CAE5ih7_ooDMqVtTMoQ70s5XCkncr04HY0JkqSp1UmKQeG81oaA@mail.gmail.com>


* av/fsmonitor-updates (2018-01-04) 6 commits
 - fsmonitor: use fsmonitor data in `git diff`
 - fsmonitor: remove debugging lines from t/t7519-status-fsmonitor.sh
 - fsmonitor: make output of test-dump-fsmonitor more concise
 - fsmonitor: update helper tool, now that flags are filled later
 - fsmonitor: stop inline'ing mark_fsmonitor_valid / _invalid
 - dir.c: update comments to match argument name

 Code clean-up on fsmonitor integration, plus optional utilization
 of the fsmonitor data in diff-files.

 Waiting for an update.
 cf. <alpine.DEB.2.21.1.1801042335130.32@MININT-6BKU6QN.europe.corp.microsoft.com>


* pb/bisect-helper-2 (2017-10-28) 8 commits
 - t6030: make various test to pass GETTEXT_POISON tests
 - bisect--helper: `bisect_start` shell function partially in C
 - bisect--helper: `get_terms` & `bisect_terms` shell function in C
 - bisect--helper: `bisect_next_check` shell function in C
 - bisect--helper: `check_and_set_terms` shell function in C
 - wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
 - bisect--helper: `bisect_write` shell function in C
 - bisect--helper: `bisect_reset` shell function in C

 Expecting a reroll.
 cf. <0102015f5e5ee171-f30f4868-886f-47a1-a4e4-b4936afc545d-000000@eu-west-1.amazonses.com>


* mk/http-backend-content-length (2017-11-27) 4 commits
 - SQUASH???
 - t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases
 - SQUASH???
 - http-backend: respect CONTENT_LENGTH as specified by rfc3875

 The http-backend (used for smart-http transport) used to slurp the
 whole input until EOF, without paying attention to CONTENT_LENGTH
 that is supplied in the environment and instead expecting the Web
 server to close the input stream.  This has been fixed.

 Expecting a reroll.
 Suggested fixes to be used when rerolling is queued, but I'd
 prefer _not_ squashing them myself.

 Also, it may be too complex solution for the problem.
 cf. <20171204171308.GA13332@sigill.intra.peff.net>


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

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

 Expecting a reroll.


* mk/use-size-t-in-zlib (2017-08-10) 1 commit
 . zlib.c: use size_t for size

 The wrapper to call into zlib followed our long tradition to use
 "unsigned long" for sizes of regions in memory, which have been
 updated to use "size_t".

 Needs resurrecting by making sure the fix is good and still applies
 (or adjusted to today's codebase).

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

* sb/blame-color (2018-04-17) 2 commits
 - builtin/blame: highlight recently changed lines
 - builtin/blame: dim uninteresting metadata lines

 "git blame" learns to unhighlight uninteresting metadata from the
 originating commit on lines that are the same as the previous one,
 and also paint lines in different colors depending on the age of
 the commit.

 The code to handle interaction between the config and command line
 option smelled fishy.  Reviews and discussions are welcomed (not
 just to this topic but others too ;-).


* ab/simplify-perl-makefile (2018-04-11) 1 commit
  (merged to 'next' on 2018-04-17 at 4448756934)
 + perl: fix installing modules from contrib

 Recent simplification of build procedure forgot a bit of tweak to
 the build procedure of contrib/mw-to-git/

 Will merge to 'master'.


* ak/bisect-doc-typofix (2018-04-07) 1 commit
  (merged to 'next' on 2018-04-17 at eafdeb0248)
 + Documentation/git-bisect.txt: git bisect term → git bisect terms

 Docfix.

 Will merge to 'master'.


* bw/commit-partial-from-subdirectory-fix (2018-04-05) 1 commit
  (merged to 'next' on 2018-04-17 at 1e56bbc14d)
 + commit: allow partial commits with relative paths

 "cd sub/dir && git commit ../path" ought to record the changes to
 the file "sub/path", but this regressed long time ago.

 Will merge to 'master'.


* ds/lazy-load-trees (2018-04-11) 5 commits
 - commit-graph: lazy-load trees for commits
 - treewide: replace maybe_tree with accessor methods
 - commit: create get_commit_tree() method
 - treewide: rename tree to maybe_tree
 - Merge branch 'bw/c-plus-plus' into ds/lazy-load-trees
 (this branch uses ds/commit-graph; is tangled with ds/generation-numbers.)

 The code has been taught to use the duplicated information stored
 in the commit-graph file to learn the tree object name for a commit
 to avoid opening and parsing the commit object when it makes sense
 to do so.

 Will merge to 'next'.


* jk/t5561-missing-curl (2018-04-05) 2 commits
  (merged to 'next' on 2018-04-17 at d8592fa6c2)
 + t5561: skip tests if curl is not available
 + t5561: drop curl stderr redirects

 Test fixes.

 Will merge to 'master'.


* ks/branch-list-detached-rebase-i (2018-04-05) 2 commits
  (merged to 'next' on 2018-04-17 at 5c2842c3f9)
 + t3200: verify "branch --list" sanity when rebasing from detached HEAD
 + branch --list: print useful info whilst interactive rebasing a detached HEAD

 "git branch --list" during an interrupted "rebase -i" now lets
 users distinguish the case where a detached HEAD is being rebased
 and a normal branch is being rebased.

 Will merge to 'master'.


* lw/daemon-log-destination (2018-04-09) 1 commit
  (merged to 'next' on 2018-04-17 at b06cdcc45e)
 + daemon.c: fix condition for redirecting stderr

 Recent introduction of "--log-destination" option to "git daemon"
 did not work well when the daemon was run under "--inetd" mode.

 Will merge to 'master'.


* mn/send-email-credential-doc (2018-04-08) 1 commit
  (merged to 'next' on 2018-04-17 at c4db21eb9b)
 + send-email: simplify Gmail example in the documentation

 Doc update.

 Will merge to 'master'.


* nd/worktree-move (2018-04-05) 1 commit
  (merged to 'next' on 2018-04-17 at 11ca393110)
 + t2028: tighten grep expression to make "move worktree" test more robust
 (this branch is used by es/worktree-docs.)

 Test update.

 Will merge to 'master'.


* ab/git-svn-get-record-typofix (2018-04-09) 1 commit
 - git-svn: avoid warning on undef readline()

 "git svn" had a minor thinko/typo which has been fixed.


* br/mergetools-guiffy (2018-04-06) 1 commit
  (merged to 'next' on 2018-04-17 at 8ec0697d5d)
 + mergetools: add support for guiffy

 "git mergetools" learned talking to guiffy.

 Will merge to 'master'.


* en/doc-typoes (2018-04-09) 2 commits
  (merged to 'next' on 2018-04-17 at 81e5c8da18)
 + Documentation: normalize spelling of 'normalised'
 + Documentation: fix several one-character-off spelling errors

 Docfix.

 Will merge to 'master'.


* hn/sort-ls-remote (2018-04-09) 1 commit
 - ls-remote: create '--sort' option
 (this branch uses jk/ref-array-push.)

 "git ls-remote" learned an option to allow sorting its output based
 on the refnames being shown.


* jk/ref-array-push (2018-04-09) 3 commits
  (merged to 'next' on 2018-04-17 at 61859b271b)
 + ref-filter: factor ref_array pushing into its own function
 + ref-filter: make ref_array_item allocation more consistent
 + ref-filter: use "struct object_id" consistently
 (this branch is used by hn/sort-ls-remote.)

 API clean-up aournd ref-filter code.

 Will merge to 'master'.


* js/empty-config-section-fix (2018-04-09) 15 commits
 - git_config_set: reuse empty sections
 - git config --unset: remove empty sections (in the common case)
 - git_config_set: make use of the config parser's event stream
 - git_config_set: do not use a state machine
 - config_set_store: rename some fields for consistency
 - config: avoid using the global variable `store`
 - config: introduce an optional event stream while parsing
 - t1300: `--unset-all` can leave an empty section behind (bug)
 - t1300: add a few more hairy examples of sections becoming empty
 - t1300: remove unreasonable expectation from TODO
 - t1300: avoid relying on a bug
 - config --replace-all: avoid extra line breaks
 - t1300: demonstrate that --replace-all can "invent" newlines
 - t1300: rename it to reflect that `repo-config` was deprecated
 - git_config_set: fix off-by-two

 "git config --unset a.b", when "a.b" is the last variable in an
 otherwise empty section "a", left an empty section "a" behind, and
 worse yet, a subsequent "git config a.c value" did not reuse that
 empty shell and instead created a new one.  These have been
 (partially) corrected.

 Will merge to 'next'.


* js/t5404-path-fix (2018-04-09) 1 commit
  (merged to 'next' on 2018-04-17 at 94092f2896)
 + t5404: relax overzealous test

 Test fix.

 Will merge to 'master'.


* ps/test-chmtime-get (2018-04-09) 1 commit
  (merged to 'next' on 2018-04-17 at dcb138d8b1)
 + t/helper: 'test-chmtime (--get|-g)' to print only the mtime

 Test cleanup.

 Will merge to 'master'.


* es/fread-reads-dir-autoconf-fix (2018-04-09) 1 commit
  (merged to 'next' on 2018-04-17 at 538601fef3)
 + configure.ac: fix botched FREAD_READS_DIRECTORIES check

 Small fix to the autoconf build procedure.

 Will merge to 'master'.


* es/worktree-docs (2018-04-09) 2 commits
  (merged to 'next' on 2018-04-17 at 15a098e9b1)
 + git-worktree.txt: unify command-line prompt in example blocks
 + git-worktree.txt: recommend 'git worktree remove' over manual deletion
 (this branch uses nd/worktree-move.)

 Doc updates.

 Will merge to 'master'.


* nd/warn-more-for-devs (2018-04-16) 4 commits
 - Makefile: add a DEVOPTS to get all of -Wextra
 - Makefile: add a DEVOPTS to suppress -Werror under DEVELOPER
 - Makefile: detect compiler and enable more warnings in DEVELOPER=1
 - connect.c: mark die_initial_contact() NORETURN

 The build procedure "make DEVELOPER=YesPlease" learned to enable a
 bit more warning options depending on the compiler used to help
 developers more.  There also is "make DEVOPTS=tokens" knob
 available now, for those who want to help fixing warnings we
 usually ignore, for example.

 Will merge to 'next'.


* sb/submodule-move-nested (2018-03-29) 6 commits
 - submodule: fixup nested submodules after moving the submodule
 - submodule-config: remove submodule_from_cache
 - submodule-config: add repository argument to submodule_from_{name, path}
 - submodule-config: allow submodule_free to handle arbitrary repositories
 - grep: remove "repo" arg from non-supporting funcs
 - submodule.h: drop declaration of connect_work_tree_and_git_dir

 Moving a submodule that itself has submodule in it with "git mv"
 forgot to make necessary adjustment to the nested sub-submodules;
 now the codepath learned to recurse into the submodules.

 What's the doneness of this thing?


* tb/config-type (2018-04-10) 2 commits
 - builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
 - builtin/config.c: treat type specifiers singularly
 (this branch is used by tb/config-default.)

 The "git config" command uses separate options e.g. "--int",
 "--bool", etc. to specify what type the caller wants the value to
 be interpreted as.  A new "--type=<typename>" option has been
 introduced, which would make it cleaner to define new types.

 Expecting a final reroll.
 cf. <20180411034941.GA63158@syl.local>
 This looked more or less ready, IIRC


* tb/config-default (2018-04-10) 3 commits
 - builtin/config: introduce `color` type specifier
 - config.c: introduce 'git_config_color' to parse ANSI colors
 - builtin/config: introduce `--default`
 (this branch uses tb/config-type.)

 "git config --get" learned the "--default" option, to help the
 calling script.  Building on top of the tb/config-type topic, the
 "git config" learns "--type=color" type.  Taken together, you can
 do things like "git config --get foo.color --default blue" and get
 the ANSI color sequence for the color given to foo.color variable,
 or "blue" if the variable does not exist.

 Will wait on the tb/config-type topic.


* jk/flockfile-stdio (2018-03-30) 1 commit
  (merged to 'next' on 2018-04-17 at e11bd565f4)
 + config: move flockfile() closer to unlocked functions

 Code clean-up.

 Will merge to 'master'.


* jk/relative-directory-fix (2018-03-30) 5 commits
  (merged to 'next' on 2018-04-17 at 1b8cc9dcb4)
 + refs: use chdir_notify to update cached relative paths
 + set_work_tree: use chdir_notify
 + add chdir-notify API
 + trace.c: export trace_setup_key
 + set_git_dir: die when setenv() fails

 Some codepaths, including the refs API, get and keep relative
 paths, that go out of sync when the process does chdir(2).  The
 chdir-notify API is introduced to let these codepaths adjust these
 cached paths to the new current directory.

 Will merge to 'master'.


* jh/json-writer (2018-03-28) 1 commit
 - json_writer: new routines to create data in JSON format

 Preparatory code to later add json output for unspecified telemetry
 data.

 We do not add random code that does not have real users to our
 codebase, so let's have it wait until such a real code materializes
 before too long.


* ot/libify-get-ref-atom-value (2018-03-29) 6 commits
 - ref-filter: libify get_ref_atom_value()
 - ref-filter: add return value to parsers
 - ref-filter: change parsing function error handling
 - ref-filter: add return value && strbuf to handlers
 - ref-filter: start adding strbufs with errors
 - ref-filter: add shortcut to work with strbufs

 Code restructuring, in preparation for further work.

 Will merge to 'next'.


* jk/branch-l-0-deprecation (2018-03-26) 3 commits
  (merged to 'next' on 2018-04-11 at 9b2b0305dd)
 + branch: deprecate "-l" option
 + t: switch "branch -l" to "branch --create-reflog"
 + t3200: unset core.logallrefupdates when testing reflog creation
 (this branch is used by jk/branch-l-1-removal and jk/branch-l-2-reincarnation.)

 The "-l" option in "git branch -l" is an unfortunate short-hand for
 "--create-reflog", but many users, both old and new, somehow expect
 it to be something else, perhaps "--list".  This step deprecates
 the short-hand and warns about the future removal of the it when it
 is used.

 Will cook in 'next'.


* jk/branch-l-1-removal (2018-03-26) 1 commit
 - branch: drop deprecated "-l" option
 (this branch is used by jk/branch-l-2-reincarnation; uses jk/branch-l-0-deprecation.)

 Following the "git branch -l" deprecation, the short-hand is removed.

 Will keep in 'pu'.


* jk/branch-l-2-reincarnation (2018-03-26) 1 commit
 - branch: make "-l" a synonym for "--list"
 (this branch uses jk/branch-l-0-deprecation and jk/branch-l-1-removal.)

 Following the "git branch -l" removal, "-l" is resurrected as a
 short-hand for "--list".

 Will keep in 'pu'.


* jm/mem-pool (2018-04-12) 3 commits
  (merged to 'next' on 2018-04-17 at 8a3641ab3a)
 + mem-pool: move reusable parts of memory pool into its own file
 + fast-import: introduce mem_pool type
 + fast-import: rename mem_pool type to mp_block

 An reusable "memory pool" implementation has been extracted from
 fast-import.c, which in turn has become the first user of the
 mem-pool API.

 Will merge to 'master'.


* pw/rebase-keep-empty-fixes (2018-03-29) 3 commits
  (merged to 'next' on 2018-04-17 at 10a4d92060)
 + rebase: respect --no-keep-empty
 + rebase -i --keep-empty: don't prune empty commits
 + rebase --root: stop assuming squash_onto is unset
 (this branch is used by pw/rebase-signoff.)

 "git rebase --keep-empty" still removed an empty commit if the
 other side contained an empty commit (due to the "does an
 equivalent patch exist already?" check), which has been corrected.

 Will merge to 'master'.


* pw/rebase-signoff (2018-03-29) 4 commits
  (merged to 'next' on 2018-04-17 at fbdc16e20e)
 + rebase --keep-empty: always use interactive rebase
 + rebase -p: error out if --signoff is given
 + rebase: extend --signoff support
 + Merge branch 'pw/rebase-keep-empty-fixes' into pw/rebase-signoff
 (this branch uses pw/rebase-keep-empty-fixes.)

 "git rebase" has learned to honor "--signoff" option when using
 backends other than "am" (but not "--preserve-merges").

 Will merge to 'master'.


* dj/runtime-prefix (2018-04-11) 5 commits
  (merged to 'next' on 2018-04-17 at a69aaa7a22)
 + mingw/msvc: use the new-style RUNTIME_PREFIX helper
 + exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows
 + exec_cmd: RUNTIME_PREFIX on some POSIX systems
 + Makefile: add Perl runtime prefix support
 + Makefile: generate Perl header from template file

 A build-time option has been added to allow Git to be told to refer
 to its associated files relative to the main binary, in the same
 way that has been possible on Windows for quite some time, for
 Linux, BSDs and Darwin.

 Will merge to 'master'.


* ab/nuke-emacs-contrib (2018-04-16) 1 commit
 - git{,-blame}.el: remove old bitrotting Emacs code

 The scripts in contrib/emacs/ have outlived their usefulness and
 have been replaced with a stub that errors out and tells the user
 there are replacements.

 Will merge to 'next'.


* bb/git-gui-ssh-key-files (2018-03-02) 2 commits
  (merged to 'next' on 2018-04-17 at e439f0398d)
 + Merge branch 'bb/ssh-key-files' of git-gui into bb/git-gui-ssh-key-files
 + git-gui: search for all current SSH key types

 "git gui" learned that "~/.ssh/id_ecdsa.pub" and
 "~/.ssh/id_ed25519.pub" are also possible SSH key files.

 Will merge to 'master'.


* bp/git-gui-bind-kp-enter (2018-03-02) 2 commits
  (merged to 'next' on 2018-04-17 at 35828e90e2)
 + Merge branch 'bp/bind-kp-enter' of git-gui into bp/git-gui-bind-kp-enter
 + git-gui: bind CTRL/CMD+numpad ENTER to do_commit

 "git gui" performs commit upon CTRL/CMD+ENTER but the
 CTRL/CMD+KP_ENTER (i.e. enter key on the numpad) did not have the
 same key binding.  It now does.

 Will merge to 'master'.


* cb/git-gui-ttk-style (2018-03-05) 2 commits
  (merged to 'next' on 2018-04-17 at 1a4f677a0d)
 + Merge branch 'cb/ttk-style' of git-gui into cb/git-gui-ttk-style
 + git-gui: workaround ttk:style theme use

 "git gui" has been taught to work with old versions of tk (like
 8.5.7) that do not support "ttk::style theme use" as a way to query
 the current theme.

 Will merge to 'master'.


* nd/pack-objects-pack-struct (2018-04-16) 15 commits
 - ci: exercise the whole test suite with uncommon code in pack-objects
 - pack-objects: reorder members to shrink struct object_entry
 - pack-objects: shrink delta_size field in struct object_entry
 - pack-objects: shrink size field in struct object_entry
 - pack-objects: clarify the use of object_entry::size
 - pack-objects: don't check size when the object is bad
 - pack-objects: shrink z_delta_size field in struct object_entry
 - pack-objects: refer to delta objects by index instead of pointer
 - pack-objects: move in_pack out of struct object_entry
 - pack-objects: move in_pack_pos out of struct object_entry
 - pack-objects: use bitfield for object_entry::depth
 - pack-objects: use bitfield for object_entry::dfs_state
 - pack-objects: turn type and in_pack_type to bitfields
 - pack-objects: a bit of document about struct object_entry
 - read-cache.c: make $GIT_TEST_SPLIT_INDEX boolean

 "git pack-objects" needs to allocate tons of "struct object_entry"
 while doing its work, and shrinking its size helps the performance
 quite a bit.

 What's the doneness of this thing?  The interdiff since previous
 rounds looked reasonable, but I didn't see this round otherwise
 scrutinized by reviewers.  The numbers given in the commit near the
 tip do look impressive, though ;-)


* nd/repack-keep-pack (2018-04-16) 7 commits
 - pack-objects: show some progress when counting kept objects
 - gc --auto: exclude base pack if not enough mem to "repack -ad"
 - gc: handle a corner case in gc.bigPackThreshold
 - gc: add gc.bigPackThreshold config
 - gc: add --keep-largest-pack option
 - repack: add --keep-pack option
 - t7700: have closing quote of a test at the beginning of line

 "git gc" in a large repository takes a lot of time as it considers
 to repack all objects into one pack by default.  The command has
 been taught to pretend as if the largest existing packfile is
 marked with ".keep" so that it is left untouched while objects in
 other packs and loose ones are repacked.

 What's the doneness of this thing?  The interdiff since the earlier
 one looked reasonable, but I didn't see this round otherwise
 scrutinized by reviewers.


* pw/add-p-select (2018-03-16) 3 commits
 - add -p: optimize line selection for short hunks
 - add -p: allow line selection to be inverted
 - add -p: select individual hunk lines

 "git add -p" interactive interface learned to let users choose
 individual added/removed lines to be used in the operation, instead
 of accepting or rejecting a whole hunk.

 Expecting a reroll to reignite the discussion.
 cf. <9895c7b7-eac4-28c1-90c6-443acd1131b7@talktalk.net>


* ds/commit-graph (2018-04-11) 16 commits
 - commit-graph: implement "--append" option
 - commit-graph: build graph from starting commits
 - commit-graph: read only from specific pack-indexes
 - commit: integrate commit graph with commit parsing
 - commit-graph: close under reachability
 - commit-graph: add core.commitGraph setting
 - commit-graph: implement git commit-graph read
 - commit-graph: implement git-commit-graph write
 - commit-graph: implement write_commit_graph()
 - commit-graph: create git-commit-graph builtin
 - graph: add commit graph design document
 - commit-graph: add format document
 - csum-file: refactor finalize_hashfile() method
 - csum-file: rename hashclose() to finalize_hashfile()
 - Merge branch 'jk/cached-commit-buffer' into HEAD
 - Merge branch 'jt/binsearch-with-fanout' into HEAD
 (this branch is used by ds/generation-numbers and ds/lazy-load-trees.)

 Precompute and store information necessary for ancestry traversal
 in a separate file to optimize graph walking.

 Will merge to 'next'.


* pc/submodule-helper-foreach (2018-02-02) 5 commits
 - submodule: port submodule subcommand 'foreach' from shell to C
 - submodule foreach: document variable '$displaypath'
 - submodule foreach: clarify the '$toplevel' variable documentation
 - submodule foreach: document '$sm_path' instead of '$path'
 - submodule foreach: correct '$path' in nested submodules from a subdirectory

 Expecting a response to review comments
 e.g. cf. <20180206150044.1bffbb573c088d38c8e44bf5@google.com>


* tg/worktree-add-existing-branch (2018-04-16) 4 commits
 - worktree: teach "add" to check out existing branches
 - worktree: factor out dwim_branch function
 - worktree: improve message when creating a new worktree
 - worktree: remove extra members from struct add_opts

 "git worktree add" learned to check out an existing branch.

 Will merge to 'next'.


* js/rebase-recreate-merge (2018-04-11) 15 commits
 - rebase -i --rebase-merges: add a section to the man page
 - rebase -i: introduce --rebase-merges=[no-]rebase-cousins
 - pull: accept --rebase=merges to recreate the branch topology
 - rebase --rebase-merges: avoid "empty merges"
 - sequencer: handle post-rewrite for merge commands
 - sequencer: make refs generated by the `label` command worktree-local
 - rebase --rebase-merges: add test for --keep-empty
 - rebase: introduce the --rebase-merges option
 - rebase-helper --make-script: introduce a flag to rebase merges
 - sequencer: fast-forward `merge` commands, if possible
 - sequencer: introduce the `merge` command
 - sequencer: introduce new commands to reset the revision
 - git-rebase--interactive: clarify arguments
 - sequencer: make rearrange_squash() a bit more obvious
 - sequencer: avoid using errno clobbered by rollback_lock_file()

 "git rebase" learned "--rebase-merges" to transplant the whole
 topology of commit graph elsewhere.

 This looked more or less ready for 'next'.  Please stop me if there
 are remaining issues I forgot about.


* bw/protocol-v2 (2018-03-15) 35 commits
  (merged to 'next' on 2018-04-11 at 23ee234a2c)
 + remote-curl: don't request v2 when pushing
 + remote-curl: implement stateless-connect command
 + http: eliminate "# service" line when using protocol v2
 + http: don't always add Git-Protocol header
 + http: allow providing extra headers for http requests
 + remote-curl: store the protocol version the server responded with
 + remote-curl: create copy of the service name
 + pkt-line: add packet_buf_write_len function
 + transport-helper: introduce stateless-connect
 + transport-helper: refactor process_connect_service
 + transport-helper: remove name parameter
 + connect: don't request v2 when pushing
 + connect: refactor git_connect to only get the protocol version once
 + fetch-pack: support shallow requests
 + fetch-pack: perform a fetch using v2
 + upload-pack: introduce fetch server command
 + push: pass ref prefixes when pushing
 + fetch: pass ref prefixes when fetching
 + ls-remote: pass ref prefixes when requesting a remote's refs
 + transport: convert transport_get_remote_refs to take a list of ref prefixes
 + transport: convert get_refs_list to take a list of ref prefixes
 + connect: request remote refs using v2
 + ls-refs: introduce ls-refs server command
 + serve: introduce git-serve
 + test-pkt-line: introduce a packet-line test helper
 + protocol: introduce enum protocol_version value protocol_v2
 + transport: store protocol version
 + connect: discover protocol version outside of get_remote_heads
 + connect: convert get_remote_heads to use struct packet_reader
 + transport: use get_refs_via_connect to get refs
 + upload-pack: factor out processing lines
 + upload-pack: convert to a builtin
 + pkt-line: add delim packet support
 + pkt-line: allow peeking a packet line without consuming it
 + pkt-line: introduce packet_read_with_status

 The beginning of the next-gen transfer protocol.

 Will cook in 'next'.


* ls/checkout-encoding (2018-04-16) 10 commits
 - convert: add round trip check based on 'core.checkRoundtripEncoding'
 - convert: add tracing for 'working-tree-encoding' attribute
 - convert: check for detectable errors in UTF encodings
 - convert: add 'working-tree-encoding' attribute
 - utf8: add function to detect a missing UTF-16/32 BOM
 - utf8: add function to detect prohibited UTF-16/32 BOM
 - utf8: teach same_encoding() alternative UTF encoding names
 - strbuf: add a case insensitive starts_with()
 - strbuf: add xstrdup_toupper()
 - strbuf: remove unnecessary NUL assignment in xstrdup_tolower()

 The new "checkout-encoding" attribute can ask Git to convert the
 contents to the specified encoding when checking out to the working
 tree (and the other way around when checking in).

 Will merge to 'next'.
 This looked more or less ready for 'next'.  Please stop me if there
 are remaining issues I forgot about.

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

* js/runtime-prefix-windows (2018-03-27) 5 commits
 . mingw/msvc: use the new-style RUNTIME_PREFIX helper
 . exec_cmd: provide a new-style RUNTIME_PREFIX helper for Windows
 . exec_cmd: RUNTIME_PREFIX on some POSIX systems
 . Makefile: add Perl runtime prefix support
 . Makefile: generate Perl header from template file

 The Windows port was the first that allowed Git to be installed
 anywhere by having its components refer to each other with relative
 pathnames.  The recent dj/runtime-prefix topic extends the idea to
 other platforms, and its approach has been adopted back in the
 Windows port.

 Ejected, as the parent topic dj/runtime-prefix covers Windows now.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Eric Sunshine]

On Tue, Apr 17, 2018 at 2:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * so/grossary-ancestor (2018-04-17) 1 commit
>  - glossary: substitute "ancestor" for "direct ancestor" in 'push' description.

s/grossary/glossary/

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Stefan Beller]

Hi Junio,

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

> * sb/object-store-replace (2018-04-12) 15 commits
...
>  The effort to pass the repository in-core structure throughout the
>  API continues.  This round deals with the code that implements the
>  refs/replace/ mechanism.
>
>  What's the doneness of this thing?  I didn't recall seeing any
>  response, especially ones that demonstrated the reviewer carefully
>  read and thought about the issues surrounding the code.  Not that I
>  spotted any problems in these patches myself, though.

Stolee and Brandon provided a "quick LGTM" type of review
https://public-inbox.org/git/20180409232536.GB102627@google.com/
https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14067@gmail.com/

I do not recall an in depth review, though Rene had some design guidance
in form of a patch, which is also the first commit of the series
https://public-inbox.org/git/38962a15-1081-bbdb-b4c4-6b46222b5f64@web.de/

My plan was to build the next series on top this week while waiting for
further review, though I wonder how much review will happen this week.
(Brandon, Jonathan Tan and Jonathan Nieder are all OOO,
Peff is on vacation, too)

I do not recall any discussion worthy design discussions left over, so
I'd lean on "cook in next for a while".

>
> --------------------------------------------------
> [Cooking]
>
> * sb/blame-color (2018-04-17) 2 commits
>  - builtin/blame: highlight recently changed lines
>  - builtin/blame: dim uninteresting metadata lines
>
>  "git blame" learns to unhighlight uninteresting metadata from the
>  originating commit on lines that are the same as the previous one,
>  and also paint lines in different colors depending on the age of
>  the commit.
>
>  The code to handle interaction between the config and command line
>  option smelled fishy.  Reviews and discussions are welcomed (not
>  just to this topic but others too ;-).

I'll look at the replies in thread there.


> * sb/submodule-move-nested (2018-03-29) 6 commits
>  - submodule: fixup nested submodules after moving the submodule
>  - submodule-config: remove submodule_from_cache
>  - submodule-config: add repository argument to submodule_from_{name, path}
>  - submodule-config: allow submodule_free to handle arbitrary repositories
>  - grep: remove "repo" arg from non-supporting funcs
>  - submodule.h: drop declaration of connect_work_tree_and_git_dir
>
>  Moving a submodule that itself has submodule in it with "git mv"
>  forgot to make necessary adjustment to the nested sub-submodules;
>  now the codepath learned to recurse into the submodules.
>
>  What's the doneness of this thing?

I considered this done a long time ago,

    "All 6 patches look good to me, thanks.
     Reviewed-by: Jonathan Tan <jonathantanmy@google.com>"

https://public-inbox.org/git/20180328161727.af10f596dffc8e01205c41dd@google.com/


Thanks,
Stefan

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

>>  What's the doneness of this thing?  I didn't recall seeing any
>>  response, especially ones that demonstrated the reviewer carefully
>>  read and thought about the issues surrounding the code.  Not that I
>>  spotted any problems in these patches myself, though.
>
> Stolee and Brandon provided a "quick LGTM" type of review
> https://public-inbox.org/git/20180409232536.GB102627@google.com/
> https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14067@gmail.com/

Yup.  Giving positive reviews is harder than giving constructive
criticism.  Much harder.  

As readers cannot tell from a "quick LGTM" between "I didn't read it
but it did not smell foul" and "I read it thoroughly, understood how
the solution works, it was presented well, and agree with the design
and implementation---there is nothing to add", the reviewers need to
come up with some way to express that it is the latter case rather
than the former.

I would not claim that I've perfected my technique to do so, but
when responding to such a "good" series, I rephrase the main idea in
the series in my own words to show that I as a reviewer read the
series well enough to be able to do so, perhaps with comparison with
possible alternatives I could think of and dicussion to argue that
the solution presented in the series is better, in an attempt to
demonstrate that I am qualified to say "this one is good" with good
enough understanding of both the issue the series addresses and the
solution in the series.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Derrick Stolee]

On 4/17/2018 9:04 PM, Junio C Hamano wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>>>   What's the doneness of this thing?  I didn't recall seeing any
>>>   response, especially ones that demonstrated the reviewer carefully
>>>   read and thought about the issues surrounding the code.  Not that I
>>>   spotted any problems in these patches myself, though.
>> Stolee and Brandon provided a "quick LGTM" type of review
>> https://public-inbox.org/git/20180409232536.GB102627@google.com/
>> https://public-inbox.org/git/9ddfee7e-025a-79c9-8d6b-700c65a14067@gmail.com/
> Yup.  Giving positive reviews is harder than giving constructive
> criticism.  Much harder.
>
> As readers cannot tell from a "quick LGTM" between "I didn't read it
> but it did not smell foul" and "I read it thoroughly, understood how
> the solution works, it was presented well, and agree with the design
> and implementation---there is nothing to add", the reviewers need to
> come up with some way to express that it is the latter case rather
> than the former.
>
> I would not claim that I've perfected my technique to do so, but
> when responding to such a "good" series, I rephrase the main idea in
> the series in my own words to show that I as a reviewer read the
> series well enough to be able to do so, perhaps with comparison with
> possible alternatives I could think of and dicussion to argue that
> the solution presented in the series is better, in an attempt to
> demonstrate that I am qualified to say "this one is good" with good
> enough understanding of both the issue the series addresses and the
> solution in the series.

I'm sorry that my second message was terse. My response to v1 [1] was

 > I looked through these patches and only found one set of whitespace > 
errors. Compiles and tests fine on my machine. > > Reviewed-by: Derrick 
Stolee <dstolee@microsoft.com> So, I pulled the code, went through it 
patch-by-patch, and saw that the transformations were made using the 
established pattern. The second review was to chime in that my v1 
comments had been addressed. Thanks, -Stolee
[1] 
https://public-inbox.org/git/6c319100-df47-3b8d-8661-24e4643ada09@gmail.com/

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Jonathan Tan]

On Tue, Apr 17, 2018 at 11:05 AM, Stefan Beller <sbeller@google.com> wrote:
>> * sb/submodule-move-nested (2018-03-29) 6 commits
>>  - submodule: fixup nested submodules after moving the submodule
>>  - submodule-config: remove submodule_from_cache
>>  - submodule-config: add repository argument to submodule_from_{name, path}
>>  - submodule-config: allow submodule_free to handle arbitrary repositories
>>  - grep: remove "repo" arg from non-supporting funcs
>>  - submodule.h: drop declaration of connect_work_tree_and_git_dir
>>
>>  Moving a submodule that itself has submodule in it with "git mv"
>>  forgot to make necessary adjustment to the nested sub-submodules;
>>  now the codepath learned to recurse into the submodules.
>>
>>  What's the doneness of this thing?
>
> I considered this done a long time ago,
>
>     "All 6 patches look good to me, thanks.
>      Reviewed-by: Jonathan Tan <jonathantanmy@google.com>"
>
> https://public-inbox.org/git/20180328161727.af10f596dffc8e01205c41dd@google.com/

To add to this, I sent this in reply to version 3 of this patch set,
after Stefan addressed my comments. Most of my in-depth comments were
in reply to version 1 of this patch, which are the grandchild replies
to [1].

[1] https://public-inbox.org/git/20180327213918.77851-1-sbeller@google.com/

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Christian Hesse]

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

Junio C Hamano <gitster@pobox.com> on Tue, 2018/04/17 15:07:
> * ab/simplify-perl-makefile (2018-04-11) 1 commit
>   (merged to 'next' on 2018-04-17 at 4448756934)
>  + perl: fix installing modules from contrib
> 
>  Recent simplification of build procedure forgot a bit of tweak to
>  the build procedure of contrib/mw-to-git/
> 
>  Will merge to 'master'.

Looks like cooking is v2 of the patch, while we were at v3, no?
-- 
Best regards,
Chris

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Elijah Newren]

On Mon, Apr 16, 2018 at 11:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * en/rename-directory-detection-reboot (2018-04-16) 32 commits
>  - merge-recursive: fix check for skipability of working tree updates
>  - merge-recursive: Fix was_tracked() to quit lying with some renamed paths
>  - t6046: testcases checking whether updates can be skipped in a merge
>  - merge-recursive: improve output precision around skipping updates
>  - merge-recursive: avoid spurious rename/rename conflict from dir renames
>  - directory rename detection: new testcases showcasing a pair of bugs
>  - merge-recursive: fix remaining directory rename + dirty overwrite cases
>  - merge-recursive: fix overwriting dirty files involved in renames
>  - merge-recursive: avoid clobbering untracked files with directory renames
>  - merge-recursive: apply necessary modifications for directory renames
>  - merge-recursive: when comparing files, don't include trees
>  - merge-recursive: check for file level conflicts then get new name
>  - merge-recursive: add computation of collisions due to dir rename & merging
>  - merge-recursive: check for directory level conflicts
>  - merge-recursive: add get_directory_renames()
>  - merge-recursive: make a helper function for cleanup for handle_renames
>  - merge-recursive: split out code for determining diff_filepairs
>  - merge-recursive: make !o->detect_rename codepath more obvious
>  - merge-recursive: fix leaks of allocated renames and diff_filepairs
>  - merge-recursive: introduce new functions to handle rename logic
>  - merge-recursive: move the get_renames() function
>  - directory rename detection: tests for handling overwriting dirty files
>  - directory rename detection: tests for handling overwriting untracked files
>  - directory rename detection: miscellaneous testcases to complete coverage
>  - directory rename detection: testcases exploring possibly suboptimal merges
>  - directory rename detection: more involved edge/corner testcases
>  - directory rename detection: testcases checking which side did the rename
>  - directory rename detection: files/directories in the way of some renames
>  - directory rename detection: partially renamed directory testcase/discussion
>  - directory rename detection: testcases to avoid taking detection too far
>  - directory rename detection: directory splitting testcases
>  - directory rename detection: basic testcases
>
>  Reboot of an attempt to detect wholesale directory renames and use
>  it while merging.


Thanks for rebasing/cherry-picking the series and applying my newest
changes.  It looks like a couple of your squashed fixes in the rebase
of the old commits (designed to deal with compilation errors from the
tree entry functions having been converted to object_id) went into the
wrong commits, breaking bisectability.  When I send out my next round,
I'll only replace the top four commits, but I'll add in a few commits
that can be squashed to fix the bisectability.

Also, the newest patches can still be fooled by a specially crafted
rename/add conflict, but I believe with a small restructure I can both
simplify the code and cover all the cases.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

Derrick Stolee <stolee@gmail.com> writes:

> I'm sorry that my second message was terse. My response to v1 [1] was
>
>> I looked through these patches and only found one set of whitespace
>> > 
> errors. Compiles and tests fine on my machine. > > Reviewed-by:
> Derrick Stolee <dstolee@microsoft.com> So, I pulled the code, went
> through it patch-by-patch, and saw that the transformations were made
> using the established pattern. The second review was to chime in that
> my v1 comments had been addressed. Thanks, -Stolee
> [1]
> https://public-inbox.org/git/6c319100-df47-3b8d-8661-24e4643ada09@gmail.com/

Thanks.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

Jonathan Tan <jonathantanmy@google.com> writes:

>> I considered this done a long time ago,
>>
>>     "All 6 patches look good to me, thanks.
>>      Reviewed-by: Jonathan Tan <jonathantanmy@google.com>"
>>
>> https://public-inbox.org/git/20180328161727.af10f596dffc8e01205c41dd@google.com/
>
> To add to this, I sent this in reply to version 3 of this patch set,
> after Stefan addressed my comments. Most of my in-depth comments were
> in reply to version 1 of this patch, which are the grandchild replies
> to [1].
>
> [1] https://public-inbox.org/git/20180327213918.77851-1-sbeller@google.com/

Thanks for helping out.  Very much appreciated.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

Christian Hesse <mail@eworm.de> writes:

> Junio C Hamano <gitster@pobox.com> on Tue, 2018/04/17 15:07:
>> * ab/simplify-perl-makefile (2018-04-11) 1 commit
>>   (merged to 'next' on 2018-04-17 at 4448756934)
>>  + perl: fix installing modules from contrib
>> 
>>  Recent simplification of build procedure forgot a bit of tweak to
>>  the build procedure of contrib/mw-to-git/
>> 
>>  Will merge to 'master'.
>
> Looks like cooking is v2 of the patch, while we were at v3, no?

If that is the case, unless v3 was obviously crappy and was
discarded, which sounds unlikely, it is more plausible that
I must have missed v3 altogether, isn't it?

I'll stop merging this down while I hunt for that v3 version.  As
the above is already in 'next', we may have to ask the v3 patch to
be rewritten to be an incremental update to it, though.

Thanks for reminding me.  Very much appreciated.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

> On Mon, Apr 16, 2018 at 11:07 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> * en/rename-directory-detection-reboot (2018-04-16) 32 commits
>>  ...
>>  - directory rename detection: testcases to avoid taking detection too far
>>  - directory rename detection: directory splitting testcases
>>  - directory rename detection: basic testcases
>>
>>  Reboot of an attempt to detect wholesale directory renames and use
>>  it while merging.
>
>
> Thanks for rebasing/cherry-picking the series and applying my newest
> changes.  It looks like a couple of your squashed fixes in the rebase
> of the old commits ...

Thanks for rebooting the effort.  The above wasn't a serious attempt
to re-queue the series to be polished for 'next'---to me, this
branch was primarily to keep track of your interim 29+fractional
patches until "the real thing", possibly rebased to newer codebase,
gets submitted.

> Also, the newest patches can still be fooled by a specially crafted
> rename/add conflict, but I believe with a small restructure I can both
> simplify the code and cover all the cases.

That's nice.  Very much looking forward to the updates.

Thanks.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

[...]

>
> * js/rebase-recreate-merge (2018-04-11) 15 commits
[...]
>  "git rebase" learned "--rebase-merges" to transplant the whole
>  topology of commit graph elsewhere.
>
>  This looked more or less ready for 'next'.  Please stop me if there
>  are remaining issues I forgot about.

It seems this is currently in inconsistent state. Despite the new name
of the option, it still doesn't rebase merges. It rather recreates them
from scratch, and Johannes is hopefully still working on implementation
of proper rebasing.

In addition, for what it's worth, I'm cooking a review of the problems
of the suggested UI. I believe the UI of this new feature is seriously
mis- and/or under- developed and is not suitable as is for the core Git.

-- Sergey

js/rebase-recreate-merges, was Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Johannes Schindelin]

Hi Junio,

On Tue, 17 Apr 2018, Junio C Hamano wrote:

> * js/rebase-recreate-merge (2018-04-11) 15 commits
>  - rebase -i --rebase-merges: add a section to the man page
>  - rebase -i: introduce --rebase-merges=[no-]rebase-cousins
>  - pull: accept --rebase=merges to recreate the branch topology
>  - rebase --rebase-merges: avoid "empty merges"
>  - sequencer: handle post-rewrite for merge commands
>  - sequencer: make refs generated by the `label` command worktree-local
>  - rebase --rebase-merges: add test for --keep-empty
>  - rebase: introduce the --rebase-merges option
>  - rebase-helper --make-script: introduce a flag to rebase merges
>  - sequencer: fast-forward `merge` commands, if possible
>  - sequencer: introduce the `merge` command
>  - sequencer: introduce new commands to reset the revision
>  - git-rebase--interactive: clarify arguments
>  - sequencer: make rearrange_squash() a bit more obvious
>  - sequencer: avoid using errno clobbered by rollback_lock_file()
> 
>  "git rebase" learned "--rebase-merges" to transplant the whole
>  topology of commit graph elsewhere.
> 
>  This looked more or less ready for 'next'.  Please stop me if there
>  are remaining issues I forgot about.

Phillip pointed out some ugliness in the way I reschedule commands after
they failed fatally, and I will fix that, I will also fix the erroneous
commit message starting with "# This is a combination of ...", and then I
wanted to go over the added documentation one last time (with a fresh set
of eyes, after looking at so much other code).

So: please do not yet merge this to `next`. I think I need one more
iteration.

Ciao,
Dscho

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Taylor Blau]

On Tue, Apr 17, 2018 at 03:07:46PM +0900, Junio C Hamano wrote:
> * tb/config-type (2018-04-10) 2 commits
>  - builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`
>  - builtin/config.c: treat type specifiers singularly
>  (this branch is used by tb/config-default.)
>
>  The "git config" command uses separate options e.g. "--int",
>  "--bool", etc. to specify what type the caller wants the value to
>  be interpreted as.  A new "--type=<typename>" option has been
>  introduced, which would make it cleaner to define new types.
>
>  Expecting a final reroll.
>  cf. <20180411034941.GA63158@syl.local>
>  This looked more or less ready, IIRC
>
>
> * tb/config-default (2018-04-10) 3 commits
>  - builtin/config: introduce `color` type specifier
>  - config.c: introduce 'git_config_color' to parse ANSI colors
>  - builtin/config: introduce `--default`
>  (this branch uses tb/config-type.)
>
>  "git config --get" learned the "--default" option, to help the
>  calling script.  Building on top of the tb/config-type topic, the
>  "git config" learns "--type=color" type.  Taken together, you can
>  do things like "git config --get foo.color --default blue" and get
>  the ANSI color sequence for the color given to foo.color variable,
>  or "blue" if the variable does not exist.
>
>  Will wait on the tb/config-type topic.

Hi Junio,

Thank you for picking up both of these topics. I sent a final reroll to
tb/config-type, which I see has made it successfully to 'pu'.

I noticed that tb/config-default, however, only landed two commits:

  - builtin/config: introduce `color` type specifier
  - config.c: introduce 'git_config_color' to parse ANSI colors

but not:

  - builtin/config: introduce `--default`

As such, I am able to build on 'pu', but the `--default` option is
missing:

  ~/g/git (pu) $ ./git-config --type=color --default red core.doesntexist
  error: unknown option `default'

Please advise.


Thanks,
Taylor

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> I noticed that tb/config-default, however, only landed two commits:
>
>   - builtin/config: introduce `color` type specifier
>   - config.c: introduce 'git_config_color' to parse ANSI colors
>
> but not:
>
>   - builtin/config: introduce `--default`

Whenever something like this happens, especially the patch was
original sent more than several days ago, it is helpful to give the
message-id of what you are referring to to identify and retrieve it.
More often than not, it wasn't explicitly rejected but was simply
dropped, either by mistake or got delayed in delivery and got
forgotten.

Also for a pair of small series like these, when rerolling the
preparatory series for the final round, it is helpful to also send
the other series that depends on the preparatory one at the same
time, even if the latter hasn't changed since the last time.

Thanks.

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Taylor Blau]

On Mon, Apr 23, 2018 at 08:33:11AM +0900, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > I noticed that tb/config-default, however, only landed two commits:
> >
> >   - builtin/config: introduce `color` type specifier
> >   - config.c: introduce 'git_config_color' to parse ANSI colors
> >
> > but not:
> >
> >   - builtin/config: introduce `--default`
>
> Whenever something like this happens, especially the patch was
> original sent more than several days ago, it is helpful to give the
> message-id of what you are referring to to identify and retrieve it.
> More often than not, it wasn't explicitly rejected but was simply
> dropped, either by mistake or got delayed in delivery and got
> forgotten.
>
> Also for a pair of small series like these, when rerolling the
> preparatory series for the final round, it is helpful to also send
> the other series that depends on the preparatory one at the same
> time, even if the latter hasn't changed since the last time.
>
> Thanks.

Thanks, these are both helpful to know, and I will be sure to include
the relevant bits in the future.

For now, the Message-ID that I was referring to is:
20180410001826.GB67209@syl.local. [1]


Thanks,
Taylor

[1]: https://public-inbox.org/git/20180410001826.GB67209@syl.local/

Re: What's cooking in git.git (Apr 2018, #02; Tue, 17)

[Junio C Hamano]

Taylor Blau <me@ttaylorr.com> writes:

> For now, the Message-ID that I was referring to is:
> 20180410001826.GB67209@syl.local. [1]

Thanks.