What's cooking in git.git (Jun 2017, #06; Thu, 22)

What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Junio C Hamano]

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

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

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

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

* ah/filter-branch-setup (2017-06-12) 2 commits
  (merged to 'next' on 2017-06-19 at f3440f2c1a)
 + filter-branch: add [--] to usage
 + filter-branch: add `--setup` step

 "filter-branch" learned a pseudo filter "--setup" that can be used
 to define a common function/variable that can be used by other
 filters.


* km/test-mailinfo-b-failure (2017-06-12) 1 commit
  (merged to 'next' on 2017-06-19 at badc2c2337)
 + t5100: add some more mailinfo tests

 New tests.


* ls/github (2017-06-13) 1 commit
  (merged to 'next' on 2017-06-19 at 4d2024615f)
 + Configure Git contribution guidelines for github.com

 Help contributors that visit us at GitHub.


* mh/fast-import-raise-default-depth (2017-06-12) 1 commit
  (merged to 'next' on 2017-06-19 at 7093c07b8e)
 + fast-import: increase the default pack depth to 50

 "fast-import" uses a default pack chain depth that is consistent
 with other parts of the system.


* nd/fopen-errors (2017-06-15) 1 commit
  (merged to 'next' on 2017-06-15 at 86bcb7c082)
 + configure.ac: loosen FREAD_READS_DIRECTORIES test program

 Hotfix for a topic that is already in 'master'.


* pc/dir-count-slashes (2017-06-12) 1 commit
  (merged to 'next' on 2017-06-19 at 57351a2771)
 + dir: create function count_slashes()

 Three instances of the same helper function have been consolidated
 to one.


* ps/stash-push-pathspec-fix (2017-06-13) 1 commit
  (merged to 'next' on 2017-06-19 at 866c9035e0)
 + git-stash: fix pushing stash with pathspec from subdir

 "git stash push <pathspec>" did not work from a subdirectory at all.
 Bugfix for a topic in v2.13


* rs/strbuf-addftime-zZ (2017-06-15) 3 commits
  (merged to 'next' on 2017-06-19 at 77480669f0)
 + date: use localtime() for "-local" time formats
 + t0006: check --date=format zone offsets
 + strbuf: let strbuf_addftime handle %z and %Z itself

 As there is no portable way to pass timezone information to
 strftime, some output format from "git log" and friends are
 impossible to produce.  Teach our own strbuf_addftime to replace %z
 and %Z with caller-supplied values to help working around this.


* sb/t4005-modernize (2017-06-10) 1 commit
  (merged to 'next' on 2017-06-19 at beedeb757b)
 + t4005: modernize style and drop hard coded sha1

 Test clean-up.


* sd/t3200-branch-m-test (2017-06-13) 1 commit
  (merged to 'next' on 2017-06-19 at 0fd712c46e)
 + t3200: add test for single parameter passed to -m option

 New test.


* sg/revision-parser-skip-prefix (2017-06-12) 5 commits
  (merged to 'next' on 2017-06-19 at 0a90bec767)
 + revision.c: use skip_prefix() in handle_revision_pseudo_opt()
 + revision.c: use skip_prefix() in handle_revision_opt()
 + revision.c: stricter parsing of '--early-output'
 + revision.c: stricter parsing of '--no-{min,max}-parents'
 + revision.h: turn rev_info.early_output back into an unsigned int

 Code clean-up.

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

* mh/packed-ref-store-prep-extra (2017-06-18) 1 commit
 - prefix_ref_iterator_advance(): relax the check of trim length
 (this branch uses mh/packed-ref-store-prep; is tangled with mh/packed-ref-store.)

 Split out of mh/packed-ref-store-prep; will drop.


* ab/die-errors-in-threaded (2017-06-21) 1 commit
 - die(): stop hiding errors due to overzealous recursion guard

 Traditionally, the default die() routine had a code to prevent it
 from getting called multiple times, which interacted badly when a
 threaded program used it (one downside is that the real error may
 be hidden and instead the only error message given to the user may
 end up being "die recursion detected", which is not very useful).

 Will merge to 'next'.


* ab/pcre-v2 (2017-06-21) 1 commit
  (merged to 'next' on 2017-06-21 at fb6320213c)
 + grep: fix erroneously copy/pasted variable in check/assert pattern

 Hotfix for a topic already in 'master'.

 Will merge to 'master'.


* bw/repo-object (2017-06-22) 21 commits
 - ls-files: use repository object
 - repository: enable initialization of submodules
 - submodule: convert is_submodule_initialized to work on a repository
 - submodule: add repo_read_gitmodules
 - submodule-config: store the_submodule_cache in the_repository
 - repository: add index_state to struct repo
 - config: read config from a repository object
 - path: add repo_worktree_path and strbuf_repo_worktree_path
 - path: add repo_git_path and strbuf_repo_git_path
 - path: worktree_git_path() should not use file relocation
 - path: convert do_git_path to take a 'struct repository'
 - path: convert strbuf_git_common_path to take a 'struct repository'
 - path: always pass in commondir to update_common_dir
 - path: create path.h
 - environment: store worktree in the_repository
 - environment: place key repository state in the_repository
 - repository: introduce the repository object
 - environment: remove namespace_len variable
 - setup: add comment indicating a hack
 - setup: don't perform lazy initialization of repository state
 - Merge branches 'bw/ls-files-sans-the-index' and 'bw/config-h' into HEAD
 (this branch uses bw/config-h, bw/ls-files-sans-the-index and js/alias-early-config.)

 Introduce a "repository" object to eventually make it easier to
 work in multiple repositories (the primary focus is to work with
 the superproject and its submodules) in a single process.


