git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* What's cooking in git.git (Jan 2018, #04; Wed, 31)
@ 2018-02-01  0:56 Junio C Hamano
  2018-02-01 11:05 ` Ævar Arnfjörð Bjarmason
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Junio C Hamano @ 2018-02-01  0:56 UTC (permalink / raw)
  To: git

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.

Many new topics appeared and are not yet marked with "Will do what"
labels.  Except for some large ones, I think most are already in
good shape, but I'd want to double check by re-reading them.

I am migrating my build and integration environment to a different
machine; if you notice anything out of ordinary, please let me know
before I decomission and reimage my usual environment ;-)

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]

* ab/fetch-prune (2018-01-24) 11 commits
 - fetch: add a --fetch-prune option and fetch.pruneTags config
 - fetch tests: add scaffolding for the new fetch.pruneTags
 - git-fetch & config doc: link to the new PRUNING section
 - git remote doc: correct dangerous lies about what prune does
 - git fetch doc: add a new section to explain the ins & outs of pruning
 - fetch tests: test --prune and refspec interaction
 - fetch tests: add a tag to be deleted to the pruning tests
 - fetch tests: re-arrange arguments for future readability
 - fetch tests: refactor in preparation for testing tag pruning
 - fetch: stop accessing "remote" variable indirectly
 - fetch: don't redundantly NULL something calloc() gave us

 Clarify how configured fetch refspecs interact with the "--prune"
 option of "git fetch", and also add a handy short-hand for getting
 rid of stale tags that are locally held.


* gs/retire-mru (2018-01-24) 1 commit
 - mru: Replace mru.[ch] with list.h implementation
 (this branch uses ot/mru-on-list.)

 Retire mru API as it does not give enough abstraction over
 underlying list API to be worth it.

 Will merge to 'next'.


* jc/mailinfo-cleanup-fix (2018-01-24) 1 commit
 - mailinfo: avoid segfault when can't open files

 Corner case bugfix.

 Will merge to 'next'.


* po/clang-format-functype-weight (2018-01-24) 1 commit
 - clang-format: adjust penalty for return type line break

 Prevent "clang-format" from breaking line after function return type.

 Will merge to 'next'.


* po/http-push-error-message (2018-01-24) 1 commit
 - http-push: improve error log

 Debugging aid.

 Will merge to 'next'.


* po/object-id (2018-01-30) 12 commits
 - sha1_file: rename hash_sha1_file_literally
 - sha1_file: convert write_loose_object to object_id
 - sha1_file: convert force_object_loose to object_id
 - sha1_file: convert write_sha1_file to object_id
 - notes: convert write_notes_tree to object_id
 - notes: convert combine_notes_* to object_id
 - commit: convert commit_tree* to object_id
 - match-trees: convert splice_tree to object_id
 - cache: clear whole hash buffer with oidclr
 - sha1_file: convert hash_sha1_file to object_id
 - dir: convert struct sha1_stat to use object_id
 - sha1_file: convert pretend_sha1_file to object_id

 Conversion from uchar[20] to struct object_id continues.


* sg/travis-linux32-sanity (2018-01-30) 5 commits
 - travis-ci: don't fail if user already exists on 32 bit Linux build job
 - travis-ci: don't run the test suite as root in the 32 bit Linux build
 - travis-ci: don't repeat the path of the cache directory
 - travis-ci: use 'set -e' in the 32 bit Linux build job
 - travis-ci: use 'set -x' for the commands under 'su' in the 32 bit Linux build

 Will merge to 'next'.


* jk/daemon-fixes (2018-01-25) 6 commits
 - daemon: fix length computation in newline stripping
 - t/lib-git-daemon: add network-protocol helpers
 - daemon: handle NULs in extended attribute string
 - daemon: fix off-by-one in logging extended attributes
 - t/lib-git-daemon: record daemon log
 - t5570: use ls-remote instead of clone for interp tests


* jt/long-running-process-doc (2018-01-25) 1 commit
 - Docs: split out long-running subprocess handshake


* nd/format-patch-stat-width (2018-01-25) 2 commits
 - format-patch: reduce patch diffstat width to 72
 - format-patch: keep cover-letter diffstat wrapped in 72 columns


* nd/list-merge-strategy (2018-01-26) 1 commit
 - completion: fix completing merge strategies on non-C locales


* sb/pull-rebase-submodule (2018-01-25) 1 commit
 - builtin/pull: respect verbosity settings in submodules


* sg/test-i18ngrep (2018-01-26) 10 commits
 - t: make 'test_i18ngrep' more informative on failure
 - t: make sure that 'test_i18ngrep' got enough parameters
 - t: forbid piping into 'test_i18ngrep'
 - t: move 'test_i18ncmp' and 'test_i18ngrep' to 'test-lib-functions.sh'
 - t5536: let 'test_i18ngrep' read the file without redirection
 - t5510: consolidate 'grep' and 'test_i18ngrep' patterns
 - t4001: don't run 'git status' upstream of a pipe
 - t6022: don't run 'git merge' upstream of a pipe
 - t5812: add 'test_i18ngrep's missing filename parameter
 - t5541: add 'test_i18ngrep's missing filename parameter


* bw/c-plus-plus (2018-01-30) 37 commits
 - replace: rename 'new' variables
 - trailer: rename 'template' variables
 - tempfile: rename 'template' variables
 - wrapper: rename 'template' variables
 - environment: rename 'namespace' variables
 - diff: rename 'template' variables
 - environment: rename 'template' variables
 - init-db: rename 'template' variables
 - unpack-trees: rename 'new' variables
 - trailer: rename 'new' variables
 - submodule: rename 'new' variables
 - split-index: rename 'new' variables
 - remote: rename 'new' variables
 - ref-filter: rename 'new' variables
 - read-cache: rename 'new' variables
 - line-log: rename 'new' variables
 - imap-send: rename 'new' variables
 - http: rename 'new' variables
 - entry: rename 'new' variables
 - diffcore-delta: rename 'new' variables
 - diff: rename 'new' variables
 - diff-lib: rename 'new' variable
 - commit: rename 'new' variables
 - combine-diff: rename 'new' variables
 - remote: rename 'new' variables
 - reflog: rename 'new' variables
 - pack-redundant: rename 'new' variables
 - help: rename 'new' variables
 - checkout: rename 'new' variables
 - apply: rename 'new' variables
 - apply: rename 'try' variables
 - diff: rename 'this' variables
 - rev-parse: rename 'this' variable
 - pack-objects: rename 'this' variables
 - blame: rename 'this' variables
 - object: rename function 'typename' to 'type_name'
 - object_info: change member name from 'typename' to 'type_name'


* ew/svn-branch-segfault-fix (2018-01-30) 1 commit
 - git-svn: control destruction order to avoid segfault

 Workaround for segfault with more recent versions of SVN.

 Will merge to 'next'.


* tz/doc-show-defaults-to-head (2018-01-30) 1 commit
 - doc: mention 'git show' defaults to HEAD

 Doc update.

 Will merge to 'next'.


* nd/ignore-glob-doc-update (2018-01-31) 1 commit
 - gitignore.txt: elaborate shell glob syntax


* nd/rebase-show-current-patch (2018-01-31) 3 commits
 - rebase: introduce and use pseudo-ref ORIG_COMMIT
 - rebase: add --show-current-patch
 - am: add --show-current-patch

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

* 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>


* dj/runtime-prefix (2017-12-05) 4 commits
 . exec_cmd: RUNTIME_PREFIX on some POSIX systems
 . Makefile: add Perl runtime prefix support
 . Makefile: add support for "perllibdir"
 . 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.

 Tentatively kicked out of 'next' to see how well another topic
 ab/simplify-perl-makefile that heavily conflicts with this fares.


* 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>


* cc/require-tcl-tk-for-build (2017-11-29) 2 commits
 - travis-ci: avoid new tcl/tk build requirement
 - Makefile: check that tcl/tk is installed

 A first-time builder of Git may have installed neither tclsh nor
 msgfmt, in which case git-gui and gitk part will fail and break the
 build.  As a workaround, refuse to run a build when tclsh is not
 installed and NO_TCLTK is not set.

 Undecided.
 I still feel that requring tclsh to be installed, with or without
 "escape hatch" for experts, may be too heavy-handed.


* mg/merge-base-fork-point (2017-09-17) 3 commits
 - merge-base: find fork-point outside partial reflog
 - merge-base: return fork-point outside reflog
 - t6010: test actual test output

 "merge-base --fork-point $branch $commit" is used to guess on which
 commit among the commits that were once at the tip of the $branch the
 $commit was built on top of, and it learns these historical tips from
 the reflog of the $branch.  When the true fork-point is lost due to
 pruning of old reflog entries, the command does not give any output,
 because it has no way to guess correctly and does not want to mislead
 the user with a wrong guess.

 The command has been updated to give the best but not known to be
 correct guess, based on a hope that a merge-base between $commit and a
 virtual merge across all the reflog entries that still are available
 for $branch may still be a closer to the true fork-point than the
 merge-base between $commit and the current tip of the $branch.

 This may have to be offered by an additional option, to allow the
 users that are prepared to see a potentially incorrect guess to opt
 into the feature, without affecting the current callers that may not
 be prepared to accept a guess that is not known to be correct.

 What's the doneness of this one?


* 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).


* 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>

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

* jh/status-no-ahead-behind (2018-01-24) 4 commits
 - status: support --no-ahead-behind in long format
 - status: update short status to respect --no-ahead-behind
 - status: add --[no-]ahead-behind to status and commit for V2 format.
 - stat_tracking_info: return +1 when branches not equal

 "git status" can spend a lot of cycles to compute the relation
 between the current branch and its upstream, which can now be
 disabled with "--no-ahead-behind" option.


* nd/worktree-move (2018-01-24) 7 commits
 - worktree remove: allow it when $GIT_WORK_TREE is already gone
 - 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.


* nd/trace-with-env (2018-01-19) 7 commits
 - run-command.c: print new cwd in trace_run_command()
 - run-command.c: print env vars in trace_run_command()
 - run-command.c: print program 'git' when tracing git_cmd mode
 - run-command.c: introduce trace_run_command()
 - trace.c: move strbuf_release() out of print_trace_line()
 - trace: avoid unnecessary quoting
 - sq_quote_argv: drop maxlen parameter

 The tracing machinery learned to report tweaking of environment
 variables as well.

 Will merge to 'next'.


* cl/t9001-cleanup (2018-01-12) 1 commit
 - t9001: use existing helper in send-email test

 Test clean-up.

 Will merge to 'next'.


* kg/packed-ref-cache-fix (2018-01-24) 6 commits
 - packed_ref_cache: don't use mmap() for small files
 - load_contents(): don't try to mmap an empty file
 - packed_ref_iterator_begin(): make optimization more general
 - find_reference_location(): make function safe for empty snapshots
 - create_snapshot(): use `xmemdupz()` rather than a strbuf
 - struct snapshot: store `start` rather than `header_len`

 Avoid mmapping small files while using packed refs (especially ones
 with zero size, which would cause later munmap() to fail).


* ks/submodule-doc-updates (2018-01-16) 2 commits
 - Doc/git-submodule: improve readability and grammar of a sentence
 - Doc/gitsubmodules: make some changes to improve readability and syntax

 Doc updates.

 Will merge to 'next'.


* nd/shared-index-fix (2018-01-24) 3 commits
 - read-cache: don't write index twice if we can't write shared index
 - read-cache.c: move tempfile creation/cleanup out of write_shared_index
 - read-cache.c: change type of "temp" in write_shared_index()

 Will merge to 'next'.


* rs/describe-unique-abbrev (2018-01-16) 1 commit
 - describe: use strbuf_add_unique_abbrev() for adding short hashes

 Code clean-up.

 Will merge to 'next'.


* tb/crlf-conv-flags (2018-01-16) 1 commit
 - convert_to_git(): safe_crlf/checksafe becomes int conv_flags
 (this branch is used by ls/checkout-encoding.)

 Code clean-up.

 Will merge to 'next'.


* nd/diff-flush-before-warning (2018-01-16) 1 commit
 - diff.c: flush stdout before printing rename warnings

 Avoid showing a warning message in the middle of a line of "git
 diff" output.

 Will merge to 'next'.


* rb/hashmap-h-compilation-fix (2018-01-16) 1 commit
 - hashmap.h: remove unused variable

 Code clean-up.

 Will merge to 'next'.


* cc/sha1-file-name (2018-01-19) 2 commits
 - sha1_file: improve sha1_file_name() perfs
 - sha1_file: remove static strbuf from sha1_file_name()

 Code clean-up.

 Will merge to 'next'.


* cl/send-email-reply-to (2018-01-17) 2 commits
 - send-email: support separate "Reply-To" address
 - send-email: rename variables for "In-reply-to" to $foo_in_reply_to

 "git send-email" learned "--reply-to=<address>" option.

 May want to get the log messages updated.
 cf. <CAN0heSqxmLoh33i65JPhyQbmPaAcJcwrTCO+ZD4eb+qh8Pf8+w@mail.gmail.com>


* ds/use-get-be64 (2018-01-19) 1 commit
 - packfile: use get_be64() for large offsets

 Code clean-up.

 Will merge to 'next'.


* en/merge-recursive-fixes (2018-01-19) 3 commits
 - merge-recursive: add explanation for src_entry and dst_entry
 - merge-recursive: fix logic ordering issue
 - Tighten and correct a few testcases for merging and cherry-picking
 (this branch is used by en/rename-directory-detection.)


* jc/worktree-add-short-help (2018-01-17) 1 commit
 - worktree: say that "add" takes an arbitrary commit in short-help


* js/rebase-recreate-merge (2018-01-30) 10 commits
 - rebase -i: introduce --recreate-merges=[no-]rebase-cousins
 - pull: accept --rebase=recreate to recreate the branch topology
 - sequencer: handle autosquash and post-rewrite for merge commands
 - sequencer: make refs generated by the `label` command worktree-local
 - rebase: introduce the --recreate-merges option
 - rebase-helper --make-script: introduce a flag to recreate merges
 - sequencer: fast-forward merge commits, if possible
 - sequencer: introduce the `merge` command
 - sequencer: introduce new commands to reset the revision
 - git-rebase--interactive: clarify arguments

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


* jt/http-redact-cookies (2018-01-19) 2 commits
 - http: support omitting data from traces
 - http: support cookie redaction when tracing

 The http tracing code, often used to debug connection issues,
 learned to redact potentially sensitive information from its output
 so that it can be more safely sharable.

 Will merge to 'next'.


* mr/packed-ref-store-fix (2018-01-19) 1 commit
 - files_initial_transaction_commit(): only unlock if locked

 Crash fix for a corner case where an error codepath tried to unlock
 what it did not acquire lock on.

 Will merge to 'next'.


* rs/strbuf-cocci-workaround (2018-01-19) 1 commit
 - cocci: use format keyword instead of a literal string

 Update Coccinelle rules to catch and optimize strbuf_addf(&buf, "%s", str)

 Will merge to 'next'.


* sg/cocci-move-array (2018-01-22) 1 commit
 - Use MOVE_ARRAY

 Code clean-up.

 Will merge to 'next'.


* tg/split-index-fixes (2018-01-19) 3 commits
 - travis: run tests with GIT_TEST_SPLIT_INDEX
 - split-index: don't write cache tree with null oid entries
 - read-cache: fix reading the shared index for other repos

 The split-index mode had a few corner case bugs fixed.

 Will merge to 'next'.


* jt/fsck-code-cleanup (2018-01-23) 1 commit
 - fsck: fix leak when traversing trees


* ab/wildmatch-tests (2018-01-30) 10 commits
 - wildmatch test: mark test as EXPENSIVE_ON_WINDOWS
 - test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite
 - wildmatch test: create & test files on disk in addition to in-memory
 - wildmatch test: perform all tests under all wildmatch() modes
 - wildmatch test: use test_must_fail, not ! for test-wildmatch
 - wildmatch test: remove dead fnmatch() test code
 - wildmatch test: use a paranoia pattern from nul_match()
 - wildmatch test: don't try to vertically align our output
 - wildmatch test: use more standard shell style
 - wildmatch test: indent with tabs, not spaces

 More tests for wildmatch functions.

 Expecting an update.
 cf. <87vaga9mgf.fsf@evledraar.gmail.com>


* bw/protocol-v2 (2018-01-26) 27 commits
 - remote-curl: implement stateless-connect command
 - 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
 - fetch-pack: perform a fetch using v2
 - upload-pack: introduce fetch server command
 - push: pass ref patterns when pushing
 - fetch: pass ref patterns when fetching
 - ls-remote: pass ref patterns when requesting a remote's refs
 - transport: convert transport_get_remote_refs to take a list of ref patterns
 - transport: convert get_refs_list to take a list of ref patterns
 - 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: introduce struct packet_reader
 - pkt-line: introduce packet_read_with_status

 The beginning of the next-gen transfer protocol.


* ls/checkout-encoding (2018-01-30) 6 commits
 - convert: add tracing for 'working-tree-encoding' attribute
 - 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
 - strbuf: add xstrdup_toupper()
 - strbuf: remove unnecessary NUL assignment in xstrdup_tolower()
 (this branch uses tb/crlf-conv-flags.)

 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).


* pc/submodule-helper (2018-01-16) 2 commits
 - submodule: port submodule subcommand 'deinit' from shell to C
 - submodule: port submodule subcommand 'sync' from shell to C

 Rewrite two more "git submodule" subcommands in C.

 Will merge to 'next'.


* sb/blame-color (2018-01-08) 4 commits
 - builtin/blame: highlight recently changed lines
 - builtin/blame: add option to color metadata fields separately
 - builtin/blame: dim uninteresting metadata
 - color.h: document and modernize header


* sg/travis-build-during-script-phase (2018-01-08) 1 commit
 - travis-ci: build Git during the 'script' phase

 Still under discussion.
 cf. <5DE3FA05-2347-4BE7-8A1A-A6E5FEEC7C2B@gmail.com>


* nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
 - dir.c: stop ignoring opendir() error in open_cached_dir()
 - update-index doc: note a fixed bug in the untracked cache
 - dir.c: fix missing dir invalidation in untracked code
 - dir.c: avoid stat() in valid_cached_dir()
 - status: add a failing test showing a core.untrackedCache bug

 Some bugs around "untracked cache" feature have been fixed.

 Will merge to 'next'.


* np/send-email-header-parsing (2017-12-15) 1 commit
 - send-email: extract email-parsing code into a subroutine

 Code refactoring.

 Undecided.


* ab/sha1dc-build (2017-12-12) 4 commits
 . Makefile: use the sha1collisiondetection submodule by default
 - sha1dc_git.h: re-arrange an ifdef chain for a subsequent change
 - Makefile: under "make dist", include the sha1collisiondetection submodule
 - Makefile: don't error out under DC_SHA1_EXTERNAL if DC_SHA1_SUBMODULE=auto

 Push the submodule version of collision-detecting SHA-1 hash
 implementation a bit harder on builders.

 The earlier two may make sense, but leaning toward rejecting the last step.
 cf. <xmqqk1xw6c24.fsf@gitster.mtv.corp.google.com>


* ab/simplify-perl-makefile (2018-01-03) 3 commits
  (merged to 'next' on 2018-01-23 at 1506e0651a)
 + perl: treat PERLLIB_EXTRA as an extra path again
 + perl: avoid *.pmc and fix Error.pm further
 + Makefile: replace perl/Makefile.PL with simple make rules

 Originally merged to 'next' on 2018-01-03

 The build procedure for perl/ part has been greatly simplified by
 weaning ourselves off of MakeMaker.

 Will cook in 'next'.


* en/rename-directory-detection (2018-01-31) 31 commits
 - 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: add a new hashmap for storing file collisions
 - 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: add a new hashmap for storing directory 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
 (this branch uses en/merge-recursive-fixes.)

 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'.


* pw/sequencer-in-process-commit (2018-01-24) 14 commits
 - sequencer: run 'prepare-commit-msg' hook
 - t7505: add tests for cherry-pick and rebase -i/-p
 - t7505: style fixes
 - sequencer: assign only free()able strings to gpg_sign
 - sequencer: improve config handling
 - t3512/t3513: remove KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT=1
 - sequencer: try to commit without forking 'git commit'
 - sequencer: load commit related config
 - sequencer: simplify adding Signed-off-by: trailer
 - commit: move print_commit_summary() to libgit
 - commit: move post-rewrite code to libgit
 - Add a function to update HEAD after creating a commit
 - commit: move empty message checks to libgit
 - t3404: check intermediate squash messages

 The sequencer infrastructure is shared across "git cherry-pick",
 "git rebase -i", etc., and has always spawned "git commit" when it
 needs to create a commit.  It has been taught to do so internally,
 when able, by reusing the codepath "git commit" itself uses, which
 gives performance boost for a few tens of percents in some sample
 scenarios.

 Will merge to 'next'.


* jh/fsck-promisors (2017-12-08) 10 commits
  (merged to 'next' on 2018-01-23 at ca59f5c18e)
 + gc: do not repack promisor packfiles
 + rev-list: support termination at promisor objects
 + sha1_file: support lazily fetching missing objects
 + introduce fetch-object: fetch one promisor object
 + index-pack: refactor writing of .keep files
 + fsck: support promisor objects as CLI argument
 + fsck: support referenced promisor objects
 + fsck: support refs pointing to promisor objects
 + fsck: introduce partialclone extension
 + extension.partialclone: introduce partial clone extension
 (this branch is used by jh/partial-clone.)

 Originally merged to 'next' on 2018-01-17

 In preparation for implementing narrow/partial clone, the machinery
 for checking object connectivity used by gc and fsck has been
 taught that a missing object is OK when it is referenced by a
 packfile specially marked as coming from trusted repository that
 promises to make them available on-demand and lazily.

 Will cook in 'next'.


* jh/partial-clone (2017-12-08) 13 commits
  (merged to 'next' on 2018-01-23 at de0f0111ea)
 + t5616: test bulk prefetch after partial fetch
 + fetch: inherit filter-spec from partial clone
 + t5616: end-to-end tests for partial clone
 + fetch-pack: restore save_commit_buffer after use
 + unpack-trees: batch fetching of missing blobs
 + clone: partial clone
 + partial-clone: define partial clone settings in config
 + fetch: support filters
 + fetch: refactor calculation of remote list
 + fetch-pack: test support excluding large blobs
 + fetch-pack: add --no-filter
 + fetch-pack, index-pack, transport: partial clone
 + upload-pack: add object filtering for partial clone
 (this branch uses jh/fsck-promisors.)

 Originally merged to 'next' on 2018-01-17

 The machinery to clone & fetch, which in turn involves packing and
 unpacking objects, have been told how to omit certain objects using
 the filtering mechanism introduced by the jh/object-filtering
 topic, and also mark the resulting pack as a promisor pack to
 tolerate missing objects, taking advantage of the mechanism
 introduced by the jh/fsck-promisors topic.

 Will cook in 'next'.


* ot/mru-on-list (2017-10-01) 1 commit
 - mru: use double-linked list from list.h
 (this branch is used by gs/retire-mru.)

 The first step to getting rid of mru API and using the
 doubly-linked list API directly instead.

 Will merge to 'next'.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-01  0:56 What's cooking in git.git (Jan 2018, #04; Wed, 31) Junio C Hamano
@ 2018-02-01 11:05 ` Ævar Arnfjörð Bjarmason
  2018-02-02 18:09   ` Junio C Hamano
  2018-02-09 17:06   ` Johannes Schindelin
  2018-02-01 12:11 ` Ævar Arnfjörð Bjarmason
  2018-02-09 18:37 ` Ævar Arnfjörð Bjarmason
  2 siblings, 2 replies; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-01 11:05 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin


