As discussed in the last commit partially fix a bug introduced in
b65abcafc7 ("grep: use PCRE v2 for optimized fixed-string search",
2019-07-01). Because PCRE v2, unlike kwset, validates its UTF-8 input
we'd die on e.g.:
fatal: pcre2_match failed with error code -22: UTF-8 error:
isolated byte with 0x80 bit set
When grepping a non-ASCII fixed string. This is a more general problem
that's hard to fix, but we can at least fix the most common case of
grepping for a fixed string without "-i". I can't think of a reason
for why we'd turn on PCRE2_UTF when matching byte-for-byte like that.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since my b65abcafc7 ("grep: use PCRE v2 for optimized fixed-string
search", 2019-07-01) we've been dying on invalid UTF-8 data when
grepping for fixed strings if the following are all true:
* The subject string is non-ASCII (e.g. "ævar")
* We're under a is_utf8_locale(), e.g. "en_US.UTF-8", not "C"
* We compiled with PCRE v2
* That PCRE v2 did not have JIT support
The last of those is why this wasn't caught earlier, per pcre2jit(3):
"unless PCRE2_NO_UTF_CHECK is set, a UTF subject string is tested
for validity. In the interests of speed, these checks do not
happen on the JIT fast path, and if invalid data is passed, the
result is undefined."
I.e. the subject being matched against our pattern was invalid, but we
were lucky and getting away with it on the JIT path, but the non-JIT
one is stricter.
This patch does nothing to fix that, instead we sneak in support for
fixed patterns starting with "(*NO_JIT)", this disables the PCRE v2
jit with implicit fixed-string matching for testing, see
pcre2syntax(3) the syntax.
This is technically a change in behavior, but it's so obscure that I
figured it was OK. We'd previously consider this an invalid regular
expression as regcomp() would die on it, now we feed it to the PCRE v2
fixed-string path. I thought this was better than introducing yet
another GIT_TEST_* environment variable.
We're also relying on a behavior of PCRE v2 that technically could
change, but I think the test coverage is worth dipping our toe into
some somewhat undefined behavior.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git fetch" into a lazy clone forgot to fetch base objects that are
necessary to complete delta in a thin packfile, which has been
corrected.
* jt/partial-clone-missing-ref-delta-base:
t5616: cover case of client having delta base
t5616: use correct flag to check object is missing
index-pack: prefetch missing REF_DELTA bases
t5616: refactor packfile replacement
When creating a partial clone, the object filtering criteria is
recorded for the origin of the clone, but this incorrectly used a
hardcoded name "origin" to name that remote; it has been corrected
to honor the "--origin <name>" option.
* xl/record-partial-clone-origin:
clone: respect user supplied origin name when setting up partial clone
"git request-pull" learned to warn when the ref we ask them to pull
from in the local repository and in the published repository are
different.
* pb/request-pull-verify-remote-ref:
request-pull: warn if the remote object is not the same as the local one
request-pull: quote regex metacharacters in local ref
"git merge --squash" is designed to update the working tree and the
index without creating the commit, and this cannot be countermanded
by adding the "--commit" option; the command now refuses to work
when both options are given.
* vv/merge-squash-with-explicit-commit:
merge: refuse --commit with --squash
"git bundle verify" needs to see if prerequisite objects exist in
the receiving repository, but the command did not check if we are
in a repository upfront, which has been corrected.
* js/bundle-verify-require-object-store:
bundle verify: error out if called without an object database
"git am -i --resolved" segfaulted after trying to see a commit as
if it were a tree, which has been corrected.
* jk/am-i-resolved-fix:
am: fix --interactive HEAD tree resolution
am: drop tty requirement for --interactive
am: read interactive input from stdin
am: simplify prompt response handling
The server side support for "git fetch" used to show incorrect
value for the HEAD symbolic ref when the namespace feature is in
use, which has been corrected.
* jk/HEAD-symref-in-xfer-namespaces:
upload-pack: strip namespace from symref data
"git update-server-info" used to leave stale packfiles in its
output, which has been corrected.
* ew/server-info-remove-crufts:
server-info: do not list unlinked packs
"git worktree add" used to fail when another worktree connected to
the same repository was corrupt, which has been corrected.
* nd/corrupt-worktrees:
worktree add: be tolerant of corrupt worktrees
A relative pathname given to "git init --template=<path> <repo>"
ought to be relative to the directory "git init" gets invoked in,
but it instead was made relative to the repository, which has been
corrected.
* nd/init-relative-template-fix:
init: make --template path relative to $CWD
A test helper has been introduced to optimize preparation of test
repositories with many simple commits, and a handful of test
scripts have been updated to use it.
* jk/test-commit-bulk:
t6200: use test_commit_bulk
t5703: use test_commit_bulk
t5702: use test_commit_bulk
t3311: use test_commit_bulk
t5310: increase the number of bitmapped commits
test-lib: introduce test_commit_bulk
"git rm" to resolve a conflicted path leaked an internal message
"needs merge" before actually removing the path, which was
confusing. This has been corrected.
* jc/denoise-rm-to-resolve:
rm: resolving by removal is not a warning-worthy event
"git clean" silently skipped a path when it cannot lstat() it; now
it gives a warning.
* js/clean-report-too-long-a-path:
clean: show an error message when the path is too long
"git stash --keep-index" did not work correctly on paths that have
been removed, which has been fixed.
* tg/stash-keep-index-with-removed-paths:
stash: fix handling removed files with --keep-index
Adjust the dir-iterator API and apply it to the local clone
optimization codepath.
* mt/dir-iterator-updates:
clone: replace strcmp by fspathcmp
clone: use dir-iterator to avoid explicit dir traversal
clone: extract function from copy_or_link_directory
clone: copy hidden paths at local clone
dir-iterator: add flags parameter to dir_iterator_begin
dir-iterator: refactor state machine model
dir-iterator: use warning_errno when possible
dir-iterator: add tests for dir-iterator API
clone: better handle symlinked files at .git/objects/
clone: test for our behavior on odd objects/* content
The "git log" command learns to issue a warning when log.mailmap
configuration is not set and --[no-]mailmap option is not used, to
prepare users for future versions of Git that uses the mailmap by
default.
* ac/log-use-mailmap-by-default-transition:
tests: defang pager tests by explicitly disabling the log.mailmap warning
documentation: mention --no-use-mailmap and log.mailmap false setting
log: add warning for unspecified log.mailmap setting
"git push --atomic" that goes over the transport-helper (namely,
the smart http transport) failed to prevent refs to be pushed when
it can locally tell that one of the ref update will fail without
having to consult the other end, which has been corrected.
* es/local-atomic-push-failure-with-http:
transport-helper: avoid var decl in for () loop control
transport-helper: enforce atomic in push_refs_with_push
"git range-diff" output has been tweaked for easier identification
of which part of what file the patch shown is about.
* tg/range-diff-output-update:
range-diff: add headers to the outer hunk header
range-diff: add filename to inner diff
range-diff: add section header instead of diff header
range-diff: suppress line count in outer diff
range-diff: don't remove funcname from inner diff
range-diff: split lines manually
range-diff: fix function parameter indentation
apply: make parse_git_diff_header public
apply: only pass required data to gitdiff_* functions
apply: only pass required data to find_name_*
apply: only pass required data to check_header_line
apply: only pass required data to git_header_name
apply: only pass required data to skip_tree_prefix
apply: replace marc.info link with public-inbox
Many GIT_TEST_* environment variables control various aspects of
how our tests are run, but a few followed "non-empty is true, empty
or unset is false" while others followed the usual "there are a few
ways to spell true, like yes, on, etc., and also ways to spell
false, like no, off, etc." convention.
* ab/test-env:
env--helper: mark a file-local symbol as static
tests: make GIT_TEST_FAIL_PREREQS a boolean
tests: replace test_tristate with "git env--helper"
tests README: re-flow a previously changed paragraph
tests: make GIT_TEST_GETTEXT_POISON a boolean
t6040 test: stop using global "script" variable
config.c: refactor die_bad_number() to not call gettext() early
env--helper: new undocumented builtin wrapping git_env_*()
config tests: simplify include cycle test
After finding a function line for --function-context in the pre-image,
xdl_emit_diff() calculates the equivalent line in the post-image. It
assumes that the lines between changes are the same on both sides. If
the option --ignore-blank-lines was also given then this is not
necessarily true.
Clamp the calculation results for start and end of the function context
to prevent out-of-bounds array accesses.
Note that this _just_ fixes the case where our mismatch sends us off the
beginning of the file. There are likely other cases where our assumption
causes us to go to the wrong line within the file. Nobody has developed
a test case yet, and the ultimate fix is likely more complicated than
this patch. But this at least prevents a segfault in the meantime.
Credit for finding the bug goes to "Liu Wei of Tencent Security Xuanwu
Lab".
Reported-by: 刘炜 <lw17qhdz@gmail.com>
Helped-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's a loop that creates 30 commits using test_commit. Using
test_commit_bulk speeds this up from:
Benchmark #1: ./t6200-fmt-merge-msg.sh --root=/var/ram/git-tests
Time (mean ± σ): 1.926 s ± 0.240 s [User: 1.055 s, System: 0.963 s]
Range (min … max): 1.431 s … 2.166 s 10 runs
to:
Benchmark #1: ./t6200-fmt-merge-msg.sh --root=/var/ram/git-tests
Time (mean ± σ): 1.343 s ± 0.179 s [User: 766.5 ms, System: 662.9 ms]
Range (min … max): 1.032 s … 1.664 s 10 runs
for an average savings of over 30%.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When one step in multi step cherry-pick or revert is reset or
committed, the command line prompt script failed to notice the
current status, which has been improved.
* pw/prompt-cherry-pick-revert-fix:
git-prompt: improve cherry-pick/revert detection
Generation of pack bitmaps are now disabled when .keep files exist,
as these are mutually exclusive features.
* ew/repack-with-bitmaps-by-default:
repack: disable bitmaps-by-default if .keep files exist
The tips of refs from the alternate object store can be used as
starting point for reachability computation now.
* jk/check-connected-with-alternates:
check_everything_connected: assume alternate ref tips are valid
object-store.h: move for_each_alternate_ref() from transport.h
The tree-walk API learned to pass an in-core repository
instance throughout more codepaths.
* nd/tree-walk-with-repo:
t7814: do not generate same commits in different repos
Use the right 'struct repository' instead of the_repository
match-trees.c: remove the_repo from shift_tree*()
tree-walk.c: remove the_repo from get_tree_entry_follow_symlinks()
tree-walk.c: remove the_repo from get_tree_entry()
tree-walk.c: remove the_repo from fill_tree_descriptor()
sha1-file.c: remove the_repo from read_object_with_reference()
"git cherry-pick/revert" learned a new "--skip" action.
* ra/cherry-pick-revert-skip:
cherry-pick/revert: advise using --skip
cherry-pick/revert: add --skip option
sequencer: use argv_array in reset_merge
sequencer: rename reset_for_rollback to reset_merge
sequencer: add advice for revert
The code to read state files used by the sequencer machinery for
"git status" has been made more robust against a corrupt or stale
state files.
* pw/status-with-corrupt-sequencer-state:
status: do not report errors in sequencer/todo
sequencer: factor out todo command name parsing
sequencer: always allow tab after command name
The commits in a repository can be described by multiple
commit-graph files now, which allows the commit-graph files to be
updated incrementally.
* ds/commit-graph-incremental:
commit-graph: test verify across alternates
commit-graph: normalize commit-graph filenames
commit-graph: test --split across alternate without --split
commit-graph: test octopus merges with --split
commit-graph: clean up chains after flattened write
commit-graph: verify chains with --shallow mode
commit-graph: create options for split files
commit-graph: expire commit-graph files
commit-graph: allow cross-alternate chains
commit-graph: merge commit-graph chains
commit-graph: add --split option to builtin
commit-graph: write commit-graph chains
commit-graph: rearrange chunk count logic
commit-graph: add base graphs chunk
commit-graph: load commit-graph chains
commit-graph: rename commit_compare to oid_compare
commit-graph: prepare for commit-graph chains
commit-graph: document commit-graph chains
"git blame" learned to "ignore" commits in the history, whose
effects (as well as their presence) get ignored.
* br/blame-ignore:
t8014: remove unnecessary braces
blame: drop some unused function parameters
blame: add a test to cover blame_coalesce()
blame: use the fingerprint heuristic to match ignored lines
blame: add a fingerprint heuristic to match ignored lines
blame: optionally track line fingerprints during fill_blame_origin()
blame: add config options for the output of ignored or unblamable lines
blame: add the ability to ignore commits and their changes
blame: use a helper function in blame_chunk()
Move oidset_parse_file() to oidset.c
fsck: rename and touch up init_skiplist()
Extend the test coverage a bit.
* cc/test-oidmap:
t0016: add 'remove' subcommand test
test-oidmap: remove 'add' subcommand
test-hashmap: remove 'hash' command
oidmap: use sha1hash() instead of static hash() function
t: add t0016-oidmap.sh
t/helper: add test-oidmap.c
"git multi-pack-index" learned expire and repack subcommands.
* ds/midx-expire-repack:
t5319: use 'test-tool path-utils' instead of 'ls -l'
t5319-multi-pack-index.sh: test batch size zero
midx: add test that 'expire' respects .keep files
multi-pack-index: test expire while adding packs
midx: implement midx_repack()
multi-pack-index: prepare 'repack' subcommand
multi-pack-index: implement 'expire' subcommand
midx: refactor permutation logic and pack sorting
midx: simplify computation of pack name lengths
multi-pack-index: prepare for 'expire' subcommand
Docs: rearrange subcommands for multi-pack-index
repack: refactor pack deletion for future use
When `lstat()` failed, `git clean` would abort without an error
message, leaving the user quite puzzled.
In particular on Windows, where the default maximum path length is
quite small (yet there are ways to circumvent that limit in many
cases), it is very important that users be given an indication why
their command failed because of too long paths when it did.
This test case makes sure that a warning is issued that would have
helped the user who reported this issue:
https://github.com/git-for-windows/git/issues/521
Note that we temporarily set `core.longpaths = false` in the regression
test; this ensures forward-compatibility with the `core.longpaths`
feature that has not yet been upstreamed from Git for Windows.
Helped-by: René Scharfe <l.s.r@web.de>
Helped-by: SZEDER Gábor <szeder.dev@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When resolving a conflict on a path in favor of removing it, using
"git rm" on it is the standard way to do so. The user however is
greeted with a "needs merge" message during that operation:
$ git merge side-branch
$ edit conflicted-path-1
$ git add conflicted-path-1
$ git rm conflicted-path-2
conflicted-path-2: needs merge
rm 'conflicted-path-2'
The removal by "git rm" does get performed, but an uninitiated user
may find it confusing, "needs merge? so I need to resolve conflict
before being able to remove it???"
The message is coming from "update-index --refresh" that is called
internally to make sure "git rm" knows which paths are clean and
which paths are dirty, in order to prevent removal of paths modified
relative to the index without the "-f" option. We somehow ended up
not squelching this message which seeped through to the UI surface.
Use the same mechanism used by "git commit", "git describe", etc. to
squelch the message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git stash push --keep-index is supposed to keep all changes that have
been added to the index, both in the index and on disk.
Currently this doesn't behave correctly when a file is removed from
the index. Instead of keeping it deleted on disk, --keep-index
currently restores the file.
Fix that behaviour by using 'git checkout' in no-overlay mode which
can faithfully restore the index and working tree. This also
simplifies the code.
Note that this will overwrite untracked files if the untracked file
has the same name as a file that has been deleted in the index.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On some older Windows versions (e.g. Windows 7), the CreateProcessW()
function does not really support spaces in its first argument,
lpApplicationName. But it supports passing NULL as lpApplicationName,
which makes it figure out the application from the (possibly quoted)
first argument of lpCommandLine.
Let's use that trick (if we are certain that the first argument matches
the executable's path) to support launching programs whose path contains
spaces.
We will abuse the test-fake-ssh.exe helper to verify that this works and
does not regress.
This fixes https://github.com/git-for-windows/git/issues/692
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the previous patch, we added a deprecation warning for the current
log.mailmap setting. This warning only appears when git is attached to
a controlling terminal. Some tests however run under an emulated
terminal, so we need to disable the warning for those tests.
Thanks to Junio for suggesting that we do this in the setup function.
Signed-off-by: Ariadne Conill <ariadne@dereferenced.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach transport-helper how to notice if skipping a ref during push would
violate atomicity on the client side. We notice that a ref would be
rejected, and choose not to send it, but don't notice that if the client
has asked for --atomic we are violating atomicity if all the other
pushes we are sending would succeed. Asking the server end to uphold
atomicity wouldn't work here as the server doesn't have any idea that we
tried to update a ref that's broken.
The added test-case is a succinct way to reproduce this issue that fails
today. The same steps work fine when we aren't using a transport-helper
to get to the upstream, i.e. when we've added a local repository as a
remote:
git remote add ~/upstream upstream
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configuration variable rebase.rescheduleFailedExec should be
effective only while running an interactive rebase and should not
affect anything when running an non-interactive one, which was not
the case. This has been corrected.
* js/rebase-reschedule-applies-only-to-interactive:
rebase --am: ignore rebase.rescheduleFailedExec