* dt/raise-core-packed-git-limit (2017-06-21) 1 commit
  (merged to 'next' on 2017-06-22 at bc1a90f077)
 + docs: update 64-bit core.packedGitLimit default

 Doc update for a topic already in 'master'.

 Will merge to 'master'.


* jk/add-p-commentchar-fix (2017-06-21) 2 commits
  (merged to 'next' on 2017-06-22 at 5a1d464e6d)
 + add--interactive: quote commentChar regex
 + add--interactive: handle EOF in prompt_yesno

 "git add -p" were updated in 2.12 timeframe to cope with custom
 core.commentchar but the implementation was buggy and a
 metacharacter like $ and * did not work.

 Will merge to 'master'.


* ks/t7508-indent-fix (2017-06-21) 1 commit
  (merged to 'next' on 2017-06-22 at d12526967b)
 + t7508: fix a broken indentation

 Cosmetic update to a test.

 Will merge to 'master'.


* mb/reword-autocomplete-message (2017-06-21) 1 commit
  (merged to 'next' on 2017-06-22 at 878888a743)
 + auto-correct: tweak phrasing

 Message update.

 Will merge to 'master'.


* ks/submodule-add-doc (2017-06-22) 1 commit
 - Documentation/git-submodule: cleanup "add" section

 Doc update.

 Will merge to 'next'.


* pw/unquote-path-in-git-pm (2017-06-22) 5 commits
 - git-add--interactive.perl: Use unquote_path() from Git.pm
 - Add tests for Git::unquote_path()
 - Git::unquote_path() throw an exception on bad path
 - Git::unquote_path() Handle '\a'
 - Git.pm: add unquote_path()
 (this branch uses rs/sha1-name-readdir-optim.)

 Code refactoring.

 Expecting a reroll.
 The structure of the series has a bit to be desired, but the end
 result looked mostly OK.


* rs/sha1-name-readdir-optim (2017-06-22) 1 commit
 - sha1_name: cache readdir(3) results in find_short_object_filename()
 (this branch is used by pw/unquote-path-in-git-pm.)

 Optimize "what are the object names already taken in an alternate
 object database?" query that is used to derive the length of prefix
 an object name is uniquely abbreviated to.

 It would be nice to have some numbers, though.

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

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

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

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


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

 "git worktree" learned move and remove subcommands.

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

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

* ab/free-and-null (2017-06-16) 6 commits
  (merged to 'next' on 2017-06-21 at a1825fabd8)
 + *.[ch] refactoring: make use of the FREE_AND_NULL() macro
 + coccinelle: make use of the "expression" FREE_AND_NULL() rule
 + coccinelle: add a rule to make "expression" code use FREE_AND_NULL()
 + coccinelle: make use of the "type" FREE_AND_NULL() rule
 + coccinelle: add a rule to make "type" code use FREE_AND_NULL()
 + git-compat-util: add a FREE_AND_NULL() wrapper around free(ptr); ptr = NULL

 A common pattern to free a piece of memory and assign NULL to the
 pointer that used to point at it has been replaced with a new
 FREE_AND_NULL() macro.

 Will merge to 'master'.


* ab/wildmatch-glob-slash-test (2017-06-15) 1 commit
  (merged to 'next' on 2017-06-21 at 8f4a056f5f)
 + wildmatch test: cover a blind spot in "/" matching

 A new test to show the interaction between the pattern [^a-z]
 (which matches '/') and a slash in a path has been added.  The
 pattern should not match the slash with "pathmatch", but should
 with "wildmatch".

 Will merge to 'master'.


* ah/doc-gitattributes-empty-index (2017-06-15) 1 commit
  (merged to 'next' on 2017-06-21 at f1dc92557b)
 + doc: do not use `rm .git/index` when normalizing line endings

 An example in documentation that does not work in multi worktree
 configuration has been corrected.

 Will merge to 'master'.


* jk/diff-highlight-module (2017-06-15) 1 commit
  (merged to 'next' on 2017-06-21 at e418062ad2)
 + diff-highlight: split code into module

 The 'diff-highlight' program (in contrib/) has been restructured
 for easier reuse by an external project 'diff-so-fancy'.

 Will merge to 'master'.