On Thu, Feb 01 2018, Junio C. Hamano jotted:

> * ab/wildmatch-tests (2018-01-30) 10 commits
>  - wildmatch test: mark test as EXPENSIVE_ON_WINDOWS
>  - test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite
>  - wildmatch test: create & test files on disk in addition to in-memory
>  - wildmatch test: perform all tests under all wildmatch() modes
>  - wildmatch test: use test_must_fail, not ! for test-wildmatch
>  - wildmatch test: remove dead fnmatch() test code
>  - wildmatch test: use a paranoia pattern from nul_match()
>  - wildmatch test: don't try to vertically align our output
>  - wildmatch test: use more standard shell style
>  - wildmatch test: indent with tabs, not spaces
>
>  More tests for wildmatch functions.
>
>  Expecting an update.
>  cf. <87vaga9mgf.fsf@evledraar.gmail.com>

The 2018-01-30 series is the update mentioned in
87vaga9mgf.fsf@evledraar.gmail.com. You probably noticed this / just
didn't adjust the note since you queued in in pu already, but just in
case: the known issues in it have been resolved, but hopefully Johannes
Schindelin can test it on Windows & report.

> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>  - update-index doc: note a fixed bug in the untracked cache
>  - dir.c: fix missing dir invalidation in untracked code
>  - dir.c: avoid stat() in valid_cached_dir()
>  - status: add a failing test showing a core.untrackedCache bug
>
>  Some bugs around "untracked cache" feature have been fixed.
>
>  Will merge to 'next'.

