* What's cooking in git.git (Jun 2017, #09; Fri, 30)
@ 2017-06-30 21:51 Junio C Hamano
2017-07-01 7:39 ` Ævar Arnfjörð Bjarmason
2017-07-02 14:26 ` Philip Oakley
0 siblings, 2 replies; 11+ messages in thread
From: Junio C Hamano @ 2017-06-30 21:51 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.
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"]
* ab/die-errors-in-threaded (2017-06-21) 1 commit
(merged to 'next' on 2017-06-24 at 135fc4b963)
+ 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).
* ah/doc-pretty-color-auto-prefix (2017-06-24) 1 commit
(merged to 'next' on 2017-06-26 at d7489fc831)
+ doc: clarify syntax for %C(auto,...) in pretty formats
Doc update.
* jc/pack-bitmap-unaligned (2017-06-26) 1 commit
(merged to 'next' on 2017-06-28 at ad026b12a3)
+ pack-bitmap: don't perform unaligned memory access
An unaligned 32-bit access in pack-bitmap code ahs been corrected.
* ks/status-initial-commit (2017-06-21) 1 commit
(merged to 'next' on 2017-06-24 at 940ffd5816)
+ 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").
* ks/submodule-add-doc (2017-06-22) 1 commit
(merged to 'next' on 2017-06-24 at 26309b38f2)
+ Documentation/git-submodule: cleanup "add" section
Doc update.
* pw/rebase-i-regression-fix-tests (2017-06-23) 5 commits
(merged to 'next' on 2017-06-23 at 835ae762f5)
+ t3420: fix under GETTEXT_POISON build
(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.
* rs/apply-validate-input (2017-06-27) 3 commits
(merged to 'next' on 2017-06-28 at 81e006b50e)
+ apply: check git diffs for mutually exclusive header lines
+ apply: check git diffs for invalid file modes
+ apply: check git diffs for missing old filenames
Tighten error checks for invalid "git apply" input.
* vs/typofixes (2017-06-27) 1 commit
(merged to 'next' on 2017-06-28 at 3d11e0b3fa)
+ Spelling fixes
Many typofixes.
--------------------------------------------------
[New Topics]
* ab/grep-lose-opt-regflags (2017-06-30) 6 commits
- grep: remove redundant REG_NEWLINE when compiling fixed regex
- grep: remove regflags from the public grep_opt API
- grep: remove redundant and verbose re-assignments to 0
- grep: remove redundant "fixed" field re-assignment to 0
- grep: adjust a redundant grep pattern type assignment
- grep: remove redundant double assignment to 0
Code cleanup.
Will merge to 'next'.
* ks/commit-assuming-only-warning-removal (2017-06-30) 2 commits
- commit-template: distinguish status information unconditionally
- commit-template: remove outdated notice about explicit paths
An old message shown in the commit log template was removed, as it
has outlived its usefulness.
Will merge to 'next'.
* sb/hashmap-customize-comparison (2017-06-30) 3 commits
- hashmap: migrate documentation from Documentation/technical into header
- patch-ids.c: use hashmap correctly
- hashmap.h: compare function has access to a data field
(this branch is used by sb/diff-color-move.)
Update the hashmap API so that data to customize the behaviour of
the comparison function can be specified at the time a hashmap is
initialized. This fixes a bug in patch-ids that may have caused
segfault.
* sb/merge-recursive-code-cleanup (2017-06-30) 1 commit
- merge-recursive: use DIFF_XDL_SET macro
Code clean-up.
Will merge to 'next'.
--------------------------------------------------
[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>
* 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 a response.
cf. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@mail.gmail.com>
cf. <xmqqo9tfff2w.fsf@gitster.mtv.corp.google.com>
"""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."""
* 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.
Waiting for a response.
cf. <20170617112228.vugswym4o4owf6wj@sigill.intra.peff.net>
cf. <xmqqmv8zhdap.fsf@gitster.mtv.corp.google.com>
* 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>
--------------------------------------------------
[Cooking]
* ab/strbuf-addftime-tzname-boolify (2017-06-24) 3 commits
- REWORD ONLY SQUASH
- strbuf: change an always NULL/"" strbuf_addftime() param to bool
- strbuf.h comment: discuss strbuf_addftime() arguments in order
strbuf_addftime() is further getting tweaked.
Waiting for a response.
cf. <xmqqk2419rhg.fsf@gitster.mtv.corp.google.com>
* mt/p4-parse-G-output (2017-06-27) 1 commit
. git-p4: parse marshal output "p4 -G" in p4 changes
Use "p4 -G" to make "p4 changes" output more Python-friendly
to parse.
Needs review/ack from git-p4 folks.
* aw/contrib-subtree-doc-asciidoctor (2017-06-27) 1 commit
(merged to 'next' on 2017-06-30 at af23bd111b)
+ subtree: honour USE_ASCIIDOCTOR when set
The Makefile rule in contrib/subtree for building documentation
learned to honour USE_ASCIIDOCTOR just like the main documentation
set does.
Will merge to 'master'.
* js/fsck-name-object (2017-06-28) 1 commit
(merged to 'next' on 2017-06-30 at 9a08514cf2)
+ t1450: use egrep for regexp "alternation"
Test fix.
Will merge to 'master'.
* jc/utf8-fprintf (2017-06-28) 1 commit
(merged to 'next' on 2017-06-30 at a8cc490818)
+ submodule--helper: do not call utf8_fprintf() unnecessarily
Code cleanup.
Will merge to 'master'.
* rs/free-and-null (2017-06-29) 1 commit
- coccinelle: polish FREE_AND_NULL rules
Code cleanup.
* ab/wildmatch (2017-06-23) 1 commit
- wildmatch: remove unused wildopts parameter
Prepare the wildmatch API for future enhancements to allow a
pattern that is repeatedly matched against many strings to be
precompiled.
* cc/shared-index-permfix (2017-06-25) 3 commits
(merged to 'next' on 2017-06-26 at bb41584bf0)
+ t1700: make sure split-index respects core.sharedrepository
+ t1301: move modebits() to test-lib-functions.sh
+ read-cache: use shared perms when writing shared index
The split index code did not honor core.sharedrepository setting
correctly.
Will merge to 'master'.
* ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits
(merged to 'next' on 2017-06-26 at d026281517)
+ pathspec: die on empty strings as pathspec
+ t0027: do not use an empty string as a pathspec element
The final step to make an empty string as a pathspec element
illegal. We started this by first deprecating and warning a
pathspec that has such an element in 2.11 (Nov 2016).
Hopefully we can merge this down to the 'master' by the end of the
year? A deprecation warning period that is about 1 year does not
sound too bad.
Will cook in 'next'.
* sb/pull-rebase-submodule (2017-06-27) 4 commits
- builtin/fetch cleanup: always set default value for submodule recursing
- pull: optionally rebase submodules (remote submodule changes only)
- builtin/fetch: parse recurse-submodules-default at default options parsing
- builtin/fetch: factor submodule recurse parsing out to submodule config
"git pull --rebase --recurse-submodules" learns to rebase the
branch in the submodules to an updated base.
* bw/repo-object (2017-06-23) 21 commits
(merged to 'next' on 2017-06-26 at ed9c0b77c3)
+ 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 bw/repo-object
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.
Will merge to 'master'.
* pw/unquote-path-in-git-pm (2017-06-30) 4 commits
- t9700: add tests for Git::unquote_path()
- Git::unquote_path(): throw an exception on bad path
- Git::unquote_path(): handle '\a'
- add -i: move unquote_path() to Git.pm
Code refactoring.
Will merge to 'next'.
* rs/sha1-name-readdir-optim (2017-06-24) 4 commits
(merged to 'next' on 2017-06-26 at a70587f2b9)
+ sha1_file: guard against invalid loose subdirectory numbers
+ sha1_file: let for_each_file_in_obj_subdir() handle subdir names
+ p4205: add perf test script for pretty log formats
+ sha1_name: cache readdir(3) results in find_short_object_filename()
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.
Will merge to 'master'.
* jt/unify-object-info (2017-06-26) 8 commits
(merged to 'next' on 2017-06-26 at 540ea81983)
+ sha1_file: refactor has_sha1_file_with_flags
+ sha1_file: do not access pack if unneeded
+ sha1_file: teach sha1_object_info_extended more flags
+ 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.
Will merge to 'master'.
* mh/packed-ref-store (2017-06-23) 29 commits
- 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
- t1408: add a test of stale packed refs covered by loose refs
The "ref-store" code reorganization continues.
Is this now ready for 'next'?
* 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 mh/packed-ref-store and bw/config-h,
so perhaps needs to wait for the former to stabilize a bit more
and possibly rebasing on them.
* ls/filter-process-delayed (2017-06-30) 7 commits
- convert: add "status=delayed" to filter process protocol
- convert: refactor capabilities negotiation
- convert: move multiple file filter error handling to separate function
- convert: put the flags field before the flag itself for consistent style
- t0021: write "OUT <size>" 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.
Will merge to 'next'.
* ab/sha1dc (2017-06-27) 3 commits
- sha1collisiondetection: automatically enable when submodule is populated
- sha1dc: optionally use sha1collisiondetection as a submodule
- sha1dc: correct endian detection for Solaris (and others?)
The "collission-detecting" implementation of SHA-1 hash we borrowed
from is replaced by directly binding the upstream project as our
submodule. Glitches on minority platforms are still being worked out.
Will keep in 'pu'.
* 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".
No more comments or updates?
* sb/diff-color-move (2017-06-30) 26 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_{PLUS, MINUS}
- 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
- Merge branch 'sb/hashmap-customize-comparison' into sb/diff-color-move
(this branch uses sb/hashmap-customize-comparison.)
"git diff" has been taught to optionally paint new lines that are
the same as deleted lines elsewhere differently from genuinely new
lines.
Looking good.
cf. <CAGZ79kaK00CpXOtXnx_u7_KHbZq4Mz8vWHKy2a8p1gQ8ogE-OA@mail.gmail.com>
--------------------------------------------------
[Discarded]
* mh/packed-ref-store-prep-extra (2017-06-18) 1 commit
. prefix_ref_iterator_advance(): relax the check of trim length
Split out of mh/packed-ref-store-prep.
* 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.
* ab/free-and-null (2017-06-28) 2 commits
(merged to 'next' on 2017-06-28 at 1cf373c61a)
+ Revert "coccinelle: add a rule to make "expression" code use FREE_AND_NULL()"
(merged to 'next' on 2017-06-28 at 1785f88122)
+ coccinelle: add a rule to make "expression" code use FREE_AND_NULL()
The coccinelle rule for free-and-null refactoring got simplified.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-06-30 21:51 What's cooking in git.git (Jun 2017, #09; Fri, 30) Junio C Hamano
@ 2017-07-01 7:39 ` Ævar Arnfjörð Bjarmason
2017-07-01 12:59 ` Torsten Bögershausen
2017-07-05 16:22 ` Junio C Hamano
2017-07-02 14:26 ` Philip Oakley
1 sibling, 2 replies; 11+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2017-07-01 7:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, xiaoqiang zhao, Emily Xie
On Fri, Jun 30 2017, Junio C. Hamano jotted:
> * 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 a response.
> cf. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@mail.gmail.com>
> cf. <xmqqo9tfff2w.fsf@gitster.mtv.corp.google.com>
>
> """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."""
I think it's fine in lieu of xiaoqiang zhao not being responsive to just
merge this as-is. The info that can help us in the future is in the ML
archive, which should be good enough.
> * ab/strbuf-addftime-tzname-boolify (2017-06-24) 3 commits
> - REWORD ONLY SQUASH
> - strbuf: change an always NULL/"" strbuf_addftime() param to bool
> - strbuf.h comment: discuss strbuf_addftime() arguments in order
>
> strbuf_addftime() is further getting tweaked.
>
> Waiting for a response.
> cf. <xmqqk2419rhg.fsf@gitster.mtv.corp.google.com>
Meant to get to this after the last "What's Cooking", will submit
another version soon.
> * ab/wildmatch (2017-06-23) 1 commit
> - wildmatch: remove unused wildopts parameter
>
> Prepare the wildmatch API for future enhancements to allow a
> pattern that is repeatedly matched against many strings to be
> precompiled.
[...]
> * ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits
> (merged to 'next' on 2017-06-26 at d026281517)
> + pathspec: die on empty strings as pathspec
> + t0027: do not use an empty string as a pathspec element
>
> The final step to make an empty string as a pathspec element
> illegal. We started this by first deprecating and warning a
> pathspec that has such an element in 2.11 (Nov 2016).
>
> Hopefully we can merge this down to the 'master' by the end of the
> year? A deprecation warning period that is about 1 year does not
> sound too bad.
>
> Will cook in 'next'.
I have a longer patch series involving the "wildmatch: remove unused
wildopts parameter" patch (although not conflicting with it) which
assumes:
1. We'll merge down my "wildmatch: remove unused wildopts parameter" to
master (doesn't conflict with #3).
2. This ex/deprecate-empty-pathspec-as-match-all series will get in
3. My series, which among other things cleans up the wildmatch tests a
lot (and adds that new wildmatch pre-compile API that was ejected)
could be reviewed & merged down.
The reason I'm waiting on #3 is because one of the things I'm doing is
improving the wildmatch tests to not only test via calling raw
wildmatch(), but also roundtripping via git-ls-files, and this will
conflict in a very minor way with #2 (the test will need to be changed
from "this warns + works differently" -> "this dies + doesn't work").
But if #2 is something that's going to cook until the end of the year
I'm going to submit this sooner, and then we can just handle the minor
conflict. Is cooking it for that long really the plan?
Also, here's a minor RFC, as part of that series I need to create files
/ directories for each of the tests now in the wildmatch tests, this
involves creating files like "?a?b", "a[]b", "$" etc. I.e. this won't
work on all platforms.
So my WIP is, and I'd like feedback on the viability of the general approach:
create_test_file() {
file=$1
# `touch .` will succeed but obviously not do what we intend
# here.
test "$file" = "." && return 1
# We cannot create a file with an empty filename.
test "$file" = "" && return 1
# The tests that are testing that e.g. foo//bar is matched by
# foo/*/bar can't be tested on filesystems since there's no
# way we're getting a double slash.
echo "$file" | grep -F '//' && return 1
dirs=$(echo "$file" | sed -r 's!/[^/]+$!!')
# We touch "./$file" instead of "$file" because even an
# escaped "touch -- -" means something different.
if test "$file" != "$dirs"
then
mkdir -p -- "$dirs" 2>/dev/null &&
touch -- "./$file" 2>/dev/null &&
return 0
else
touch -- "./$file" 2>/dev/null &&
return 0
fi
return 1
}
And then later on for the tests I do:
# The existing test
test_expect_success "wildmatch: match '$text' '$pattern'" "
test-wildmatch wildmatch '$text' '$pattern'
"
# My new test
if create_test_file "$text"
then
test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
test_when_finished \"
rm -rf -- * &&
git reset
\" &&
git add -A &&
>expect.err &&
printf '%s' '$text' >expect &&
git --glob-pathspecs ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
test_cmp expect.err actual.err &&
test_cmp expect actual
"
else
test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
fi
This still needs to be cleaned up a bit to be parameterized (i.e. the
--glob-pathspecs argument, whether it should error etc.).
It works for me on Linux, but I'm wondering if others see any issues
with the approach, does simply trying to create bizarro filenames on
some OSs cause issues? I don't think so, but let's make sure.
Also this whole if/else with test_expect_success/test_expect_failure
pattern kind of sucks, I'm thinking of adding:
# Do the create_test_file() test to see if we can create the file then:
SKIP_TEST=<explanation if create_test_file() returned non-zero, empty string otherwise>
test_expect_success '...' '...'
I.e. to add a facility to test-lib.sh to be picked up by test_skip to
set a variable to skip individual tests with an explanation, currently
we have no non-hacky way to do this with the test-lib. I.e. the
equivalent of Test::More:
$ perl -MTest::More=no_plan -wE 'my $test = "Match bizarro glob on fs"; if (shift) { pass $test } else { SKIP: { skip $test } }' 0
ok 1 # skip Match bizarro glob on fs
1..1
$ perl -MTest::More=no_plan -wE 'my $test = "Match bizarro glob on fs"; if (shift) { pass $test } else { SKIP: { skip $test } }' 1
ok 1 - Match bizarro glob on fs
1..1
The "# skip" is magical and will be picked up as skip TAP.
We could also as a hack do:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 2306574dc9..0cea1711c2 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -398,7 +398,12 @@ trap 'exit $?' INT
test_ok_ () {
test_success=$(($test_success + 1))
- say_color "" "ok $test_count - $@"
+ if echo "$@" | grep -q '^# skip'
+ then
+ say_color "" "ok $test_count $@"
+ else
+ say_color "" "ok $test_count - $@"
+ fi
}
test_failure_ () {
This would avoid the caveats of setting a possible persistent shell
variable, but OTOH the code would become quite ugly, you'd need:
if <skip>
then
test_expect_success '# skip <reason>' 'true'
else
test_expect_success '<real test>' '<real code>'
fi
So I'm heavily leaning towards just adding a $SKIP_TEST variable of some
sort.
> * ab/sha1dc (2017-06-27) 3 commits
> - sha1collisiondetection: automatically enable when submodule is populated
> - sha1dc: optionally use sha1collisiondetection as a submodule
> - sha1dc: correct endian detection for Solaris (and others?)
>
> The "collission-detecting" implementation of SHA-1 hash we borrowed
> from is replaced by directly binding the upstream project as our
> submodule. Glitches on minority platforms are still being worked out.
>
> Will keep in 'pu'.
The status of this is that we've come to a consensus with upstream /
another reported about what to do about this issue in
https://github.com/cr-marcstevens/sha1collisiondetection/pull/34 but
pull request was a bit of a mess (multiple merges etc). I rebased &
cleaned that up this morning as
https://github.com/cr-marcstevens/sha1collisiondetection/pull/37
I'll wait for that to get into upstream before submitting a new round of
this.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-01 7:39 ` Ævar Arnfjörð Bjarmason
@ 2017-07-01 12:59 ` Torsten Bögershausen
2017-07-05 16:22 ` Junio C Hamano
1 sibling, 0 replies; 11+ messages in thread
From: Torsten Bögershausen @ 2017-07-01 12:59 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, Junio C Hamano
Cc: git, xiaoqiang zhao, Emily Xie
On 01/07/17 09:39, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Jun 30 2017, Junio C. Hamano jotted:
>
>> * 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 a response.
>> cf. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@mail.gmail.com>
>> cf. <xmqqo9tfff2w.fsf@gitster.mtv.corp.google.com>
>>
>> """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."""
>
> I think it's fine in lieu of xiaoqiang zhao not being responsive to just
> merge this as-is. The info that can help us in the future is in the ML
> archive, which should be good enough.
>
>> * ab/strbuf-addftime-tzname-boolify (2017-06-24) 3 commits
>> - REWORD ONLY SQUASH
>> - strbuf: change an always NULL/"" strbuf_addftime() param to bool
>> - strbuf.h comment: discuss strbuf_addftime() arguments in order
>>
>> strbuf_addftime() is further getting tweaked.
>>
>> Waiting for a response.
>> cf. <xmqqk2419rhg.fsf@gitster.mtv.corp.google.com>
>
> Meant to get to this after the last "What's Cooking", will submit
> another version soon.
>
>> * ab/wildmatch (2017-06-23) 1 commit
>> - wildmatch: remove unused wildopts parameter
>>
>> Prepare the wildmatch API for future enhancements to allow a
>> pattern that is repeatedly matched against many strings to be
>> precompiled.
>
> [...]
>
>> * ex/deprecate-empty-pathspec-as-match-all (2017-06-23) 2 commits
>> (merged to 'next' on 2017-06-26 at d026281517)
>> + pathspec: die on empty strings as pathspec
>> + t0027: do not use an empty string as a pathspec element
>>
>> The final step to make an empty string as a pathspec element
>> illegal. We started this by first deprecating and warning a
>> pathspec that has such an element in 2.11 (Nov 2016).
>>
>> Hopefully we can merge this down to the 'master' by the end of the
>> year? A deprecation warning period that is about 1 year does not
>> sound too bad.
>>
>> Will cook in 'next'.
>
> I have a longer patch series involving the "wildmatch: remove unused
> wildopts parameter" patch (although not conflicting with it) which
> assumes:
>
> 1. We'll merge down my "wildmatch: remove unused wildopts parameter" to
> master (doesn't conflict with #3).
>
> 2. This ex/deprecate-empty-pathspec-as-match-all series will get in
>
> 3. My series, which among other things cleans up the wildmatch tests a
> lot (and adds that new wildmatch pre-compile API that was ejected)
> could be reviewed & merged down.
>
> The reason I'm waiting on #3 is because one of the things I'm doing is
> improving the wildmatch tests to not only test via calling raw
> wildmatch(), but also roundtripping via git-ls-files, and this will
> conflict in a very minor way with #2 (the test will need to be changed
> from "this warns + works differently" -> "this dies + doesn't work").
>
> But if #2 is something that's going to cook until the end of the year
> I'm going to submit this sooner, and then we can just handle the minor
> conflict. Is cooking it for that long really the plan?
>
> Also, here's a minor RFC, as part of that series I need to create files
> / directories for each of the tests now in the wildmatch tests, this
> involves creating files like "?a?b", "a[]b", "$" etc. I.e. this won't
> work on all platforms.
>
> So my WIP is, and I'd like feedback on the viability of the general approach:
>
> create_test_file() {
> file=$1
>
> # `touch .` will succeed but obviously not do what we intend
> # here.
> test "$file" = "." && return 1
> # We cannot create a file with an empty filename.
> test "$file" = "" && return 1
> # The tests that are testing that e.g. foo//bar is matched by
> # foo/*/bar can't be tested on filesystems since there's no
> # way we're getting a double slash.
> echo "$file" | grep -F '//' && return 1
>
> dirs=$(echo "$file" | sed -r 's!/[^/]+$!!')
sed -r is a GNU extension, isn't it ?
http://pubs.opengroup.org/onlinepubs/7908799/xcu/sed.html
This may work:
sed -e 's!/[^/][^/]*$!!')
(The rest looks good - at first glance)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-06-30 21:51 What's cooking in git.git (Jun 2017, #09; Fri, 30) Junio C Hamano
2017-07-01 7:39 ` Ævar Arnfjörð Bjarmason
@ 2017-07-02 14:26 ` Philip Oakley
2017-07-03 18:20 ` Junio C Hamano
1 sibling, 1 reply; 11+ messages in thread
From: Philip Oakley @ 2017-07-02 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: "Junio C Hamano" <gitster@pobox.com>
> 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.
>
Junio,
Is it possible to include a table of contents that lists the integration
branches, split by your categories, to help find areas of interest?
[Graduated to "master"]
* topic list
[New Topics]
[Stalled]
[Cooking]
[Discarded]
The TOC wouldn't need the [] or * markings if that's a problem.
--
Philip
> 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"]
>
> * ab/die-errors-in-threaded (2017-06-21) 1 commit
<snip>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-02 14:26 ` Philip Oakley
@ 2017-07-03 18:20 ` Junio C Hamano
2017-07-03 19:13 ` Philip Oakley
0 siblings, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2017-07-03 18:20 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
"Philip Oakley" <philipoakley@iee.org> writes:
> Junio,
> Is it possible to include a table of contents that lists the
> integration branches, split by your categories, to help find areas of
> interest?
>
> [Graduated to "master"]
> * topic list
> [New Topics]
> [Stalled]
> [Cooking]
> [Discarded]
>
> The TOC wouldn't need the [] or * markings if that's a problem.
I am not sure what you are asking. Is this the command you are
looking for?
$ grep -e "^[[*]" whats-cooking.txt
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-03 18:20 ` Junio C Hamano
@ 2017-07-03 19:13 ` Philip Oakley
2017-07-03 20:19 ` Junio C Hamano
2017-07-04 6:02 ` Junio C Hamano
0 siblings, 2 replies; 11+ messages in thread
From: Philip Oakley @ 2017-07-03 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> Junio,
>> Is it possible to include a table of contents that lists the
>> integration branches, split by your categories, to help find areas of
>> interest?
>>
>> [Graduated to "master"]
>> * topic list
>> [New Topics]
>> [Stalled]
>> [Cooking]
>> [Discarded]
>>
>> The TOC wouldn't need the [] or * markings if that's a problem.
>
> I am not sure what you are asking. Is this the command you are
> looking for?
>
> $ grep -e "^[[*]" whats-cooking.txt
>
Ah, thanks.
It does presume that one has extracted the email to the text file, which is
easier on some systems and mail clients than others ;-)
Am I right that the What's cooking is prepared by a script?
--
Philip
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-03 19:13 ` Philip Oakley
@ 2017-07-03 20:19 ` Junio C Hamano
2017-07-05 7:30 ` Philip Oakley
2017-07-04 6:02 ` Junio C Hamano
1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2017-07-03 20:19 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
"Philip Oakley" <philipoakley@iee.org> writes:
> Am I right that the What's cooking is prepared by a script?
Because I have to keep track of so many topics, its maintenance is
heavily helped by a script. I do not think it is sensible to expect
me to (or it would be good use of my time) correctly update the list
of commits manually every time a topic is replaced with its new
version.
But I consider the use of the script just like my use of Emacs to
edit the final end result. Yes, I use tools to prepare it, and the
tools know certain rules that I prefer to apply to the document,
such as "a topic that has not been touched since the previous issue
by default does not need its description updated."
Does that answer your question?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-03 19:13 ` Philip Oakley
2017-07-03 20:19 ` Junio C Hamano
@ 2017-07-04 6:02 ` Junio C Hamano
2017-07-05 0:17 ` Stefan Beller
1 sibling, 1 reply; 11+ messages in thread
From: Junio C Hamano @ 2017-07-04 6:02 UTC (permalink / raw)
To: Philip Oakley; +Cc: git
"Philip Oakley" <philipoakley@iee.org> writes:
> From: "Junio C Hamano" <gitster@pobox.com>
>
>> I am not sure what you are asking. Is this the command you are
>> looking for?
>>
>> $ grep -e "^[[*]" whats-cooking.txt
>>
> Ah, thanks.
>
> It does presume that one has extracted the email to the text file,
> which is easier on some systems and mail clients than others ;-)
Perhaps you would want to find an e-mail client that can handle text
files better, then? ;-)
If you are cloning and following along my tree from one of these
places:
git://repo.or.cz/alt-git.git/
git://git.kernel.org/pub/scm/git/git.git/
git://github.com/git/git.git/
the 'todo' branch in these repositories keeps track of the
whats-cooking.txt report (among other things), so you can also:
$ git cat-file -p origin/todo:whats-cooking.txt |
grep -e "^[[*]"
to get the same effect.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-04 6:02 ` Junio C Hamano
@ 2017-07-05 0:17 ` Stefan Beller
0 siblings, 0 replies; 11+ messages in thread
From: Stefan Beller @ 2017-07-05 0:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Philip Oakley, git@vger.kernel.org
On Mon, Jul 3, 2017 at 11:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com>
>>
>>> I am not sure what you are asking. Is this the command you are
>>> looking for?
>>>
>>> $ grep -e "^[[*]" whats-cooking.txt
>>>
>> Ah, thanks.
>>
>> It does presume that one has extracted the email to the text file,
>> which is easier on some systems and mail clients than others ;-)
>
> Perhaps you would want to find an e-mail client that can handle text
> files better, then? ;-)
>
> If you are cloning and following along my tree from one of these
> places:
>
> git://repo.or.cz/alt-git.git/
> git://git.kernel.org/pub/scm/git/git.git/
> git://github.com/git/git.git/
>
> the 'todo' branch in these repositories keeps track of the
> whats-cooking.txt report (among other things), so you can also:
>
> $ git cat-file -p origin/todo:whats-cooking.txt |
> grep -e "^[[*]"
>
> to get the same effect.
>
FWIW:
I have a script in my git dir,
cat git/cookreport.sh
git -C Meta pull origin todo
Meta/cook -w
with Meta being a repo tracking one of the URLs above.
I might add a | grep -e "^[[*]" or add some scripting to verbose
report my own topics.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-03 20:19 ` Junio C Hamano
@ 2017-07-05 7:30 ` Philip Oakley
0 siblings, 0 replies; 11+ messages in thread
From: Philip Oakley @ 2017-07-05 7:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
From: "Junio C Hamano" <gitster@pobox.com>
Sent: Monday, July 03, 2017 9:19 PM
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> Am I right that the What's cooking is prepared by a script?
>
> Because I have to keep track of so many topics, its maintenance is
> heavily helped by a script. I do not think it is sensible to expect
> me to (or it would be good use of my time) correctly update the list
> of commits manually every time a topic is replaced with its new
> version.
>
Definately. I was hoping that a 'contents list' element (at the point of
sending the emails) could also be part of the automated scripting.
> But I consider the use of the script just like my use of Emacs to
> edit the final end result. Yes, I use tools to prepare it, and the
> tools know certain rules that I prefer to apply to the document,
> such as "a topic that has not been touched since the previous issue
> by default does not need its description updated."
>
> Does that answer your question?
>
I see the script's location is given in a follow up response. I'll see what
opportunities for a TOC there may be within the flow, though my local todo
list is getting a bit long with other personal matters.
--
Philip
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What's cooking in git.git (Jun 2017, #09; Fri, 30)
2017-07-01 7:39 ` Ævar Arnfjörð Bjarmason
2017-07-01 12:59 ` Torsten Bögershausen
@ 2017-07-05 16:22 ` Junio C Hamano
1 sibling, 0 replies; 11+ messages in thread
From: Junio C Hamano @ 2017-07-05 16:22 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: git, xiaoqiang zhao, Emily Xie
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> On Fri, Jun 30 2017, Junio C. Hamano jotted:
>
>> * 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 a response.
>> cf. <CACBZZX5GYV50rjg9X602JHqFPaoofH9TwDf_-r_MDu8-rmNV6Q@mail.gmail.com>
>> cf. <xmqqo9tfff2w.fsf@gitster.mtv.corp.google.com>
>>
>> """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."""
>
> I think it's fine in lieu of xiaoqiang zhao not being responsive to just
> merge this as-is. The info that can help us in the future is in the ML
> archive, which should be good enough.
OK. I'll amend to add a few lines of note to the commit log and
then merge it down.
> So my WIP is, and I'd like feedback on the viability of the general approach:
>
> create_test_file() {
> file=$1
>
> # `touch .` will succeed but obviously not do what we intend
> # here.
If you want to create, do not use "touch" that gives readers a false
and confusing impression that you care about the timestamp of the
thing being updated. If you say ">./$file", you can get an error from
the shell just fine, I think.
> test "$file" = "." && return 1
> # We cannot create a file with an empty filename.
> test "$file" = "" && return 1
Likewise, as that would become ">./".
> # The tests that are testing that e.g. foo//bar is matched by
> # foo/*/bar can't be tested on filesystems since there's no
> # way we're getting a double slash.
> echo "$file" | grep -F '//' && return 1
> dirs=$(echo "$file" | sed -r 's!/[^/]+$!!')
GNUism already pointed out, I think.
>
> # We touch "./$file" instead of "$file" because even an
> # escaped "touch -- -" means something different.
> if test "$file" != "$dirs"
> then
> mkdir -p -- "$dirs" 2>/dev/null &&
> touch -- "./$file" 2>/dev/null &&
> return 0
> else
> touch -- "./$file" 2>/dev/null &&
> return 0
> fi
> return 1
> }
>
> And then later on for the tests I do:
>
> # The existing test
> test_expect_success "wildmatch: match '$text' '$pattern'" "
> test-wildmatch wildmatch '$text' '$pattern'
> "
>
> # My new test
> if create_test_file "$text"
> then
> test_expect_success "wildmatch(ls): match '$pattern' '$text'" "
> test_when_finished \"
> rm -rf -- * &&
> git reset
> \" &&
> git add -A &&
> >expect.err &&
> printf '%s' '$text' >expect &&
> git --glob-pathspecs ls-files -z -- '$pattern' 2>actual.err | tr -d '\0' >actual &&
> test_cmp expect.err actual.err &&
> test_cmp expect actual
> "
> else
> test_expect_failure "wildmatch(ls): match skip '$pattern' '$text'" 'false'
> fi
>
> This still needs to be cleaned up a bit to be parameterized (i.e. the
> --glob-pathspecs argument, whether it should error etc.).
>
> It works for me on Linux, but I'm wondering if others see any issues
> with the approach, does simply trying to create bizarro filenames on
> some OSs cause issues? I don't think so, but let's make sure.
Issues meaning that the test wants to see how a pathname with ^I in
it works but create_test_file step would fail? Your above construct
covers that with the if/then/else test_expect_failure/fi just fine,
I think.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-07-05 16:22 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-30 21:51 What's cooking in git.git (Jun 2017, #09; Fri, 30) Junio C Hamano
2017-07-01 7:39 ` Ævar Arnfjörð Bjarmason
2017-07-01 12:59 ` Torsten Bögershausen
2017-07-05 16:22 ` Junio C Hamano
2017-07-02 14:26 ` Philip Oakley
2017-07-03 18:20 ` Junio C Hamano
2017-07-03 19:13 ` Philip Oakley
2017-07-03 20:19 ` Junio C Hamano
2017-07-05 7:30 ` Philip Oakley
2017-07-04 6:02 ` Junio C Hamano
2017-07-05 0:17 ` Stefan Beller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).