* jt/unify-object-info (2017-06-21) 8 commits
 - sha1_file: refactor has_sha1_file_with_flags
 - sha1_file: do not access pack if unneeded
 - sha1_file: improve sha1_object_info_extended
 - sha1_file: refactor read_object
 - sha1_file: move delta base cache code up
 - sha1_file: rename LOOKUP_REPLACE_OBJECT
 - sha1_file: rename LOOKUP_UNKNOWN_OBJECT
 - sha1_file: teach packed_object_info about typename

 Code clean-ups.

 Looked sensible to me.  Any further comments?


* rs/pretty-add-again (2017-06-15) 1 commit
  (merged to 'next' on 2017-06-21 at 5128ad3632)
 + pretty: recalculate duplicate short hashes

 The pretty-format specifiers like '%h', '%t', etc. had an
 optimization that no longer works correctly.  In preparation/hope
 of getting it correctly implemented, first discard the optimization
 that is broken.

 Will merge to 'master'.


* sg/doc-pretty-formats (2017-06-15) 1 commit
  (merged to 'next' on 2017-06-21 at 011df65cf5)
 + docs/pretty-formats: stress that %- removes all preceding line-feeds

 Doc update.

 Will merge to 'master'.


* sn/reset-doc-typofix (2017-06-15) 1 commit
  (merged to 'next' on 2017-06-21 at 3e629ac2cb)
 + doc: git-reset: fix a trivial typo

 Doc update.

 Will merge to 'master'.


* da/mergetools-meld-output-opt-on-macos (2017-06-18) 1 commit
  (merged to 'next' on 2017-06-21 at de00cce3c0)
 + mergetools/meld: improve compatibiilty with Meld on macOS X

 "git mergetool" learned to work around a wrapper MacOS X adds
 around underlying meld.

 Will merge to 'master'.


* ks/status-initial-commit (2017-06-21) 1 commit
 - status: contextually notify user about an initial commit

 "git status" has long shown essentially the same message as "git
 commit"; the message it gives while preparing for the root commit,
 i.e. "Initial commit", was hard to understand for some new users.
 Now it says "No commits yet" to stress more on the current status
 (rather than the commit the user is preparing for, which is more in
 line with the focus of "git commit").

 Will merge to 'next'.


* lb/status-stash-count (2017-06-18) 3 commits
  (merged to 'next' on 2017-06-22 at 86bc2f2213)
 + glossary: define 'stash entry'
 + status: add optional stash count information
 + stash: update documentation to use 'stash entry'

 "git status" learned to optionally give how many stash entries the
 user has in its output.

 Will merge to 'master'.


* mh/packed-ref-store (2017-06-19) 29 commits
 - SQUASH???
 - read_packed_refs(): die if `packed-refs` contains bogus data
 - repack_without_refs(): don't lock or unlock the packed refs
 - commit_packed_refs(): remove call to `packed_refs_unlock()`
 - clear_packed_ref_cache(): don't protest if the lock is held
 - packed_refs_unlock(), packed_refs_is_locked(): new functions
 - packed_refs_lock(): report errors via a `struct strbuf *err`
 - packed_refs_lock(): function renamed from lock_packed_refs()
 - commit_packed_refs(): use a staging file separate from the lockfile
 - commit_packed_refs(): report errors rather than dying
 - packed_ref_store: make class into a subclass of `ref_store`
 - packed-backend: new module for handling packed references
 - packed_read_raw_ref(): new function, replacing `resolve_packed_ref()`
 - packed_ref_store: support iteration
 - packed_peel_ref(): new function, extracted from `files_peel_ref()`
 - repack_without_refs(): take a `packed_ref_store *` parameter
 - get_packed_ref(): take a `packed_ref_store *` parameter
 - rollback_packed_refs(): take a `packed_ref_store *` parameter
 - commit_packed_refs(): take a `packed_ref_store *` parameter
 - lock_packed_refs(): take a `packed_ref_store *` parameter
 - add_packed_ref(): take a `packed_ref_store *` parameter
 - get_packed_refs(): take a `packed_ref_store *` parameter
 - get_packed_ref_cache(): take a `packed_ref_store *` parameter
 - validate_packed_ref_cache(): take a `packed_ref_store *` parameter
 - clear_packed_ref_cache(): take a `packed_ref_store *` parameter
 - packed_ref_store: move `packed_refs_lock` member here
 - packed_ref_store: move `packed_refs_path` here
 - packed_ref_store: new struct
 - add_packed_ref(): teach function to overwrite existing refs
 (this branch uses mh/packed-ref-store-prep; is tangled with mh/packed-ref-store-prep-extra.)

 The "ref-store" code reorganization continues.

 Seems to break the promise that packed-refs are covered by loose
 refs and the former that points at a missing garbage is not an
 error.
 cf. <20170619195330.fhjlfiqmcwhgttaa@sigill.intra.peff.net>


* js/alias-early-config (2017-06-15) 6 commits
  (merged to 'next' on 2017-06-21 at ca4995aac2)
 + alias: use the early config machinery to expand aliases
 + t7006: demonstrate a problem with aliases in subdirectories
 + t1308: relax the test verifying that empty alias values are disallowed
 + help: use early config when autocorrecting aliases
 + config: report correct line number upon error
 + discover_git_directory(): avoid setting invalid git_dir
 (this branch is used by bw/config-h and bw/repo-object.)

 The code to pick up and execute command alias definition from the
 configuration used to switch to the top of the working tree and
 then come back when the expanded alias was executed, which was
 unnecessarilyl complex.  Attempt to simplify the logic by using the
 early-config mechanism that does not chdir around.

 Will merge to 'master'.