It must be Murphy's law or something, but even though the bug has been
there for years I just had some internal users again run into the bug
this fixes, so I'm building an internal v2.16.1 + custom patches (this
included).

> * ab/sha1dc-build (2017-12-12) 4 commits
>  . Makefile: use the sha1collisiondetection submodule by default
>  - sha1dc_git.h: re-arrange an ifdef chain for a subsequent change
>  - Makefile: under "make dist", include the sha1collisiondetection submodule
>  - Makefile: don't error out under DC_SHA1_EXTERNAL if DC_SHA1_SUBMODULE=auto
>
>  Push the submodule version of collision-detecting SHA-1 hash
>  implementation a bit harder on builders.
>
>  The earlier two may make sense, but leaning toward rejecting the last step.
>  cf. <xmqqk1xw6c24.fsf@gitster.mtv.corp.google.com>

This has been lingering for a long time. I think it makes sense just to
merge the first 3 down and then we can discuss 4/4 in another
submission. [12]/4 solve real bugs we have now, 3/4 is harmless to merge
down (and makes 4/4 smaller when we get around to discussing it again),
it's just 4/4 that's been stalling this.

Do you want to peel of 4/4 and just keep 1-3 should I submit another
version without 4/4?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-01  0:56 What's cooking in git.git (Jan 2018, #04; Wed, 31) Junio C Hamano
  2018-02-01 11:05 ` Ævar Arnfjörð Bjarmason
@ 2018-02-01 12:11 ` Ævar Arnfjörð Bjarmason
  2018-02-02 18:05   ` Junio C Hamano
  2018-02-09 18:37 ` Ævar Arnfjörð Bjarmason
  2 siblings, 1 reply; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-01 12:11 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git


