summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2022-02-04i18n: factorize "invalid value" messagesLibravatar Jean-Noël Avila1-1/+1
Use the same message when an invalid value is passed to a command line option or a configuration variable. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-02-04i18n: factorize more 'incompatible options' messagesLibravatar Jean-Noël Avila1-1/+1
Find more incompatible options to factorize. When more than two options are mutually exclusive, print the ones which are actually on the command line. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-26Merge branch 'en/keep-cwd'Libravatar Junio C Hamano1-0/+21
Fix a regression in 2.35 that roke the use of "rebase" and "stash" in a secondary worktree. * en/keep-cwd: sequencer, stash: fix running from worktree subdir
2022-01-26sequencer, stash: fix running from worktree subdirLibravatar Elijah Newren1-0/+21
In commits bc3ae46b42 ("rebase: do not attempt to remove startup_info->original_cwd", 2021-12-09) and 0fce211ccc ("stash: do not attempt to remove startup_info->original_cwd", 2021-12-09), we wanted to allow the subprocess to know which directory the parent process was running from, so that the subprocess could protect it. However... When run from a non-main worktree, setup_git_directory() will note that the discovered git directory (/PATH/TO/.git/worktree/non-main-worktree) does not match DEFAULT_GIT_DIR_ENVIRONMENT (see setup_discovered_git_dir()), and decide to set GIT_DIR in the environment. This matters because... Whenever git is run with the GIT_DIR environment variable set, and GIT_WORK_TREE not set, it presumes that '.' is the working tree. So... This combination results in the subcommand being very confused about the working tree. Fix it by also setting the GIT_WORK_TREE environment variable along with setting cmd.dir. A possibly more involved fix we could consider for later would be to make setup.c set GIT_WORK_TREE whenever (a) it discovers both the git directory and the working tree and (b) it decides to set GIT_DIR in the environment. I did not attempt that here as such would be too big of a change for a 2.35.1 release. Test-case-by: Glen Choo <chooglen@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-24Merge branch 'ab/checkout-branch-info-leakfix'Libravatar Junio C Hamano1-0/+13
We added an unrelated sanity checking that leads to a BUG() while plugging a leak, which triggered in a repository with symrefs in the local branch namespace that point at a ref outside. Partially revert the change to avoid triggering the BUG(). * ab/checkout-branch-info-leakfix: checkout: avoid BUG() when hitting a broken repository
2022-01-21checkout: avoid BUG() when hitting a broken repositoryLibravatar Junio C Hamano1-0/+13
When 9081a421 (checkout: fix "branch info" memory leaks, 2021-11-16) cleaned up existing memory leaks, we added an unrelated sanity check to ensure that a local branch is truly local and not a symref to elsewhere that dies with BUG() otherwise. This was misguided in two ways. First of all, such a tightening did not belong to a leak-fix patch. And the condition it detected was *not* a bug in our program but a problem in user data, where warning() or die() would have been more appropriate. As the condition is not fatal (the result of computing the local branch name in the code that is involved in the faulty check is only used as a textual label for the commit), let's revert the code to the original state, i.e. strip "refs/heads/" to compute the local branch name if possible, and otherwise leave it NULL. The consumer of the information in merge_working_tree() is prepared to see NULL in there and act accordingly. cf. https://bugzilla.redhat.com/show_bug.cgi?id=2042920 Reported-by: Petr Šplíchal <psplicha@redhat.com> Reported-by: Todd Zullinger <tmz@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-14Merge branch 'js/t1450-making-it-writable-does-not-need-full-posixperm'Libravatar Junio C Hamano1-2/+2
Test fix. * js/t1450-making-it-writable-does-not-need-full-posixperm: t1450-fsck: exec-bit is not needed to make loose object writable
2022-01-13t1450-fsck: exec-bit is not needed to make loose object writableLibravatar Johannes Sixt1-2/+2
A test case wants to append stuff to a loose object file to ensure that this kind of corruption is detected. To make a read-only loose object file writable with chmod, it is not necessary to also make it executable. Replace the bitmask 755 with the instruction +w to request only the write bit and to also heed the umask. And get rid of a POSIXPERM prerequisite, which is unnecessary for the test. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-12Merge branch 'fs/gpg-unknown-key-test-fix'Libravatar Junio C Hamano1-20/+2
Test simplification. * fs/gpg-unknown-key-test-fix: t/gpg: simplify test for unknown key
2022-01-12Merge branch 'ma/windows-dynload-fix'Libravatar Junio C Hamano1-1/+3
Fix calling dynamically loaded functions on Windows. * ma/windows-dynload-fix: lazyload: use correct calling conventions
2022-01-12Merge branch 'fs/ssh-signing-key-lifetime'Libravatar Junio C Hamano1-0/+8
"git merge $signed_tag" started to drop the tag message from the default merge message it uses by accident, which has been corrected. * fs/ssh-signing-key-lifetime: fmt-merge-msg: prevent use-after-free with signed tags
2022-01-12t/gpg: simplify test for unknown keyLibravatar Fabian Stelzer1-20/+2
To test for a key that is completely unknown to the keyring we need one to sign the commit with. This was done by generating a new key and not add it into the keyring. To avoid the key generation overhead and problems where GPG did hang in CI during it, switch GNUPGHOME to the empty $GNUPGHOME_NOT_USED instead, therefore making all used keys unknown for this single `verify-commit` call. Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Fabian Stelzer <fs@gigacodes.de> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10fmt-merge-msg: prevent use-after-free with signed tagsLibravatar Taylor Blau1-0/+8
When merging a signed tag, fmt_merge_msg_sigs() is responsible for populating the body of the merge message with the names of the signed tags, their signatures, and the validity of those signatures. In 02769437e1 (ssh signing: use sigc struct to pass payload, 2021-12-09), check_signature() was taught to pass the object payload via the sigc struct instead of passing the payload buffer separately. In effect, 02769437e1 causes buf, and sigc.payload to point at the same region in memory. This causes a problem for fmt_tag_signature(), which wants to read from this location, since it is freed beforehand by signature_check_clear() (which frees it via sigc's `payload` member). That makes the subsequent use in fmt_tag_signature() a use-after-free. As a result, merge messages did not contain the body of any signed tags. Luckily, they tend not to contain garbage, either, since the result of strstr()-ing the object buffer in fmt_tag_signature() is guarded: const char *tag_body = strstr(buf, "\n\n"); if (tag_body) { tag_body += 2; strbuf_add(tagbuf, tag_body, buf + len - tag_body); } Unfortunately, the tests in t6200 did not catch this at the time because they do not search for the body of signed tags in fmt-merge-msg's output. Resolve this by waiting to call signature_check_clear() until after its contents can be safely discarded. Harden ourselves against any future regressions in this area by making sure we can find signed tag messages in the output of fmt-merge-msg, too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-10Merge branch 'en/stash-df-fix'Libravatar Junio C Hamano1-0/+24
"git stash apply" forgot to attempt restoring untracked files when it failed to restore changes to tracked ones. * en/stash-df-fix: stash: do not return before restoring untracked files
2022-01-10Merge branch 'ms/t-readme-typofix'Libravatar Junio C Hamano1-1/+1
Typofix. * ms/t-readme-typofix: t/README: fix typo
2022-01-10Merge branch 'ja/i18n-similar-messages'Libravatar Junio C Hamano13-40/+41
Similar message templates have been consolidated so that translators need to work on fewer number of messages. * ja/i18n-similar-messages: i18n: turn even more messages into "cannot be used together" ones i18n: ref-filter: factorize "%(foo) atom used without %(bar) atom" i18n: factorize "--foo outside a repository" i18n: refactor "unrecognized %(foo) argument" strings i18n: factorize "no directory given for --foo" i18n: factorize "--foo requires --bar" and the like i18n: tag.c factorize i18n strings i18n: standardize "cannot open" and "cannot read" i18n: turn "options are incompatible" into "cannot be used together" i18n: refactor "%s, %s and %s are mutually exclusive" i18n: refactor "foo and bar are mutually exclusive"
2022-01-10Merge branch 'en/merge-ort-renorm-with-rename-delete-conflict-fix'Libravatar Junio C Hamano1-0/+26
A corner case bug in the ort merge strategy has been corrected. * en/merge-ort-renorm-with-rename-delete-conflict-fix: merge-ort: fix bug with renormalization and rename/delete conflicts
2022-01-10Merge branch 'js/branch-track-inherit'Libravatar Junio C Hamano5-4/+114
"git -c branch.autosetupmerge=inherit branch new old" makes "new" to have the same upstream as the "old" branch, instead of marking "old" itself as its upstream. * js/branch-track-inherit: config: require lowercase for branch.*.autosetupmerge branch: add flags and config to inherit tracking branch: accept multiple upstream branches for tracking
2022-01-10Merge branch 'jz/apply-3-corner-cases'Libravatar Junio C Hamano1-0/+18
"git apply --3way" bypasses the attempt to do a three-way application in more cases to address the regression caused by the recent change to use direct application as a fallback. * jz/apply-3-corner-cases: git-apply: skip threeway in add / rename cases
2022-01-10Merge branch 'ab/do-not-limit-stash-help-to-push'Libravatar Junio C Hamano1-0/+19
"git stash" by default triggers its "push" action, but its implementation also made "git stash -h" to show short help only for "git stash push", which has been corrected. * ab/do-not-limit-stash-help-to-push: stash: don't show "git stash push" usage on bad "git stash" usage
2022-01-10Merge branch 'ds/fetch-pull-with-sparse-index'Libravatar Junio C Hamano4-80/+149
"git fetch" and "git pull" are now declared sparse-index clean. Also "git ls-files" learns the "--sparse" option to help debugging. * ds/fetch-pull-with-sparse-index: test-read-cache: remove --table, --expand options t1091/t3705: remove 'test-tool read-cache --table' t1092: replace 'read-cache --table' with 'ls-files --sparse' ls-files: add --sparse option fetch/pull: use the sparse index
2022-01-10Merge branch 'hn/ref-api-tests-update'Libravatar Junio C Hamano3-11/+24
Test updates. * hn/ref-api-tests-update: t7004: use "test-tool ref-store" for reflog inspection t7004: create separate tags for different tests t5550: require REFFILES t5540: require REFFILES
2022-01-10Merge branch 'ja/perf-use-specified-shell'Libravatar Junio C Hamano1-1/+1
Perf tests were run with end-user's shell, but it has been corrected to use the shell specified by $TEST_SHELL_PATH. * ja/perf-use-specified-shell: t/perf: do not run tests in user's $SHELL
2022-01-10Merge branch 'hn/test-ref-store-show-hash-algo'Libravatar Junio C Hamano1-4/+5
Debugging support for refs API. * hn/test-ref-store-show-hash-algo: test-ref-store: print hash algorithm
2022-01-10Merge branch 'ws/fast-export-with-revision-options'Libravatar Junio C Hamano1-0/+32
Use of certain "git rev-list" options with "git fast-export" created nonsense results (the worst two of which being "--reverse" and "--invert-grep --grep=<foo>"). The use of "--first-parent" is made to behave a bit more sensible than before. * ws/fast-export-with-revision-options: fast-export: fix surprising behavior with --first-parent
2022-01-10Merge branch 'ds/sparse-checkout-malformed-pattern-fix'Libravatar Junio C Hamano1-1/+36
Certain sparse-checkout patterns that are valid in non-cone mode led to segfault in cone mode, which has been corrected. * ds/sparse-checkout-malformed-pattern-fix: sparse-checkout: refuse to add to bad patterns sparse-checkout: fix OOM error with mixed patterns sparse-checkout: fix segfault on malformed patterns
2022-01-09lazyload: use correct calling conventionsLibravatar Matthias Aßhauer1-1/+3
Christoph Reiter reported on the Git for Windows issue tracker[1], that mingw_strftime() imports strftime() from ucrtbase.dll with the wrong calling convention. It should be __cdecl instead of WINAPI, which we always use in DECLARE_PROC_ADDR(). The MSYS2 project encountered cmake sefaults on x86 Windows caused by the same issue in the cmake source. [2] There are no known git crashes that where caused by this, yet, but we should try to prevent them. We import two other non-WINAPI functions via DECLARE_PROC_ADDR(), too. * NtSetSystemInformation() (NTAPI) * GetUserNameExW() (SEC_ENTRY) NTAPI, SEC_ENTRY and WINAPI are all ususally defined as __stdcall, but there are circumstances where they're defined differently. Teach DECLARE_PROC_ADDR() about calling conventions and be explicit about when we want to use which calling convention. Import winnt.h for the definition of NTAPI and sspi.h for SEC_ENTRY near their respective only users. [1] https://github.com/git-for-windows/git/issues/3560 [2] https://github.com/msys2/MINGW-packages/issues/10152 Reported-By: Christoph Reiter <reiter.christoph@gmail.com> Signed-off-by: Matthias Aßhauer <mha1993@live.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05Merge branch 'rs/pcre2-utf'Libravatar Junio C Hamano1-0/+6
"git grep --perl-regexp" failed to match UTF-8 characters with wildcard when the pattern consists only of ASCII letters, which has been corrected. * rs/pcre2-utf: grep/pcre2: factor out literal variable grep/pcre2: use PCRE2_UTF even with ASCII patterns
2022-01-05Merge branch 'jc/t4204-do-not-write-git-on-upstream-of-pipe'Libravatar Junio C Hamano1-12/+17
Test fixes. * jc/t4204-do-not-write-git-on-upstream-of-pipe: t4204 is not sanitizer clean at all
2022-01-05Merge branch 'rs/log-invert-grep-with-headers'Libravatar Junio C Hamano1-0/+19
"git log --invert-grep --author=<name>" used to exclude commits written by the given author, but now "--invert-grep" only affects the matches made by the "--grep=<pattern>" option. * rs/log-invert-grep-with-headers: log: let --invert-grep only invert --grep
2022-01-05Merge branch 'rs/t4202-invert-grep-test-fix'Libravatar Junio C Hamano1-1/+1
Test fix. * rs/t4202-invert-grep-test-fix: t4202: fix patternType setting in --invert-grep test
2022-01-05Merge branch 'ds/repack-fixlets'Libravatar Junio C Hamano2-0/+47
Two fixes around "git repack". * ds/repack-fixlets: repack: make '--quiet' disable progress repack: respect kept objects with '--write-midx -b'
2022-01-05Merge branch 'jc/merge-detached-head-name'Libravatar Junio C Hamano1-1/+41
The default merge message prepared by "git merge" records the name of the current branch; the name can be overridden with a new option to allow users to pretend a merge is made on a different branch. * jc/merge-detached-head-name: merge: allow to pretend a merge is made into a different branch
2022-01-05Merge branch 'pw/diff-color-moved-fix'Libravatar Junio C Hamano2-11/+251
Correctness and performance update to "diff --color-moved" feature. * pw/diff-color-moved-fix: diff --color-moved: intern strings diff: use designated initializers for emitted_diff_symbol diff --color-moved-ws=allow-indentation-change: improve hash lookups diff --color-moved: stop clearing potential moved blocks diff --color-moved: shrink potential moved blocks as we go diff --color-moved: unify moved block growth functions diff --color-moved: call comparison function directly diff --color-moved-ws=allow-indentation-change: simplify and optimize diff: simplify allow-indentation-change delta calculation diff --color-moved: avoid false short line matches and bad zebra coloring diff --color-moved=zebra: fix alternate coloring diff --color-moved: rewind when discarding pmb diff --color-moved: factor out function diff --color-moved: clear all flags on blocks that are too short diff --color-moved: add perf tests
2022-01-05Merge branch 'xw/am-empty'Libravatar Junio C Hamano2-0/+108
"git am" learns "--empty=(stop|drop|keep)" option to tweak what is done to a piece of e-mail without a patch in it. * xw/am-empty: am: support --allow-empty to record specific empty patches am: support --empty=<option> to handle empty patches doc: git-format-patch: describe the option --always
2022-01-05Merge branch 'en/keep-cwd'Libravatar Junio C Hamano1-0/+277
Many git commands that deal with working tree files try to remove a directory that becomes empty (i.e. "git switch" from a branch that has the directory to another branch that does not would attempt remove all files in the directory and the directory itself). This drops users into an unfamiliar situation if the command was run in a subdirectory that becomes subject to removal due to the command. The commands have been taught to keep an empty directory if it is the directory they were started in to avoid surprising users. * en/keep-cwd: t2501: simplify the tests since we can now assume desired behavior dir: new flag to remove_dir_recurse() to spare the original_cwd dir: avoid incidentally removing the original_cwd in remove_path() stash: do not attempt to remove startup_info->original_cwd rebase: do not attempt to remove startup_info->original_cwd clean: do not attempt to remove startup_info->original_cwd symlinks: do not include startup_info->original_cwd in dir removal unpack-trees: add special cwd handling unpack-trees: refuse to remove startup_info->original_cwd setup: introduce startup_info->original_cwd t2501: add various tests for removing the current working directory
2022-01-05Merge branch 'jh/p4-rcs-expansion-in-bytestring'Libravatar Junio C Hamano1-0/+15
The RCS keyword substitution in "git p4" used to be done assuming that the contents are UTF-8 text, which can trigger decoding errors. We now treat the contents as a bytestring for robustness and correctness. * jh/p4-rcs-expansion-in-bytestring: git-p4: resolve RCS keywords in bytes not utf-8 git-p4: open temporary patch file for write only git-p4: add raw option to read_pipelines git-p4: pre-compile RCS keyword regexes git-p4: use with statements to close files after use in patchRCSKeywords
2022-01-05i18n: turn even more messages into "cannot be used together" onesLibravatar Jean-Noël Avila10-15/+16
Even if some of these messages are not subject to gettext i18n, this helps bring a single style of message for a given error type. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: factorize "--foo requires --bar" and the likeLibravatar Jean-Noël Avila7-7/+7
They are all replaced by "the option '%s' requires '%s'", which is a new string but replaces 17 previous unique strings. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: turn "options are incompatible" into "cannot be used together"Libravatar Jean-Noël Avila8-13/+13
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: refactor "%s, %s and %s are mutually exclusive"Libravatar Jean-Noël Avila1-3/+3
Use placeholders for constant tokens. The strings are turned into "cannot be used together" Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-05i18n: refactor "foo and bar are mutually exclusive"Libravatar Jean-Noël Avila2-2/+2
Use static strings for constant parts of the sentences. They are all turned into "cannot be used together". Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-04t/README: fix typoLibravatar Marc Strapetz1-1/+1
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-04stash: do not return before restoring untracked filesLibravatar Elijah Newren1-0/+24
In commit bee8691f19 ("stash: restore untracked files AFTER restoring tracked files", 2021-09-10), we correctly identified that we should restore changes to tracked files before attempting to restore untracked files, and accordingly moved the code for restoring untracked files a few lines down in do_apply_stash(). Unfortunately, the intervening lines had some early return statements meaning that we suddenly stopped restoring untracked files in some cases. Even before the previous commit, there was another possible issue with the current code -- a post-stash-apply 'git status' that was intended to be run after restoring the stash was skipped when we hit a conflict (or other error condition), which seems slightly inconsistent. Fix both issues by saving the return status, and letting other functionality run before returning. Reported-by: AJ Henderson Test-case-by: Randall S. Becker <randall.becker@nexbridge.ca> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-03Merge branch 'en/sparse-checkout-set'Libravatar Junio C Hamano1-1/+9
The "init" and "set" subcommands in "git sparse-checkout" have been unified for a better user experience and performance. * en/sparse-checkout-set: sparse-checkout: remove stray trailing space clone: avoid using deprecated `sparse-checkout init` Documentation: clarify/correct a few sparsity related statements git-sparse-checkout.txt: update to document init/set/reapply changes sparse-checkout: enable reapply to take --[no-]{cone,sparse-index} sparse-checkout: enable `set` to initialize sparse-checkout mode sparse-checkout: split out code for tweaking settings config sparse-checkout: disallow --no-stdin as an argument to set sparse-checkout: add sanity-checks on initial sparsity state sparse-checkout: break apart functions for sparse_checkout_(set|add) sparse-checkout: pass use_stdin as a parameter instead of as a global
2022-01-03Merge branch 'es/test-chain-lint'Libravatar Junio C Hamano161-845/+738
Broken &&-chains in the test scripts have been corrected. * es/test-chain-lint: t6000-t9999: detect and signal failure within loop t5000-t5999: detect and signal failure within loop t4000-t4999: detect and signal failure within loop t0000-t3999: detect and signal failure within loop tests: simplify by dropping unnecessary `for` loops tests: apply modern idiom for exiting loop upon failure tests: apply modern idiom for signaling test failure tests: fix broken &&-chains in `{...}` groups tests: fix broken &&-chains in `$(...)` command substitutions tests: fix broken &&-chains in compound statements tests: use test_write_lines() to generate line-oriented output tests: simplify construction of large blocks of text t9107: use shell parameter expansion to avoid breaking &&-chain t6300: make `%(raw:size) --shell` test more robust t5516: drop unnecessary subshell and command invocation t4202: clarify intent by creating expected content less cleverly t1020: avoid aborting entire test script when one test fails t1010: fix unnoticed failure on Windows t/lib-pager: use sane_unset() to avoid breaking &&-chain
2021-12-30sparse-checkout: refuse to add to bad patternsLibravatar Derrick Stolee1-2/+5
When in cone mode sparse-checkout, it is unclear how 'git sparse-checkout add <dir1> ...' should behave if the existing sparse-checkout file does not match the cone mode patterns. Change the behavior to fail with an error message about the existing patterns. Also, all cone mode patterns start with a '/' character, so add that restriction. This is necessary for our example test 'cone mode: warn on bad pattern', but also requires modifying the example sparse-checkout file we use to test the warnings related to recognizing cone mode patterns. This error checking would cause a failure further down the test script because of a test that adds non-cone mode patterns without cleaning them up. Perform that cleanup as part of the test now. Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-30sparse-checkout: fix OOM error with mixed patternsLibravatar Derrick Stolee1-0/+11
Add a test to t1091-sparse-checkout-builtin.sh that would result in an infinite loop and out-of-memory error before this change. The issue relies on having non-cone-mode patterns while trying to modify the patterns in cone-mode. The fix is simple, allowing us to break from the loop when the input path does not contain a slash, as the "dir" pattern we added does not. This is only a fix to the critical out-of-memory error. A better response to such a strange state will follow in a later change. Reported-by: Calbabreaker <calbabreaker@gmail.com> Helped-by: Taylor Blau <me@ttaylorr.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-30sparse-checkout: fix segfault on malformed patternsLibravatar Derrick Stolee1-0/+21
Then core.sparseCheckoutCone is enabled, the sparse-checkout patterns are used to populate two hashsets that accelerate pattern matching. If the user modifies the sparse-checkout file outside of the 'sparse-checkout' builtin, then strange patterns can happen, triggering some error checks. One of these error checks is possible to hit when some special characters exist in a line. A warning message is correctly written to stderr, but then there is additional logic that attempts to remove the line from the hashset and free the data. This leads to a segfault in the 'git sparse-checkout list' command because it iterates over the contents of the hashset, which is now invalid. The fix here is to stop trying to remove from the hashset. In addition, we disable cone mode sparse-checkout because of the malformed data. This results in the pattern-matching working with a possibly-slower algorithm, but using the patterns as they are in the sparse-checkout file. This also changes the behavior of commands such as 'git sparse-checkout list' because the output patterns will be the contents of the sparse-checkout file instead of the list of directories. This is an existing behavior for other types of bad patterns. Add a test that triggers the segfault without the code change. Reported-by: John Burnett <johnburnett@johnburnett.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-30merge-ort: fix bug with renormalization and rename/delete conflictsLibravatar Elijah Newren1-0/+26
Ever since commit a492d5331c ("merge-ort: ensure we consult df_conflict and path_conflicts", 2021-06-30), when renormalization is active AND a file is involved in a rename/delete conflict BUT the file is unmodified (either before or after renormalization), merge-ort was running into an assertion failure. Prior to that commit (or if assertions were compiled out), merge-ort would mis-merge instead, ignoring the rename/delete conflict and just deleting the file. Remove the assertions, fix the code appropriately, leave some good comments in the code, and add a testcase for this situation. Reported-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>