* bw/config-h (2017-06-15) 6 commits
  (merged to 'next' on 2017-06-21 at 15c5f34034)
 + config: don't implicitly use gitdir or commondir
 + config: respect commondir
 + setup: teach discover_git_directory to respect the commondir
 + config: don't include config.h by default
 + config: remove git_config_iter
 + config: create config.h
 (this branch is used by bw/repo-object; uses js/alias-early-config.)

 Fix configuration codepath to pay proper attention to commondir
 that is used in multi-worktree situation, and isolate config API
 into its own header file.

 Will merge to 'master'.


* bw/ls-files-sans-the-index (2017-06-13) 17 commits
  (merged to 'next' on 2017-06-21 at 39ce64f6c7)
 + ls-files: factor out tag calculation
 + ls-files: factor out debug info into a function
 + ls-files: convert show_files to take an index
 + ls-files: convert show_ce_entry to take an index
 + ls-files: convert prune_cache to take an index
 + ls-files: convert ce_excluded to take an index
 + ls-files: convert show_ru_info to take an index
 + ls-files: convert show_other_files to take an index
 + ls-files: convert show_killed_files to take an index
 + ls-files: convert write_eolinfo to take an index
 + ls-files: convert overlay_tree_on_cache to take an index
 + tree: convert read_tree to take an index parameter
 + convert: convert renormalize_buffer to take an index
 + convert: convert convert_to_git to take an index
 + convert: convert convert_to_git_filter_fd to take an index
 + convert: convert crlf_to_git to take an index
 + convert: convert get_cached_convert_stats_ascii to take an index
 (this branch is used by bw/repo-object.)

 Code clean-up.

 Will merge to 'master'.


* jk/warn-add-gitlink (2017-06-15) 2 commits
  (merged to 'next' on 2017-06-21 at 7210ddbb2e)
 + t: move "git add submodule" into test blocks
 + add: warn when adding an embedded repository

 Using "git add d/i/r" when d/i/r is the top of the working tree of
 a separate repository would create a gitlink in the index, which
 would appear as a not-quite-initialized submodule to others.  We
 learned to give warnings when this happens.

 Will merge to 'master'.


* mh/packed-ref-store-prep (2017-06-18) 2 commits
  (merged to 'next' on 2017-06-22 at 3f7a4da1e8)
 + for_each_bisect_ref(): don't trim refnames
 + lock_packed_refs(): fix cache validity check
 (this branch is used by mh/packed-ref-store and mh/packed-ref-store-prep-extra.)

 Bugfix for a topic that is (only) in 'master'.

 Will merge to 'master'.


* sb/submodule-doc (2017-06-22) 1 commit
 - submodules: overhaul documentation

 Doc update.

 Waiting for discussion to settle.


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

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

 Has a bit of interaction with two other topics, so perhaps needs to
 wait for them to stabilize a bit more.


* ls/filter-process-delayed (2017-06-01) 5 commits
 - convert: add "status=delayed" to filter process protocol
 - convert: move multiple file filter error handling to separate function
 - t0021: write "OUT" only on success
 - t0021: make debug log file name configurable
 - t0021: keep filter log files on comparison

 The filter-process interface learned to allow a process with long
 latency give a "delayed" response.

 Needs review.


* pw/rebase-i-regression-fix-tests (2017-06-19) 4 commits
  (merged to 'next' on 2017-06-22 at d1dde1672a)
 + rebase: add more regression tests for console output
 + rebase: add regression tests for console output
 + rebase -i: add test for reflog message
 + sequencer: print autostash messages to stderr

 Fix a recent regression to "git rebase -i" and add tests that would
 have caught it and others.

 Will merge to 'master'.


* ab/sha1dc (2017-06-07) 2 commits
 - sha1collisiondetection: automatically enable when submodule is populated
 - sha1dc: optionally use sha1collisiondetection as a submodule

 The "collission-detecting" implementation of SHA-1 hash we borrowed
 from is replaced by directly binding the upstream project as our
 submodule.

 Will keep in 'pu'.
 Impact to the various build and release infrastructure of using
 submodule is not yet fully known, but this lets us dip our toes.


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

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

 Waiting for discussion to settle.


* sb/diff-color-move (2017-06-21) 25 commits
 - diff: document the new --color-moved setting
 - diff.c: add dimming to moved line detection
 - diff.c: color moved lines differently, plain mode
 - diff.c: color moved lines differently
 - diff.c: buffer all output if asked to
 - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY
 - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP
 - diff.c: convert word diffing to use emit_diff_symbol
 - diff.c: convert show_stats to use emit_diff_symbol
 - diff.c: convert emit_binary_diff_body to use emit_diff_symbol
 - submodule.c: migrate diff output to use emit_diff_symbol
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF
 - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS{_PORCELAIN}
 - diff.c: migrate emit_line_checked to use emit_diff_symbol
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO
 - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER
 - diff.c: introduce emit_diff_symbol
 - diff.c: factor out diff_flush_patch_all_file_pairs
 - diff.c: move line ending check into emit_hunk_header
 - diff.c: readability fix

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

 Is any more update coming?