On Thu, Feb 01 2018, Junio C. Hamano jotted:

> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>  - update-index doc: note a fixed bug in the untracked cache
>  - dir.c: fix missing dir invalidation in untracked code
>  - dir.c: avoid stat() in valid_cached_dir()
>  - status: add a failing test showing a core.untrackedCache bug
>
>  Some bugs around "untracked cache" feature have been fixed.
>
>  Will merge to 'next'.

The "update-index doc: note a fixed bug in the untracked cache" needs to
be amended so it doesn't say "Before 2.16, ":

    https://github.com/gitster/git/commit/b9fc38c9f90b8bf2c9147ad536813b66aa45220d#diff-01fe1588047a177245bfaf82336cdeaeR467

I'm not sure whether you're planning this for 2.16.2, or whether it'll
be in 2.17.0, but the patch should be amended to mention either one of
those.

I can submit a replacement patch, but figured this was trivial enough
(and you know more about the release plan) that you'd like to amend this
locally.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-01 12:11 ` Ævar Arnfjörð Bjarmason
@ 2018-02-02 18:05   ` Junio C Hamano
  2018-02-02 19:29     ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2018-02-02 18:05 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: git

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

> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>
>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>>  - update-index doc: note a fixed bug in the untracked cache
>>  - dir.c: fix missing dir invalidation in untracked code
>>  - dir.c: avoid stat() in valid_cached_dir()
>>  - status: add a failing test showing a core.untrackedCache bug
>>
>>  Some bugs around "untracked cache" feature have been fixed.
>>
>>  Will merge to 'next'.
>
> The "update-index doc: note a fixed bug in the untracked cache" needs to
> be amended so it doesn't say "Before 2.16, ":

True; we could just say "earlier", but I am inclined to suggest that
we get drop it altogether.  Description of historical bugs is of no
interest with the version that already fixes them, so the _only_
value the doc update adds is to tell readers that the untracked
cache feature is still not well proven, and core.untrackedCache may
serve as an escape hatch from its bugs by disabling the mechanism
added for the feature.  I am *not* opposed to a replacement of the
patch that just says something like "This feature has been cause of
bugs even in recent versions of Git, and you may want to disable it
as a workaround when you are hit by an otherwise undiscovered bug in
this area", though.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-01 11:05 ` Ævar Arnfjörð Bjarmason
@ 2018-02-02 18:09   ` Junio C Hamano
  2018-02-09 17:06   ` Johannes Schindelin
  1 sibling, 0 replies; 22+ messages in thread
From: Junio C Hamano @ 2018-02-02 18:09 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: git, Johannes Schindelin

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

> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>
>> * ab/wildmatch-tests (2018-01-30) 10 commits
> The 2018-01-30 series is the update mentioned in
> 87vaga9mgf.fsf@evledraar.gmail.com. You probably noticed this / just
> didn't adjust the note since you queued in in pu already, but just in
> case: the known issues in it have been resolved, but hopefully Johannes
> Schindelin can test it on Windows & report.

Thanks for a correction.  Very much appreciated.  Let's start moving
this forward then.
>> * ab/sha1dc-build (2017-12-12) 4 commits
>>  . Makefile: use the sha1collisiondetection submodule by default
>>  - sha1dc_git.h: re-arrange an ifdef chain for a subsequent change
>>  - Makefile: under "make dist", include the sha1collisiondetection submodule
>>  - Makefile: don't error out under DC_SHA1_EXTERNAL if DC_SHA1_SUBMODULE=auto
> Do you want to peel of 4/4 and just keep 1-3 should I submit another
> version without 4/4?

Nah, let's just discard the tip one without prejudice and move the
remainder forward.

Thanks.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-02 18:05   ` Junio C Hamano
@ 2018-02-02 19:29     ` Ævar Arnfjörð Bjarmason
  0 siblings, 0 replies; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-02 19:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git