* xz/send-email-batch-size (2017-05-23) 1 commit
 - send-email: --batch-size to work around some SMTP server limit

 "git send-email" learned to overcome some SMTP server limitation
 that does not allow many pieces of e-mails to be sent over a single
 session.

 Waiting for response.
 cf. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@mail.gmail.com>


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

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

 Are we happy with these two?
 cf. <20170617112228.vugswym4o4owf6wj@sigill.intra.peff.net>


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

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

 Expecting a reroll.
 This is at its v5.
 cf. <cover.1497444257.git.johannes.schindelin@gmx.de>

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

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

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


* jc/pretty-add-again (2017-06-13) 1 commit
 . add_again() off-by-one error in custom format


* sk/dash-is-previous (2017-03-01) 5 commits
 . revert.c: delegate handling of "-" shorthand to setup_revisions
 . sha1_name.c: teach get_sha1_1 "-" shorthand for "@{-1}"
 . revision.c: args starting with "-" might be a revision
 . revision.c: swap if/else blocks
 . revision.c: do not update argv with unknown option

 A dash "-" can be written to mean "the branch that was previously
 checked out" in more places.

 Ejected, as it seems that making -.. to mean @{-1}..HEAD etc. are
 going too far.


* mg/name-rev-debug (2017-03-31) 2 commits
 . describe: pass --debug down to name-rev
 . name-rev: provide debug output

 "git describe --debug --contains" did not add any meaningful
 information, even though without "--contains" it did.

 Will discard for now.
 cf. <c85bc2a1-56d8-8a02-6089-2b8cb3d39e99@grubix.eu>

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Ævar Arnfjörð Bjarmason]

On Thu, Jun 22 2017, Junio C. Hamano jotted:

> * sd/branch-copy (2017-06-18) 3 commits
>  - branch: add a --copy (-c) option to go with --move (-m)
>  - branch: add test for -m renaming multiple config sections
>  - config: create a function to format section headers
>
>  "git branch" learned "-c/-C" to create and switch to a new branch
>  by copying an existing one.
>
>  Has a bit of interaction with two other topics, so perhaps needs to
>  wait for them to stabilize a bit more.

What topics are those? Didn't see any outright conflicts, but might have
missed something. Anything Sahil & I can help with?

> * ab/sha1dc (2017-06-07) 2 commits
>  - sha1collisiondetection: automatically enable when submodule is populated
>  - sha1dc: optionally use sha1collisiondetection as a submodule
>
>  The "collission-detecting" implementation of SHA-1 hash we borrowed
>  from is replaced by directly binding the upstream project as our
>  submodule.
>
>  Will keep in 'pu'.
>  Impact to the various build and release infrastructure of using
>  submodule is not yet fully known, but this lets us dip our toes.

I'm in no rush to get this in. I just submitted it initially as a
"submodules make sense here, and in git.git, yay!"

But it's been 1 month kicking around in pu now. What are we gaining from
keeping it there even longer at this point?

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

Been meaning to do my part to follow-up on this one, sorry about the
delay.

> * xz/send-email-batch-size (2017-05-23) 1 commit
>  - send-email: --batch-size to work around some SMTP server limit
>
>  "git send-email" learned to overcome some SMTP server limitation
>  that does not allow many pieces of e-mails to be sent over a single
>  session.
>
>  Waiting for response.
>  cf. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@mail.gmail.com>

I think between <7993e188.d18d.15c3560bcaf.Coremail.zxq_yx_007@163.com>
& <20170523103050.1f7ab7e0@jvn> we have sufficient info about what bug
this solves to try an alternate approach at some other time.

I think it makes sense to merge this down.

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Thu, Jun 22 2017, Junio C. Hamano jotted:
>
>> * sd/branch-copy (2017-06-18) 3 commits
>>  - branch: add a --copy (-c) option to go with --move (-m)
>>  - branch: add test for -m renaming multiple config sections
>>  - config: create a function to format section headers
>>
>>  "git branch" learned "-c/-C" to create and switch to a new branch
>>  by copying an existing one.
>>
>>  Has a bit of interaction with two other topics, so perhaps needs to
>>  wait for them to stabilize a bit more.
>
> What topics are those? Didn't see any outright conflicts, but might have
> missed something. Anything Sahil & I can help with?

Sorry, I write these and then forget the details because I have to
tend to many other topics all the time X-<.  Perhaps attempting the
merge to 'pu' yourself will tell you more?

>> * ab/sha1dc (2017-06-07) 2 commits
>> ...
>>  Will keep in 'pu'.
>>  Impact to the various build and release infrastructure of using
>>  submodule is not yet fully known, but this lets us dip our toes.
> ...
> But it's been 1 month kicking around in pu now. What are we gaining from
> keeping it there even longer at this point?