On Fri, Feb 02 2018, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>>
>>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>>>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>>>  - update-index doc: note a fixed bug in the untracked cache
>>>  - dir.c: fix missing dir invalidation in untracked code
>>>  - dir.c: avoid stat() in valid_cached_dir()
>>>  - status: add a failing test showing a core.untrackedCache bug
>>>
>>>  Some bugs around "untracked cache" feature have been fixed.
>>>
>>>  Will merge to 'next'.
>>
>> The "update-index doc: note a fixed bug in the untracked cache" needs to
>> be amended so it doesn't say "Before 2.16, ":
>
> True; we could just say "earlier", but I am inclined to suggest that
> we get drop it altogether.  Description of historical bugs is of no
> interest with the version that already fixes them, so the _only_
> value the doc update adds is to tell readers that the untracked
> cache feature is still not well proven, and core.untrackedCache may
> serve as an escape hatch from its bugs by disabling the mechanism
> added for the feature.  I am *not* opposed to a replacement of the
> patch that just says something like "This feature has been cause of
> bugs even in recent versions of Git, and you may want to disable it
> as a workaround when you are hit by an otherwise undiscovered bug in
> this area", though.

 - It's my experience that most users today who aren't *nix graybeards
   don't use the documentation shipped on their system as their primary
   source for docs.

   They go to Google and might find the manpage there. Thus this
   documentation will be read by users on pre-2.17 (or whenever this bug
   fix gets included).

 - This is very useful information if you're deploying
   core.untrackedCache across a site with differing git versions. Just
   because you have 2.17 doesn't mean everywhere you're about to deploy
   core.untrackedCache does.

 - In general I agree that we shouldn't be documenting old bugs, but I
   think in this case it makes sense since the bug's really bad. Without
   thinking to disable core.untrackedCache there's seemingly no way to
   fix it without wiping away the index, which might lose you work.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-01 11:05 ` Ævar Arnfjörð Bjarmason
  2018-02-02 18:09   ` Junio C Hamano
@ 2018-02-09 17:06   ` Johannes Schindelin
  2018-02-09 18:30     ` Ævar Arnfjörð Bjarmason
  1 sibling, 1 reply; 22+ messages in thread
From: Johannes Schindelin @ 2018-02-09 17:06 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, git

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

Hi,

On Thu, 1 Feb 2018, Ævar Arnfjörð Bjarmason wrote:

> On Thu, Feb 01 2018, Junio C. Hamano jotted:
> 
> > * ab/wildmatch-tests (2018-01-30) 10 commits
> >  - wildmatch test: mark test as EXPENSIVE_ON_WINDOWS
> >  - test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite
> >  - wildmatch test: create & test files on disk in addition to in-memory
> >  - wildmatch test: perform all tests under all wildmatch() modes
> >  - wildmatch test: use test_must_fail, not ! for test-wildmatch
> >  - wildmatch test: remove dead fnmatch() test code
> >  - wildmatch test: use a paranoia pattern from nul_match()
> >  - wildmatch test: don't try to vertically align our output
> >  - wildmatch test: use more standard shell style
> >  - wildmatch test: indent with tabs, not spaces
> >
> >  More tests for wildmatch functions.
> >
> >  Expecting an update.
> >  cf. <87vaga9mgf.fsf@evledraar.gmail.com>
> 
> The 2018-01-30 series is the update mentioned in
> 87vaga9mgf.fsf@evledraar.gmail.com. You probably noticed this / just
> didn't adjust the note since you queued in in pu already, but just in
> case: the known issues in it have been resolved, but hopefully Johannes
> Schindelin can test it on Windows & report.

Sorry, I did not have time to look at this. All I can say is that the `pu`
builds are green for a couple of days already. Which I celebrate!

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-09 17:06   ` Johannes Schindelin
@ 2018-02-09 18:30     ` Ævar Arnfjörð Bjarmason
  0 siblings, 0 replies; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 18:30 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git


On Fri, Feb 09 2018, Johannes Schindelin jotted:

> Hi,
>
> On Thu, 1 Feb 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>>
>> > * ab/wildmatch-tests (2018-01-30) 10 commits
>> >  - wildmatch test: mark test as EXPENSIVE_ON_WINDOWS
>> >  - test-lib: add an EXPENSIVE_ON_WINDOWS prerequisite
>> >  - wildmatch test: create & test files on disk in addition to in-memory
>> >  - wildmatch test: perform all tests under all wildmatch() modes
>> >  - wildmatch test: use test_must_fail, not ! for test-wildmatch
>> >  - wildmatch test: remove dead fnmatch() test code
>> >  - wildmatch test: use a paranoia pattern from nul_match()
>> >  - wildmatch test: don't try to vertically align our output
>> >  - wildmatch test: use more standard shell style
>> >  - wildmatch test: indent with tabs, not spaces
>> >
>> >  More tests for wildmatch functions.
>> >
>> >  Expecting an update.
>> >  cf. <87vaga9mgf.fsf@evledraar.gmail.com>
>>
>> The 2018-01-30 series is the update mentioned in
>> 87vaga9mgf.fsf@evledraar.gmail.com. You probably noticed this / just
>> didn't adjust the note since you queued in in pu already, but just in
>> case: the known issues in it have been resolved, but hopefully Johannes
>> Schindelin can test it on Windows & report.
>
> Sorry, I did not have time to look at this. All I can say is that the `pu`
> builds are green for a couple of days already. Which I celebrate!

Thanks, if you get time it would be great to know if:

    time GIT_TEST_LONG=1 ./t3070-wildmatch.sh

Runs cleanly for you, and how long it takes now. Even though it's going
to take a long time still, I optimized the test a lot so I expect it'll
be quicker.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-01  0:56 What's cooking in git.git (Jan 2018, #04; Wed, 31) Junio C Hamano
  2018-02-01 11:05 ` Ævar Arnfjörð Bjarmason
  2018-02-01 12:11 ` Ævar Arnfjörð Bjarmason
@ 2018-02-09 18:37 ` Ævar Arnfjörð Bjarmason
  2018-02-09 18:54   ` Junio C Hamano
  2018-02-10 10:09   ` What's cooking in git.git (Jan 2018, #04; Wed, 31) Duy Nguyen
  2 siblings, 2 replies; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 18:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy


On Thu, Feb 01 2018, Junio C. Hamano jotted:

> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>  - update-index doc: note a fixed bug in the untracked cache
>  - dir.c: fix missing dir invalidation in untracked code
>  - dir.c: avoid stat() in valid_cached_dir()
>  - status: add a failing test showing a core.untrackedCache bug
>
>  Some bugs around "untracked cache" feature have been fixed.
>
>  Will merge to 'next'.

I think you / Nguyễn may not have seen my
<87d11omi2o.fsf@evledraar.gmail.com>
(https://public-inbox.org/git/87d11omi2o.fsf@evledraar.gmail.com/)

As noted there I think it's best to proceed without the "dir.c: stop
ignoring opendir[...]" patch.

It's going to be a bad regression in 2.17 if it ends up spewing pagefuls
of warnings in previously working repos if the UC is on.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-09 18:37 ` Ævar Arnfjörð Bjarmason
@ 2018-02-09 18:54   ` Junio C Hamano
  2018-02-09 21:04     ` [PATCH 0/2] update-index doc: note new caveats in 2.17 Ævar Arnfjörð Bjarmason
                       ` (2 more replies)
  2018-02-10 10:09   ` What's cooking in git.git (Jan 2018, #04; Wed, 31) Duy Nguyen
  1 sibling, 3 replies; 22+ messages in thread
From: Junio C Hamano @ 2018-02-09 18:54 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: git, Nguyễn Thái Ngọc Duy

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

> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>
>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>>  - update-index doc: note a fixed bug in the untracked cache
>>  - dir.c: fix missing dir invalidation in untracked code
>>  - dir.c: avoid stat() in valid_cached_dir()
>>  - status: add a failing test showing a core.untrackedCache bug
>>
>>  Some bugs around "untracked cache" feature have been fixed.
>>
>>  Will merge to 'next'.
>
> I think you / Nguyễn may not have seen my
> <87d11omi2o.fsf@evledraar.gmail.com>
> (https://public-inbox.org/git/87d11omi2o.fsf@evledraar.gmail.com/)
>
> As noted there I think it's best to proceed without the "dir.c: stop
> ignoring opendir[...]" patch.
>
> It's going to be a bad regression in 2.17 if it ends up spewing pagefuls
> of warnings in previously working repos if the UC is on.

Well, I am not sure if it is a regression to diagnose problematic
untracked cache information left by earlier version of the software
with bugs.  After all, this is still an experimental feature, and we
do want to see the warning to serve its purpose to diagnose possible
remaining bugs, and new similar ones when a newer iteration of the
feature introduces, no?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 0/2] update-index doc: note new caveats in 2.17
  2018-02-09 18:54   ` Junio C Hamano
@ 2018-02-09 21:04     ` Ævar Arnfjörð Bjarmason
  2018-02-09 21:40       ` Junio C Hamano
  2018-02-09 21:04     ` [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache Ævar Arnfjörð Bjarmason
  2018-02-09 21:04     ` [PATCH 2/2] update-index doc: note the caveat with "could not open..." Ævar Arnfjörð Bjarmason
  2 siblings, 1 reply; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 21:04 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
	Ævar Arnfjörð Bjarmason

On Fri, Feb 09 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> I think you / Nguyễn may not have seen my
>> <87d11omi2o.fsf@evledraar.gmail.com>
>> (https://public-inbox.org/git/87d11omi2o.fsf@evledraar.gmail.com/)
>>
>> As noted there I think it's best to proceed without the "dir.c: stop
>> ignoring opendir[...]" patch.
>>
>> It's going to be a bad regression in 2.17 if it ends up spewing pagefuls
>> of warnings in previously working repos if the UC is on.
>
> Well, I am not sure if it is a regression to diagnose problematic
> untracked cache information left by earlier version of the software
> with bugs.  After all, this is still an experimental feature, and we
> do want to see the warning to serve its purpose to diagnose possible
> remaining bugs, and new similar ones when a newer iteration of the
> feature introduces, no?

Fair enough. I just wanted to make sure it had been seen. It wasn't
obvious whether it had just been missed since there was no follow-up
there or note in WC.

We were disagreeing to the extent that some of this should be
documented in 878tcbmbqb.fsf@evledraar.gmail.com and related, and I
see you've ejected the doc patch I had in that series.

I really think we should be saying something like what this new doc
series says, it's conceptually on top of Duy's series but applies on
top of master.

I think there's room to quibble about whether to include 1/2 at all
since it's a relatively obscure edge case.

2/2 however is something I think a *lot* of users are going to hit. I
just skimmed the relevant bits of git-config and git-update-index now,
and nothing describes the UC as an experimental feature, and it's been
well-known to improve performance.

When users upgrade to 2.17 they're going to have git yelling at them
(as my users did) on existing checkouts, with no indication whatsoever
that it's due to the UC or how to fix it.

Let's at least documente it. I also wonder if the "dir.c: stop
ignoring opendir() error in open_cached_dir()" change shouldn't have
something in the warning itself about it being caused by the UC,
doesn't it only warn under that mode? I.e.:

    -"could not open directory '%s'")
    +"core.untrackedCache: could not open directory '%s'")

Ævar Arnfjörð Bjarmason (2):
  update-index doc: note a fixed bug in the untracked cache
  update-index doc: note the caveat with "could not open..."

 Documentation/git-update-index.txt | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

-- 
2.15.1.424.g9478a66081


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache
  2018-02-09 18:54   ` Junio C Hamano
  2018-02-09 21:04     ` [PATCH 0/2] update-index doc: note new caveats in 2.17 Ævar Arnfjörð Bjarmason
@ 2018-02-09 21:04     ` Ævar Arnfjörð Bjarmason
  2018-02-09 21:52       ` Junio C Hamano
  2018-02-09 21:04     ` [PATCH 2/2] update-index doc: note the caveat with "could not open..." Ævar Arnfjörð Bjarmason
  2 siblings, 1 reply; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 21:04 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
	Ævar Arnfjörð Bjarmason

Document the bug tested for in my "status: add a failing test showing
a core.untrackedCache bug" and fixed in Duy's "dir.c: fix missing dir
invalidation in untracked code".

Since this is very likely something others will encounter in the
future on older versions, and it's not obvious how to fix it let's
document both that it exists, and how to "fix" it with a one-off
command.

As noted in that commit, even though this bug gets the untracked cache
into a bad state, we have not yet found a case where this is user
visible, and thus it makes sense for these docs to focus on the
symlink case only.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/git-update-index.txt | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index bdb0342593..e30b185918 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -464,6 +464,22 @@ command reads the index; while when `--[no-|force-]untracked-cache`
 are used, the untracked cache is immediately added to or removed from
 the index.
 
+Before 2.17, the untracked cache had a bug where replacing a directory
+with a symlink to another directory could cause it to incorrectly show
+files tracked by git as untracked. See the "status: add a failing test
+showing a core.untrackedCache bug" commit to git.git. A workaround for
+that was (and this might work for other undiscoverd bugs in the
+future):
+
+----------------
+$ git -c core.untrackedCache=false status
+----------------
+
+This bug has also been shown to affect non-symlink cases of replacing
+a directory with a file when it comes to the internal structures of
+the untracked cache, but no case has been found where this resulted in
+wrong "git status" output.
+
 File System Monitor
 -------------------
 
-- 
2.15.1.424.g9478a66081


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [PATCH 2/2] update-index doc: note the caveat with "could not open..."
  2018-02-09 18:54   ` Junio C Hamano
  2018-02-09 21:04     ` [PATCH 0/2] update-index doc: note new caveats in 2.17 Ævar Arnfjörð Bjarmason
  2018-02-09 21:04     ` [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache Ævar Arnfjörð Bjarmason
@ 2018-02-09 21:04     ` Ævar Arnfjörð Bjarmason
  2 siblings, 0 replies; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 21:04 UTC (permalink / raw)
  To: git
  Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy,
	Ævar Arnfjörð Bjarmason

Note the caveat where 2.17 is stricter about index validation
potentially causing "could not open directory" warnings when git is
upgraded. See the preceding "dir.c: stop ignoring opendir() error in
open_cached_dir()" change.

This caused some mayhem when I upgraded git to a version with this
series at Booking.com, and other users have doubtless enabled the UC
extension and are in for a surprise when they upgrade. Let's give them
a headsup in the docs.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 Documentation/git-update-index.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index e30b185918..0c81600d8c 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -480,6 +480,16 @@ a directory with a file when it comes to the internal structures of
 the untracked cache, but no case has been found where this resulted in
 wrong "git status" output.
 
+There are also cases where existing indexes written by git versions
+before 2.17 will reference directories that don't exist anymore,
+potentially causing many "could not open directory" warnings to be
+printed on "git status". These are new warnings for existing issues
+that were previously silently discarded.
+
+As with the bug described above the solution is to one-off do a "git
+status" run with `core.untrackedCache=false` to flush out the leftover
+bad data.
+
 File System Monitor
 -------------------
 
-- 
2.15.1.424.g9478a66081


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 0/2] update-index doc: note new caveats in 2.17
  2018-02-09 21:04     ` [PATCH 0/2] update-index doc: note new caveats in 2.17 Ævar Arnfjörð Bjarmason
@ 2018-02-09 21:40       ` Junio C Hamano
  2018-02-09 22:10         ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2018-02-09 21:40 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: git, Nguyễn Thái Ngọc Duy

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

> When users upgrade to 2.17 they're going to have git yelling at them
> (as my users did) on existing checkouts, with no indication whatsoever
> that it's due to the UC or how to fix it.