Keeping as many things outside 'next' means I have less things I
have to worry about ;-)

I am sort of waiting for a success from Windows box at Travis.  It
hasn't passed for other reasons for a while, though.

>> * xz/send-email-batch-size (2017-05-23) 1 commit
>>  - send-email: --batch-size to work around some SMTP server limit
>>
>>  "git send-email" learned to overcome some SMTP server limitation
>>  that does not allow many pieces of e-mails to be sent over a single
>>  session.
>>
>>  Waiting for response.
>>  cf. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@mail.gmail.com>
>
> I think between <7993e188.d18d.15c3560bcaf.Coremail.zxq_yx_007@163.com>
> & <20170523103050.1f7ab7e0@jvn> we have sufficient info about what bug
> this solves to try an alternate approach at some other time.

I thought your wish (which I found reasonable) was to record
whatever information that would help us in the future in the log
message?  I was waiting for that to happen.

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Lars Schneider]

> On 23 Jun 2017, at 00:35, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Here are the topics that have been cooking.  Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.  The ones marked with '.' do not appear in any of
> the integration branches, but I am still holding onto them.
> 
> 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
> 
> --------------------------------------------------
> 
...

> 
> * ls/filter-process-delayed (2017-06-01) 5 commits
> - convert: add "status=delayed" to filter process protocol
> - convert: move multiple file filter error handling to separate function
> - t0021: write "OUT" only on success
> - t0021: make debug log file name configurable
> - t0021: keep filter log files on comparison
> 
> The filter-process interface learned to allow a process with long
> latency give a "delayed" response.
> 
> Needs review.

I am still desperately looking for reviewers!
It would be awesome if this feature would have a chance 
to go into 2.14 :-)


> * pw/rebase-i-regression-fix-tests (2017-06-19) 4 commits
>  (merged to 'next' on 2017-06-22 at d1dde1672a)
> + rebase: add more regression tests for console output
> + rebase: add regression tests for console output
> + rebase -i: add test for reflog message
> + sequencer: print autostash messages to stderr
> 
> Fix a recent regression to "git rebase -i" and add tests that would
> have caught it and others.
> 
> Will merge to 'master'.

I think this series breaks t3420-rebase-autostash.sh 
with GETTEXT_POISON=YesPlease

See: https://travis-ci.org/git/git/jobs/245990993


- Lars

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Ævar Arnfjörð Bjarmason]

On Thu, Jun 22 2017, Junio C. Hamano jotted:

> * sb/diff-color-move (2017-06-21) 25 commits
>  - diff: document the new --color-moved setting
>  - diff.c: add dimming to moved line detection
>  - diff.c: color moved lines differently, plain mode
>  - diff.c: color moved lines differently
>  - diff.c: buffer all output if asked to
>  - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY
>  - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP
>  - diff.c: convert word diffing to use emit_diff_symbol
>  - diff.c: convert show_stats to use emit_diff_symbol
>  - diff.c: convert emit_binary_diff_body to use emit_diff_symbol
>  - submodule.c: migrate diff output to use emit_diff_symbol
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF
>  - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS{_PORCELAIN}
>  - diff.c: migrate emit_line_checked to use emit_diff_symbol
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO
>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER
>  - diff.c: introduce emit_diff_symbol
>  - diff.c: factor out diff_flush_patch_all_file_pairs
>  - diff.c: move line ending check into emit_hunk_header
>  - diff.c: readability fix
>
>  "git diff" has been taught to optionally paint new lines that are
>  the same as deleted lines elsewhere differently from genuinely new
>  lines.
>
>  Is any more update coming?

I guess here's as good a place for feedback is any, this feature's
great, but I discovered some minor warts in it:

This is good:

    $ ./git --exec-path=$PWD show --color-moved=crap
    fatal: bad --color-moved argument: crap

This is bad:

    $ ./git --exec-path=$PWD -c diff.colorMoved=crap show
    fatal: unable to parse 'diff.colormoved' from command-line config

Fixed with:

    diff --git a/diff.c b/diff.c
    index 7cae4f1ddb..036dbc1c3c 100644
    --- a/diff.c
    +++ b/diff.c
    @@ -278,7 +278,7 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
            if (!strcmp(var, "diff.colormoved")) {
                    int cm = parse_color_moved(value);
                    if (cm < 0)
    -                       return -1;
    +                       die("bad --color-moved argument: %s", value);
                    diff_color_moved_default = cm;
                    return 0;
            }

But I'm not familiar enough with the code to say if just dying here, as
opposed to returning -1 is OK or not.

Also, I think something like this (very lighty tested) patch on top
makes sense:

    diff --git a/diff.c b/diff.c
    index 7cae4f1ddb..d195d304d3 100644
    --- a/diff.c
    +++ b/diff.c
    @@ -257,6 +257,15 @@ int git_diff_heuristic_config(const char *var, const char *value, void *cb)

     static int parse_color_moved(const char *arg)
     {
    +       int v = git_parse_maybe_bool(arg);
    +
    +       if (v != -1) {
    +               if (v == 0)
    +                       return COLOR_MOVED_NO;
    +               else if (v == 1)
    +                       return COLOR_MOVED_PLAIN;
    +       }
    +
            if (!strcmp(arg, "no"))
                    return COLOR_MOVED_NO;
            else if (!strcmp(arg, "plain"))

I don't want to set this to a specific value, just "true" and it should
pick whatever the default is (and that in the config yields a very bad
error message, hence the first patch).

If you don't want to have a default for whatever reason I think the docs
need to change:

    diff --git a/Documentation/config.txt b/Documentation/config.txt
    index 1ab7bdfb49..4b6f8c6d5c 100644
    --- a/Documentation/config.txt
    +++ b/Documentation/config.txt
    @@ -1085,8 +1085,9 @@ This does not affect linkgit:git-format-patch[1] or the
     command line with the `--color[=<when>]` option.

     diff.colorMoved::
    -       If set moved lines in a diff are colored differently,
    -       for details see '--color-moved' in linkgit:git-diff[1].
    +       If set to a valid `<mode>` moved lines in a diff are colored
    +       differently, for details of valid modes see '--color-moved' in
    +       linkgit:git-diff[1].

     color.diff.<slot>::
            Use customized color for diff colorization.  `<slot>` specifies

Right now the lazy reader (i.e. me) just reads "if set...<blah blah>"
tries it out, and then gets a cryptic error. "If set" to me immediately
sounds like a bool variable (but then I read the diff docs and found
it's not). So with that bool parsing it could be changed to:

    diff --git a/Documentation/config.txt b/Documentation/config.txt
    index 1ab7bdfb49..e62d926740 100644
    --- a/Documentation/config.txt
    +++ b/Documentation/config.txt
    @@ -1085,8 +1085,10 @@ This does not affect linkgit:git-format-patch[1] or the
     command line with the `--color[=<when>]` option.

     diff.colorMoved::
    -       If set moved lines in a diff are colored differently,
    -       for details see '--color-moved' in linkgit:git-diff[1].
    +       If set to either a valid `<mode>` or a true value, moved lines
    +       in a diff are colored differently, for details of valid modes
    +       see '--color-moved' in linkgit:git-diff[1]. If simply set to
    +       true the default color mode will be used.

     color.diff.<slot>::
            Use customized color for diff colorization.  `<slot>` specifies

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Stefan Beller]

On Fri, Jun 23, 2017 at 2:59 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> On Thu, Jun 22 2017, Junio C. Hamano jotted:
>
>> * sb/diff-color-move (2017-06-21) 25 commits
>>  - diff: document the new --color-moved setting
>>  - diff.c: add dimming to moved line detection
>>  - diff.c: color moved lines differently, plain mode
>>  - diff.c: color moved lines differently
>>  - diff.c: buffer all output if asked to
>>  - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY
>>  - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP
>>  - diff.c: convert word diffing to use emit_diff_symbol
>>  - diff.c: convert show_stats to use emit_diff_symbol
>>  - diff.c: convert emit_binary_diff_body to use emit_diff_symbol
>>  - submodule.c: migrate diff output to use emit_diff_symbol
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF
>>  - diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS{_PORCELAIN}
>>  - diff.c: migrate emit_line_checked to use emit_diff_symbol
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO
>>  - diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER
>>  - diff.c: introduce emit_diff_symbol
>>  - diff.c: factor out diff_flush_patch_all_file_pairs
>>  - diff.c: move line ending check into emit_hunk_header
>>  - diff.c: readability fix
>>
>>  "git diff" has been taught to optionally paint new lines that are
>>  the same as deleted lines elsewhere differently from genuinely new
>>  lines.
>>
>>  Is any more update coming?
>
> I guess here's as good a place for feedback is any, this feature's
> great, but I discovered some minor warts in it:

Thanks for reporting these. :)

So:
* have the boolean option as below
* fix error modes in config
* rewrite documentation for lazy skimming readers :)

I also consider
* changing the default to zebra (instead of dimmed_zebra)

Junio wrote (when reviewing Michaels series)
> This patch shows OK, but when applied to other changes in the
> series, e.g. "packed_ref_store: make class into a subclass of
> `ref_store`", it was somewhat irritating that all new blank lines
> are shown as a copy-move of a single deleted blank line (also a
> single "return refs" in an entirely new function being a copy/move
> looked confusing).

* add some heuristic to omit small blobs, (empty lines, closing braces)
  Maybe this is can be solved by not considering anything
  that occurs multiple times?

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Stefan Beller]

> This is good:
>
>     $ ./git --exec-path=$PWD show --color-moved=crap
>     fatal: bad --color-moved argument: crap
>
> This is bad:
>
>     $ ./git --exec-path=$PWD -c diff.colorMoved=crap show
>     fatal: unable to parse 'diff.colormoved' from command-line config
>
> Fixed with:
>
>     diff --git a/diff.c b/diff.c
>     index 7cae4f1ddb..036dbc1c3c 100644
>     --- a/diff.c
>     +++ b/diff.c
>     @@ -278,7 +278,7 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
>             if (!strcmp(var, "diff.colormoved")) {
>                     int cm = parse_color_moved(value);
>                     if (cm < 0)
>     -                       return -1;
>     +                       die("bad --color-moved argument: %s", value);
>                     diff_color_moved_default = cm;
>                     return 0;
>             }
>
> But I'm not familiar enough with the code to say if just dying here, as
> opposed to returning -1 is OK or not.

I think this one is 'not good', as it (a) does not help the user a lot
and (b) is not consistent with the rest around in that function, for example

  $ git -c diff.interhunkcontext=-2 diff
  fatal: unable to parse 'diff.interhunkcontext' from command-line config

So instead of return -1, we could issue an additional warning, but this could
be a generic warning?

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Junio C Hamano]

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

>>> * ab/sha1dc (2017-06-07) 2 commits
>>> ...
>>>  Will keep in 'pu'.
>>>  Impact to the various build and release infrastructure of using
>>>  submodule is not yet fully known, but this lets us dip our toes.
>> ...
>> But it's been 1 month kicking around in pu now. What are we gaining from
>> keeping it there even longer at this point?
>
> I am sort of waiting for a success from Windows box at Travis.  It
> hasn't passed for other reasons for a while, though.

https://travis-ci.org/git/git/jobs/246371006#L480 shows that on
Linux, we are taking the code from the submodule and the compilation
is happy.

https://travis-ci.org/git/git/jobs/246371008#L25 shows that we do
init and update the submodule but it does not appear that neither
the bundled sha1dc/ nor the submodule gets used on MacOS.  Probably
we are using the hash from the platform?

https://travis-ci.org/git/git/jobs/246371011#L724 shows that the
bundled sha1dc/ is used on Windows, not from the submodule, for
whatever reason.  I trust what Dscho does for Windows platform well
enough that I do not feel unconfortable for not knowing why the
build there triggered by Travis does not use the submodule one.
Whatever configuration he chooses would be the best for the
platform.

So the only nit I may have is that we may possibly want to turn this
on in .travis.yml on MacOS before we move it forward (otherwise we'd
be shipping bundled one and submodule one without doing any build on
that platform)?  Other than that, the topic seems ready to be merged
down.

Thanks.

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> This is bad:
>
>     $ ./git --exec-path=$PWD -c diff.colorMoved=crap show
>     fatal: unable to parse 'diff.colormoved' from command-line config
>
> Fixed with:
>
>     diff --git a/diff.c b/diff.c
>     index 7cae4f1ddb..036dbc1c3c 100644
>     --- a/diff.c
>     +++ b/diff.c
>     @@ -278,7 +278,7 @@ int git_diff_ui_config(const char *var, const char *value, void *cb)
>             if (!strcmp(var, "diff.colormoved")) {
>                     int cm = parse_color_moved(value);
>                     if (cm < 0)
>     -                       return -1;
>     +                       die("bad --color-moved argument: %s", value);
>                     diff_color_moved_default = cm;
>                     return 0;
>             }

You would want to model this after an existing practice nearby.

    $ git -c color.diff.new=frotz diff
    error: error: invalid color value: frotz
    fatal: unable to parse 'color.diff.new' from command-line config

It could be argued that it would even be better to show "here is the
list of valid values the configuration takes", but generally we do
not do that in other configuration variables.

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> * add some heuristic to omit small blobs, (empty lines, closing braces)
>   Maybe this is can be solved by not considering anything
>   that occurs multiple times?

I vaguely recall that we had to do something similar in "blame -C"
where it tries to avoid passing blame for insignificant changes down
as copied.  But for the purpose of this "moved line coloring",
excluding multiple copy destinations of the same thing may be a
simpler and more robust solution.  It will not catch "somebody
stupidly removed one function and made two private copies", though.

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Junio C Hamano]

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

> But for the purpose of this "moved line coloring",
> excluding multiple copy destinations of the same thing may be a
> simpler and more robust solution.  It will not catch "somebody
> stupidly removed one function and made two private copies", though.

Let me take this one back.  Treating multiple copy destinations and
multiple copy sources differently is a bad idea.  It is easy for a
user to give "-R" option to "diff" to turn such a stupid patch into
"somebody brilliantly consolidated two copies of the same thing into
a single function", and we want to keep "diff" and "diff -R" output
symmetric.

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

[Stefan Beller]

On Fri, Jun 23, 2017 at 6:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> But for the purpose of this "moved line coloring",
>> excluding multiple copy destinations of the same thing may be a
>> simpler and more robust solution.  It will not catch "somebody
>> stupidly removed one function and made two private copies", though.
>
> Let me take this one back.  Treating multiple copy destinations and
> multiple copy sources differently is a bad idea.  It is easy for a
> user to give "-R" option to "diff" to turn such a stupid patch into
> "somebody brilliantly consolidated two copies of the same thing into
> a single function", and we want to keep "diff" and "diff -R" output
> symmetric.

Thanks for the pointer with "blame -C". I'll look through the archives
to see if there are good discussions that yield ideas for this.