Wait.  Are you saying that the new warning is "warning" against a
condition that is not an error?

> ... doesn't it only warn under that mode? I.e.:
>
>     -"could not open directory '%s'")
>     +"core.untrackedCache: could not open directory '%s'")

For example, if it attempts to open a directory which does *not*
have to exist, and sees an error from opendir() due to ENOENT, then
I do not think it should be giving a warning.  If we positively know
that a directory should exist there and we cannot open it, of course
we should warn.  Also, if we know a directory should be readable
when it exists, then we should be warning when we see an error other
than ENOENT.

So...

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache
  2018-02-09 21:04     ` [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache Ævar Arnfjörð Bjarmason
@ 2018-02-09 21:52       ` Junio C Hamano
  2018-02-09 22:14         ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2018-02-09 21:52 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: git, Nguyễn Thái Ngọc Duy

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

> +Before 2.17, the untracked cache had a bug where replacing a directory
> +with a symlink to another directory could cause it to incorrectly show
> +files tracked by git as untracked. See the "status: add a failing test
> +showing a core.untrackedCache bug" commit to git.git. A workaround for
> +that was (and this might work for other undiscoverd bugs in the
> +future):

s/undiscoverd/undiscovered/

But more importantly, would it help _us_ to encourage people to
squelch the diagnoses without telling us about potential breakage, I
wonder, by telling them to do this for other undiscovered cases,
too?

Will queue with the above typofix, together with the other one.  I
am not sure if we want to say "Before 2.17", though.

> +
> +----------------
> +$ git -c core.untrackedCache=false status
> +----------------
> +
> +This bug has also been shown to affect non-symlink cases of replacing
> +a directory with a file when it comes to the internal structures of
> +the untracked cache, but no case has been found where this resulted in
> +wrong "git status" output.
> +
>  File System Monitor
>  -------------------

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 0/2] update-index doc: note new caveats in 2.17
  2018-02-09 21:40       ` Junio C Hamano
@ 2018-02-09 22:10         ` Ævar Arnfjörð Bjarmason
  0 siblings, 0 replies; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 22:10 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy


On Fri, Feb 09 2018, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>
>> When users upgrade to 2.17 they're going to have git yelling at them
>> (as my users did) on existing checkouts, with no indication whatsoever
>> that it's due to the UC or how to fix it.
>
> Wait.  Are you saying that the new warning is "warning" against a
> condition that is not an error?

No I mean the warning itself gives you no indication what the solution
is, or why it might be happening, and because it's printed on every
occurrence we had "git status" invocations on some big repos where there
would be hundreds of lines of the same warning for different
now-nonexisting directories.

Deferring it and just printing "we had N cases of..." would be better,
but would make the logic a lot more complex, I'm not sure how common
this would be in the wild, but as noted happened on a large proportion
of our checkouts, so having something mentioning this in the docs is
good.

I only had that git version out for about an hour, but had some users rm
-rfing their checkouts and re-cloning because they couldn't figure out
how to fix it.

Is noting it in the docs going to help all those users? No, but at least
we'll have something Google-able they're likely to find.

>> ... doesn't it only warn under that mode? I.e.:
>>
>>     -"could not open directory '%s'")
>>     +"core.untrackedCache: could not open directory '%s'")
>
> For example, if it attempts to open a directory which does *not*
> have to exist, and sees an error from opendir() due to ENOENT, then
> I do not think it should be giving a warning.  If we positively know
> that a directory should exist there and we cannot open it, of course
> we should warn.  Also, if we know a directory should be readable
> when it exists, then we should be warning when we see an error other
> than ENOENT.

*nod*, so not UC-specific, even though I've only seen it in relation to
that.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache
  2018-02-09 21:52       ` Junio C Hamano
@ 2018-02-09 22:14         ` Ævar Arnfjörð Bjarmason
  2018-02-09 22:50           ` Junio C Hamano
  0 siblings, 1 reply; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 22:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy


On Fri, Feb 09 2018, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:
>
>> +Before 2.17, the untracked cache had a bug where replacing a directory
>> +with a symlink to another directory could cause it to incorrectly show
>> +files tracked by git as untracked. See the "status: add a failing test
>> +showing a core.untrackedCache bug" commit to git.git. A workaround for
>> +that was (and this might work for other undiscoverd bugs in the
>> +future):
>
> s/undiscoverd/undiscovered/
>
> But more importantly, would it help _us_ to encourage people to
> squelch the diagnoses without telling us about potential breakage, I
> wonder, by telling them to do this for other undiscovered cases,
> too?

You mean including something like "if you see this the git ML would like
to hear about it"?

> Will queue with the above typofix, together with the other one.  I
> am not sure if we want to say "Before 2.17", though.

I'm just keeping in mind the user who later on upgrades git from say
2.14 to 2.18 or something, and is able to find in the docs when/why this
new warning got added, which helps diagnose it.

>> +
>> +----------------
>> +$ git -c core.untrackedCache=false status
>> +----------------
>> +
>> +This bug has also been shown to affect non-symlink cases of replacing
>> +a directory with a file when it comes to the internal structures of
>> +the untracked cache, but no case has been found where this resulted in
>> +wrong "git status" output.
>> +
>>  File System Monitor
>>  -------------------

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache
  2018-02-09 22:14         ` Ævar Arnfjörð Bjarmason
@ 2018-02-09 22:50           ` Junio C Hamano
  2018-02-09 22:58             ` Ævar Arnfjörð Bjarmason
  0 siblings, 1 reply; 22+ messages in thread
From: Junio C Hamano @ 2018-02-09 22:50 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: git, Nguyễn Thái Ngọc Duy

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

>> Will queue with the above typofix, together with the other one.  I
>> am not sure if we want to say "Before 2.17", though.
>
> I'm just keeping in mind the user who later on upgrades git from say
> 2.14 to 2.18 or something, and is able to find in the docs when/why this
> new warning got added, which helps diagnose it.

Ah, no, that is not what I meant.  I just didn't think '2.17' in
that sentence may not be understood as "Git version 2.17" by most
readers.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache
  2018-02-09 22:50           ` Junio C Hamano
@ 2018-02-09 22:58             ` Ævar Arnfjörð Bjarmason
  0 siblings, 0 replies; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-09 22:58 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy


On Fri, Feb 09 2018, Junio C. Hamano jotted:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>>> Will queue with the above typofix, together with the other one.  I
>>> am not sure if we want to say "Before 2.17", though.
>>
>> I'm just keeping in mind the user who later on upgrades git from say
>> 2.14 to 2.18 or something, and is able to find in the docs when/why this
>> new warning got added, which helps diagnose it.
>
> Ah, no, that is not what I meant.  I just didn't think '2.17' in
> that sentence may not be understood as "Git version 2.17" by most
> readers.

Ah, I see. Yes I agree, sorry. Do you mind fixing it up to just say
"Before Git version 2.17, ..." ?

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-09 18:37 ` Ævar Arnfjörð Bjarmason
  2018-02-09 18:54   ` Junio C Hamano
@ 2018-02-10 10:09   ` Duy Nguyen
  2018-02-11 14:44     ` Ævar Arnfjörð Bjarmason
  1 sibling, 1 reply; 22+ messages in thread
From: Duy Nguyen @ 2018-02-10 10:09 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, Git Mailing List

On Sat, Feb 10, 2018 at 1:37 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>
>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>>  - update-index doc: note a fixed bug in the untracked cache
>>  - dir.c: fix missing dir invalidation in untracked code
>>  - dir.c: avoid stat() in valid_cached_dir()
>>  - status: add a failing test showing a core.untrackedCache bug
>>
>>  Some bugs around "untracked cache" feature have been fixed.
>>
>>  Will merge to 'next'.
>
> I think you / Nguyễn may not have seen my
> <87d11omi2o.fsf@evledraar.gmail.com>
> (https://public-inbox.org/git/87d11omi2o.fsf@evledraar.gmail.com/)

I have. But since you wrote "I haven't found... yet", I assumed you
were still on it. You didn't give me much info to follow anyway.

> As noted there I think it's best to proceed without the "dir.c: stop
> ignoring opendir[...]" patch.
>
> It's going to be a bad regression in 2.17 if it ends up spewing pagefuls
> of warnings in previously working repos if the UC is on.

"previously working" is a strong word when opendir() starts to
complain. Sure we can suppress/ignore the error messages but I don't
think it's a healthy attitude. Unreported bugs can't be fixed.

We could perhaps stop reporting after we have printed like ... 5 lines
or so? That keeps the noise level down a bit and probably still give
enough indicator to at least repair the cache.
-- 
Duy

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-10 10:09   ` What's cooking in git.git (Jan 2018, #04; Wed, 31) Duy Nguyen
@ 2018-02-11 14:44     ` Ævar Arnfjörð Bjarmason
  2018-02-12 10:04       ` Duy Nguyen
  0 siblings, 1 reply; 22+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2018-02-11 14:44 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Junio C Hamano, Git Mailing List


On Sat, Feb 10 2018, Duy Nguyen jotted:

> On Sat, Feb 10, 2018 at 1:37 AM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>>
>> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>>
>>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>>>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>>>  - update-index doc: note a fixed bug in the untracked cache
>>>  - dir.c: fix missing dir invalidation in untracked code
>>>  - dir.c: avoid stat() in valid_cached_dir()
>>>  - status: add a failing test showing a core.untrackedCache bug
>>>
>>>  Some bugs around "untracked cache" feature have been fixed.
>>>
>>>  Will merge to 'next'.
>>
>> I think you / Nguyễn may not have seen my
>> <87d11omi2o.fsf@evledraar.gmail.com>
>> (https://public-inbox.org/git/87d11omi2o.fsf@evledraar.gmail.com/)
>
> I have. But since you wrote "I haven't found... yet", I assumed you
> were still on it. You didn't give me much info to follow anyway.

Haven't had time to dig further, sorry, and won't be able to share the
repository. Is there some UC inspection command that can be run on the
relevant path / other thing that'll be indicative of what went wrong?

>> As noted there I think it's best to proceed without the "dir.c: stop
>> ignoring opendir[...]" patch.
>>
>> It's going to be a bad regression in 2.17 if it ends up spewing pagefuls
>> of warnings in previously working repos if the UC is on.
>
> "previously working" is a strong word when opendir() starts to
> complain. Sure we can suppress/ignore the error messages but I don't
> think it's a healthy attitude. Unreported bugs can't be fixed.

I mean that for the user it returned the right "git status" info and
didn't print errors, but yeah, the index may have been in some
internally funny state.

> We could perhaps stop reporting after we have printed like ... 5 lines
> or so? That keeps the noise level down a bit and probably still give
> enough indicator to at least repair the cache.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: What's cooking in git.git (Jan 2018, #04; Wed, 31)
  2018-02-11 14:44     ` Ævar Arnfjörð Bjarmason
@ 2018-02-12 10:04       ` Duy Nguyen
  0 siblings, 0 replies; 22+ messages in thread
From: Duy Nguyen @ 2018-02-12 10:04 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason; +Cc: Junio C Hamano, Git Mailing List

On Sun, Feb 11, 2018 at 9:44 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> On Sat, Feb 10 2018, Duy Nguyen jotted:
>
>> On Sat, Feb 10, 2018 at 1:37 AM, Ævar Arnfjörð Bjarmason
>> <avarab@gmail.com> wrote:
>>>
>>> On Thu, Feb 01 2018, Junio C. Hamano jotted:
>>>
>>>> * nd/fix-untracked-cache-invalidation (2018-01-24) 5 commits
>>>>  - dir.c: stop ignoring opendir() error in open_cached_dir()
>>>>  - update-index doc: note a fixed bug in the untracked cache
>>>>  - dir.c: fix missing dir invalidation in untracked code
>>>>  - dir.c: avoid stat() in valid_cached_dir()
>>>>  - status: add a failing test showing a core.untrackedCache bug
>>>>
>>>>  Some bugs around "untracked cache" feature have been fixed.
>>>>
>>>>  Will merge to 'next'.
>>>
>>> I think you / Nguyễn may not have seen my
>>> <87d11omi2o.fsf@evledraar.gmail.com>
>>> (https://public-inbox.org/git/87d11omi2o.fsf@evledraar.gmail.com/)
>>
>> I have. But since you wrote "I haven't found... yet", I assumed you
>> were still on it. You didn't give me much info to follow anyway.
>
> Haven't had time to dig further, sorry, and won't be able to share the
> repository. Is there some UC inspection command that can be run on the
> relevant path / other thing that'll be indicative of what went wrong?

There's test-dump-untracked-cache that will give you all the data.
From then on, you may need to dig in the code a bit to see how that
data should be processed.

There's no obfuscation support in that command, unfortunately, so you
can't just send me the dump. But if you could limit it to a few
"blocks" related to the error messages, then manual obfuscation should
not take that much time (either that or just add obfuscation in
test-dump-untracked-cache.c, it's probably easier task; or I can do
this for you)

>>> As noted there I think it's best to proceed without the "dir.c: stop
>>> ignoring opendir[...]" patch.
>>>
>>> It's going to be a bad regression in 2.17 if it ends up spewing pagefuls
>>> of warnings in previously working repos if the UC is on.
>>
>> "previously working" is a strong word when opendir() starts to
>> complain. Sure we can suppress/ignore the error messages but I don't
>> think it's a healthy attitude. Unreported bugs can't be fixed.
>
> I mean that for the user it returned the right "git status" info and
> didn't print errors, but yeah, the index may have been in some
> internally funny state.

One question (I wasn't clear from your previous mail). Does "git
status" always report the same errors when run multiple times, or does
it just report once, then next "git status" is silent? I suppose it's
the former case..
-- 
Duy

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, back to index

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-01  0:56 What's cooking in git.git (Jan 2018, #04; Wed, 31) Junio C Hamano
2018-02-01 11:05 ` Ævar Arnfjörð Bjarmason
2018-02-02 18:09   ` Junio C Hamano
2018-02-09 17:06   ` Johannes Schindelin
2018-02-09 18:30     ` Ævar Arnfjörð Bjarmason
2018-02-01 12:11 ` Ævar Arnfjörð Bjarmason
2018-02-02 18:05   ` Junio C Hamano
2018-02-02 19:29     ` Ævar Arnfjörð Bjarmason
2018-02-09 18:37 ` Ævar Arnfjörð Bjarmason
2018-02-09 18:54   ` Junio C Hamano
2018-02-09 21:04     ` [PATCH 0/2] update-index doc: note new caveats in 2.17 Ævar Arnfjörð Bjarmason
2018-02-09 21:40       ` Junio C Hamano
2018-02-09 22:10         ` Ævar Arnfjörð Bjarmason
2018-02-09 21:04     ` [PATCH 1/2] update-index doc: note a fixed bug in the untracked cache Ævar Arnfjörð Bjarmason
2018-02-09 21:52       ` Junio C Hamano
2018-02-09 22:14         ` Ævar Arnfjörð Bjarmason
2018-02-09 22:50           ` Junio C Hamano
2018-02-09 22:58             ` Ævar Arnfjörð Bjarmason
2018-02-09 21:04     ` [PATCH 2/2] update-index doc: note the caveat with "could not open..." Ævar Arnfjörð Bjarmason
2018-02-10 10:09   ` What's cooking in git.git (Jan 2018, #04; Wed, 31) Duy Nguyen
2018-02-11 14:44     ` Ævar Arnfjörð Bjarmason
2018-02-12 10:04       ` Duy Nguyen

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox