summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-02-14Merge branch 'kw/fsmonitor-watchman-racefix'Libravatar Junio C Hamano6-5/+202
A new version of fsmonitor-watchman hook has been introduced, to avoid races. * kw/fsmonitor-watchman-racefix: fsmonitor: update documentation for hook version and watchman hooks fsmonitor: add fsmonitor hook scripts for version 2 fsmonitor: handle version 2 of the hooks that will use opaque token fsmonitor: change last update timestamp on the index_state to opaque token
2020-02-14Merge branch 'jn/promote-proto2-to-default'Libravatar Junio C Hamano12-34/+45
The transport protocol version 2 becomes the default one. * jn/promote-proto2-to-default: fetch: default to protocol version 2 protocol test: let protocol.version override GIT_TEST_PROTOCOL_VERSION test: request GIT_TEST_PROTOCOL_VERSION=0 when appropriate config doc: protocol.version is not experimental fetch test: use more robust test for filtered objects
2020-02-14Merge branch 'hw/advice-add-nothing'Libravatar Junio C Hamano2-2/+6
Two help messages given when "git add" notices the user gave it nothing to add have been updated to use advise() API. * hw/advice-add-nothing: add: change advice config variables used by the add API add: use advise function to display hints
2020-02-12Merge branch 'jb/parse-options-message-fix'Libravatar Junio C Hamano1-2/+2
Error message fix. * jb/parse-options-message-fix: parse-options: lose an unnecessary space in an error message
2020-02-12Merge branch 'pb/do-not-recurse-grep-no-index'Libravatar Junio C Hamano1-1/+10
"git grep --no-index" should not get affected by the contents of the .gitmodules file but when "--recurse-submodules" is given or the "submodule.recurse" variable is set, it did. Now these settings are ignored in the "--no-index" mode. * pb/do-not-recurse-grep-no-index: grep: ignore --recurse-submodules if --no-index is given
2020-02-12Merge branch 'dt/submodule-rm-with-stale-cache'Libravatar Junio C Hamano1-0/+7
Running "git rm" on a submodule failed unnecessarily when .gitmodules is only cache-dirty, which has been corrected. * dt/submodule-rm-with-stale-cache: git rm submodule: succeed if .gitmodules index stat info is zero
2020-02-12Merge branch 'jt/t5616-robustify'Libravatar Junio C Hamano1-13/+23
Futureproofing a test not to depend on the current implementation detail. * jt/t5616-robustify: t5616: make robust to delta base change
2020-02-12Merge branch 'jk/escaped-wildcard-dwim'Libravatar Junio C Hamano1-0/+14
Disambiguation logic to tell revisions and pathspec apart has been tweaked so that backslash-escaped glob special characters do not count in the "wildcards are pathspec" rule. * jk/escaped-wildcard-dwim: verify_filename(): handle backslashes in "wildcards are pathspecs" rule
2020-02-06add: change advice config variables used by the add APILibravatar Heba Waly1-0/+2
advice.addNothing config variable is used to control the visibility of two advice messages in the add library. This config variable is replaced by two new variables, whose names are more clear and relevant to the two cases. Also add the two new variables to the documentation. Signed-off-by: Heba Waly <heba.waly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-05Merge branch 'pb/recurse-submodule-in-worktree-fix'Libravatar Junio C Hamano2-77/+90
The "--recurse-submodules" option of various subcommands did not work well when run in an alternate worktree, which has been corrected. * pb/recurse-submodule-in-worktree-fix: submodule.c: use get_git_dir() instead of get_git_common_dir() t2405: clarify test descriptions and simplify test t2405: use git -C and test_commit -C instead of subshells t7410: rename to t2405-worktree-submodule.sh
2020-02-05Merge branch 'en/fill-directory-fixes-more'Libravatar Junio C Hamano1-0/+9
Corner case bugs in "git clean" that stems from a (necessarily for performance reasons) awkward calling convention in the directory enumeration API has been corrected. * en/fill-directory-fixes-more: dir: point treat_leading_path() warning to the right place dir: restructure in a way to avoid passing around a struct dirent dir: treat_leading_path() and read_directory_recursive(), round 2 clean: demonstrate a bug with pathspecs
2020-02-05Merge branch 'bc/hash-independent-tests-part-7'Libravatar Junio C Hamano19-219/+254
Preparation of test scripts for the day when the object names will use SHA-256 continues. * bc/hash-independent-tests-part-7: t5604: make hash independent t5601: switch into repository to hash object t5562: use $ZERO_OID t5540: make hash size independent t5537: make hash size independent t5530: compute results based on object length t5512: abstract away SHA-1-specific constants t5510: make hash size independent t5504: make hash algorithm independent t5324: make hash size independent t5319: make test work with SHA-256 t5319: change invalid offset for SHA-256 compatibility t5318: update for SHA-256 t4300: abstract away SHA-1-specific constants t4204: make hash size independent t4202: abstract away SHA-1-specific constants t4200: make hash size independent t4134: compute appropriate length constant t4066: compute index line in diffs t4054: make hash-size independent
2020-02-05Merge branch 'km/submodule-add-errmsg'Libravatar Junio C Hamano1-2/+13
Improve error message generation for "git submodule add". * km/submodule-add-errmsg: submodule add: show 'add --dry-run' stderr when aborting
2020-02-05Merge branch 'am/checkout-file-and-ref-ref-ambiguity'Libravatar Junio C Hamano1-2/+26
"git checkout X" did not correctly fail when X is not a local branch but could name more than one remote-tracking branches (i.e. to be dwimmed as the starting point to create a corresponding local branch), which has been corrected. * am/checkout-file-and-ref-ref-ambiguity: checkout: don't revert file on ambiguous tracking branches parse_branchname_arg(): extract part as new function
2020-02-05Merge branch 'js/add-p-leftover-bits'Libravatar Junio C Hamano1-1/+1
The final leg of rewriting "add -i/-p" in C. * js/add-p-leftover-bits: ci: include the built-in `git add -i` in the `linux-gcc` job built-in add -p: handle Escape sequences more efficiently built-in add -p: handle Escape sequences in interactive.singlekey mode built-in add -p: respect the `interactive.singlekey` config setting terminal: add a new function to read a single keystroke terminal: accommodate Git for Windows' default terminal terminal: make the code of disable_echo() reusable built-in add -p: handle diff.algorithm built-in add -p: support interactive.diffFilter t3701: adjust difffilter test
2020-02-05Merge branch 'dl/test-must-fail-fixes'Libravatar Junio C Hamano9-101/+112
Test clean-up. * dl/test-must-fail-fixes: t1507: inline full_name() t1507: run commands within test_expect_success t1507: stop losing return codes of git commands t1501: remove use of `test_might_fail cp` t1409: use test_path_is_missing() t1409: let sed open its own input file t1307: reorder `nongit test_must_fail` t1306: convert `test_might_fail rm` to `rm -f` t0020: use ! check_packed_refs_marked t0020: don't use `test_must_fail has_cr` t0003: don't use `test_must_fail attr_check` t0003: use test_must_be_empty() t0003: use named parameters in attr_check() t0000: replace test_must_fail with run_sub_test_lib_test_err() t/lib-git-p4: use test_path_is_missing()
2020-02-05parse-options: lose an unnecessary space in an error messageLibravatar Jacques Bodin-Hullin1-2/+2
Signed-off-by: Jacques Bodin-Hullin <j.bodinhullin@monsieurbiz.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-30Merge branch 'ss/t6025-modernize'Libravatar Junio C Hamano1-47/+48
Test style updates. * ss/t6025-modernize: t6025: use helpers to replace test -f <path> t6025: modernize style
2020-01-30Merge branch 'ds/refmap-doc'Libravatar Junio C Hamano1-0/+24
"git fetch --refmap=" option has got a better documentation. * ds/refmap-doc: fetch: document and test --refmap=""
2020-01-30Merge branch 'js/builtin-add-i-cmds'Libravatar Junio C Hamano1-0/+9
Minor bugfixes to "git add -i" that has recently been rewritten in C. * js/builtin-add-i-cmds: built-in add -i: accept open-ended ranges again built-in add -i: do not try to `patch`/`diff` an empty list of files
2020-01-30Merge branch 'jk/test-fixes'Libravatar Junio C Hamano2-4/+2
Test fixes. * jk/test-fixes: t7800: don't rely on reuse_worktree_file() t4018: drop "debugging" cat from hunk-header tests
2020-01-30Merge branch 'sg/completion-worktree'Libravatar Junio C Hamano1-0/+57
The command line completion (in contrib/) learned to complete subcommands and arguments to "git worktree". * sg/completion-worktree: completion: list paths and refs for 'git worktree add' completion: list existing working trees for 'git worktree' subcommands completion: simplify completing 'git worktree' subcommands and options completion: return the index of found word from __git_find_on_cmdline() completion: clean up the __git_find_on_cmdline() helper function t9902-completion: add tests for the __git_find_on_cmdline() helper
2020-01-30Merge branch 'jn/test-lint-one-shot-export-to-shell-function'Libravatar Junio C Hamano2-3/+17
The test-lint machinery knew to check "VAR=VAL shell_function" construct, but did not check "VAR= shell_funciton", which has been corrected. * jn/test-lint-one-shot-export-to-shell-function: fetch test: mark test of "skipping" haves as v0-only t/check-non-portable-shell: detect "FOO= shell_func", too fetch test: avoid use of "VAR= cmd" with a shell function
2020-01-30Merge branch 'hi/gpg-mintrustlevel'Libravatar Junio C Hamano4-0/+149
gpg.minTrustLevel configuration variable has been introduced to tell various signature verification codepaths the required minimum trust level. * hi/gpg-mintrustlevel: gpg-interface: add minTrustLevel as a configuration option
2020-01-30Merge branch 'am/test-pathspec-f-f-error-cases'Libravatar Junio C Hamano5-12/+105
More tests. * am/test-pathspec-f-f-error-cases: t: add tests for error conditions with --pathspec-from-file
2020-01-30Merge branch 'ds/graph-horizontal-edges'Libravatar Junio C Hamano1-0/+62
Rendering by "git log --graph" of ancestry lines leading to a merge commit were made suboptimal to waste vertical space a bit with a recent update, which has been corrected. * ds/graph-horizontal-edges: graph: fix collapse of multiple edges graph: add test to demonstrate horizontal line bug
2020-01-30Merge branch 'am/update-pathspec-f-f-tests'Libravatar Junio C Hamano9-11/+188
Test updates. * am/update-pathspec-f-f-tests: t: directly test parse_pathspec_file() t: fix quotes tests for --pathspec-from-file
2020-01-30grep: ignore --recurse-submodules if --no-index is givenLibravatar Philippe Blain1-1/+10
Since grep learned to recurse into submodules in 0281e487fd (grep: optionally recurse into submodules, 2016-12-16), using --recurse-submodules along with --no-index makes Git die(). This is unfortunate because if submodule.recurse is set in a user's ~/.gitconfig, invoking `git grep --no-index` either inside or outside a Git repository results in fatal: option not supported with --recurse-submodules Let's allow using these options together, so that setting submodule.recurse globally does not prevent using `git grep --no-index`. Using `--recurse-submodules` should not have any effect if `--no-index` is used inside a repository, as Git will recurse into the checked out submodule directories just like into regular directories. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-28git rm submodule: succeed if .gitmodules index stat info is zeroLibravatar David Turner1-0/+7
The bug was that ie_match_stat() was used to compare if the stat info for the file was compatible with the stat info in the index, rather using ie_modified() to check if the file was in fact different from the version in the index. A version of this (with deinit instead of rm) was reported here: https://lore.kernel.org/git/CAPOqYV+C-P9M2zcUBBkD2LALPm4K3sxSut+BjAkZ9T1AKLEr+A@mail.gmail.com/ It seems that in that case, the user's clone command left the index with empty stat info. The mailing list was unable to reproduce this. But we (Two Sigma) hit the bug while using some plumbing commands, so I'm fixing it. I manually confirmed that the fix also repairs deinit in this scenario. Signed-off-by: David Turner <dturner@twosigma.com> Reported-by: Thomas Bétous <th.betous@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-27t5616: make robust to delta base changeLibravatar Jonathan Tan1-13/+23
Commit 6462d5eb9a ("fetch: remove fetch_if_missing=0", 2019-11-08) contains a test that relies on having to lazily fetch the delta base of a blob, but assumes that the tree being fetched (as part of the test) is sent as a non-delta object. This assumption may not hold in the future; for example, a change in the length of the object hash might result in the tree being sent as a delta instead. Make the test more robust by relying on having to lazily fetch the delta base of the tree instead, and by making no assumptions on whether the blobs are sent as delta or non-delta. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-27verify_filename(): handle backslashes in "wildcards are pathspecs" ruleLibravatar Jeff King1-0/+14
Commit 28fcc0b71a (pathspec: avoid the need of "--" when wildcard is used, 2015-05-02) allowed: git rev-parse '*.c' without the double-dash. But the rule it uses to check for wildcards actually looks for any glob special. This is overly liberal, as it means that a pattern that doesn't actually do any wildcard matching, like "a\b", will be considered a pathspec. If you do have such a file on disk, that's presumably what you wanted. But if you don't, the results are confusing: rather than say "there's no such path a\b", we'll quietly accept it as a pathspec which very likely matches nothing (or at least not what you intended). Likewise, looking for path "a\*b" doesn't expand the search at all; it would only find a single entry, "a*b". This commit switches the rule to trigger only when glob metacharacters would expand the search, meaning both of those cases will now report an error (you can still disambiguate using "--", of course; we're just tightening the DWIM heuristic). Note that we didn't test the original feature in 28fcc0b71a at all. So this patch not only tests for these corner cases, but also adds a regression test for the existing behavior. Reported-by: David Burström <davidburstrom@spotify.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-23fsmonitor: add fsmonitor hook scripts for version 2Libravatar Kevin Willford2-0/+194
Version 2 of the fsmonitor hooks is passed the version and an update token and must pass back a last update token to use for subsequent calls to the hook. Signed-off-by: Kevin Willford <Kevin.Willford@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-22Merge branch 'nd/switch-and-restore'Libravatar Junio C Hamano1-0/+17
"git restore --staged" did not correctly update the cache-tree structure, resulting in bogus trees to be written afterwards, which has been corrected. * nd/switch-and-restore: restore: invalidate cache-tree when removing entries with --staged
2020-01-22Merge branch 'jk/no-flush-upon-disconnecting-slrpc-transport'Libravatar Junio C Hamano1-0/+12
Reduce unnecessary round-trip when running "ls-remote" over the stateless RPC mechanism. * jk/no-flush-upon-disconnecting-slrpc-transport: transport: don't flush when disconnecting stateless-rpc helper
2020-01-22Merge branch 'hw/commit-advise-while-rejecting'Libravatar Junio C Hamano1-0/+9
"git commit" gives output similar to "git status" when there is nothing to commit, but without honoring the advise.statusHints configuration variable, which has been corrected. * hw/commit-advise-while-rejecting: commit: honor advice.statusHints when rejecting an empty commit
2020-01-22submodule.c: use get_git_dir() instead of get_git_common_dir()Libravatar Philippe Blain1-0/+33
Ever since df56607dff (git-common-dir: make "modules/" per-working-directory directory, 2014-11-30), submodules in linked worktrees are cloned to $GIT_DIR/modules, i.e. $GIT_COMMON_DIR/worktrees/<name>/modules. However, this convention was not followed when the worktree updater commands checkout, reset and read-tree learned to recurse into submodules. Specifically, submodule.c::submodule_move_head, introduced in 6e3c1595c6 (update submodules: add submodule_move_head, 2017-03-14) and submodule.c::submodule_unset_core_worktree, (re)introduced in 898c2e65b7 (submodule: unset core.worktree if no working tree is present, 2018-12-14) use get_git_common_dir() instead of get_git_dir() to get the path of the submodule repository. This means that, for example, 'git checkout --recurse-submodules <branch>' in a linked worktree will correctly checkout <branch>, detach the submodule's HEAD at the commit recorded in <branch> and update the submodule working tree, but the submodule HEAD that will be moved is the one in $GIT_COMMON_DIR/modules/<name>/, i.e. the submodule repository of the main superproject working tree. It will also rewrite the gitfile in the submodule working tree of the linked worktree to point to $GIT_COMMON_DIR/modules/<name>/. This leads to an incorrect (and confusing!) state in the submodule working tree of the main superproject worktree. Additionally, if switching to a commit where the submodule is not present, submodule_unset_core_worktree will be called and will incorrectly remove 'core.wortree' from the config file of the submodule in the main superproject worktree, $GIT_COMMON_DIR/modules/<name>/config. Fix this by constructing the path to the submodule repository using get_git_dir() in both submodule_move_head and submodule_unset_core_worktree. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-22t2405: clarify test descriptions and simplify testLibravatar Philippe Blain1-20/+16
When 'checkout --to' functionality was moved to 'worktree add', tests were adapted in f194b1ef6e (tests: worktree: retrofit "checkout --to" tests for "worktree add", 2015-07-06). The calls were changed to 'worktree add' in this test (then t7410), but the test descriptions were not updated, keeping 'checkout' instead of using the new terminology (linked worktrees). Also, in the test each worktree is created in $TRASH_DIRECTORY/<leading-directory>/main, where the name of <leading-directory> carries some information about what behavior each test verifies. This directory structure is not mandatory for the tests; the worktrees can live next to one another in the trash directory. Clarify the tests by using the right terminology, and remove the unnecessary leading directories such that all superproject worktrees are directly next to one another in the trash directory. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-22t2405: use git -C and test_commit -C instead of subshellsLibravatar Philippe Blain1-25/+9
The subshells used in the setup phase of this test are unnecessary. Remove them by using 'git -C' and 'test_commit -C'. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-22t7410: rename to t2405-worktree-submodule.shLibravatar Philippe Blain1-1/+1
This test was added in df56607dff (git-common-dir: make "modules/" per-working-directory directory, 2014-11-30), back when the 'git worktree' command did not exist and 'git checkout --to' was used to create supplementary worktrees. Since this file contains tests for the interaction of 'git worktree' with submodules, rename it to t2405-worktree-submodule.sh, following the naming scheme for tests checking the behavior of various commands with submodules. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-21t6025: use helpers to replace test -f <path>Libravatar Shourya Shukla1-3/+3
Take advantage of helper function 'test_path_is_file()' to replace 'test -f' since the function makes the code more readable and gives better error messages. Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-21t6025: modernize styleLibravatar Shourya Shukla1-47/+48
The tests in `t6025-merge-symlinks.sh` were written a long time ago, and has a lot of style violations, including the mixed-use of tabs and spaces, missing indentations, and other shell script style violations. Update it to match the CodingGuidelines. Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-21fetch: document and test --refmap=""Libravatar Derrick Stolee1-0/+24
To prevent long blocking time during a 'git fetch' call, a user may want to set up a schedule for background 'git fetch' processes. However, these runs will update the refs/remotes branches due to the default refspec set in the config when Git adds a remote. Hence the user will not notice when remote refs are updated during their foreground fetches. In fact, they may _want_ those refs to stay put so they can work with the refs from their last foreground fetch call. This can be accomplished by overriding the configured refspec using '--refmap=' along with a custom refspec: git fetch --refmap='' <remote> +refs/heads/*:refs/hidden/<remote>/* to populate a custom ref space and download a pack of the new reachable objects. This kind of call allows a few things to happen: 1. We download a new pack if refs have updated. 2. Since the refs/hidden branches exist, GC will not remove the newly-downloaded data. 3. With fetch.writeCommitGraph enabled, the refs/hidden refs are used to update the commit-graph file. To avoid the refs/hidden directory from filling without bound, the --prune option can be included. When providing a refspec like this, the --prune option does not delete remote refs and instead only deletes refs in the target refspace. Update the documentation to clarify how '--refmap=""' works and create tests to guarantee this behavior remains in the future. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16t7800: don't rely on reuse_worktree_file()Libravatar Jeff King1-3/+2
A test in t7800 tries to make sure that when git-difftool runs an external tool that fails, it stops looking at files. Our fake failing tool prints the file name it was asked to diff before exiting non-zero, and then we confirm the output contains only that file. However, this subtly relies on our internal reuse_worktree_file(). Because we're diffing between branches, the command run by difftool might see: - the git-stored filename (e.g., "file"), if we decided that the working tree contents were up-to-date with the object in the index and HEAD, and we could reuse them - a temporary filename (e.g. "/tmp/abc123_file") if we had to dump the contents from the object database If the latter case happens, then the test fails, because it's expecting the string "file". I discovered this when debugging something unrelated with reuse_worktree_file(). I _thought_ it should be able to be triggered by a racy-git situation, but running: ./t7800-difftool.sh --stress --run=2,13 never seems to fail. However, by my reading of reuse_worktree_file(), this would probably always fail under Cygwin, because it sets NO_FAST_WORKING_DIRECTORY. At any rate, since reuse_worktree_file() is meant to be an optimization that may or may not trigger, our test should be robust either way. Instead of checking the filename, let's just make sure we got a single line of output (which would not be true if we continued after the first failure). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16t4018: drop "debugging" cat from hunk-header testsLibravatar Jeff King1-1/+0
We run a series of hunk-header tests in a loop, and each one does this: test_when_finished 'cat actual' && # for debugging only This is pretty pointless. When the test succeeds, we waste time running a useless cat process. If you're debugging a failure with "-i", then we won't run the when-finished part at all. So it helps only if you're running with something like "--verbose-log". Since we expect the tests to succeed most of the time, a better way to do this would be a helper that checks the output and dumps "actual" only when it fails. But it's probably not even worth the effort, as anyone debugging a failure could just run with "-i" and investigate the "actual" file themselves. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16built-in add -i: accept open-ended ranges againLibravatar Johannes Schindelin1-0/+9
The interactive `add` command allows selecting multiple files for some of its sub-commands, via unique prefixes, indices or index ranges. When re-implementing `git add -i` in C, we even added a code comment talking about ranges with a missing end index, such as `2-`, but the code did not actually accept those, as pointed out in https://github.com/git-for-windows/git/issues/2466#issuecomment-574142760. Let's fix this, and add a test case to verify that this stays fixed forever. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16dir: treat_leading_path() and read_directory_recursive(), round 2Libravatar Elijah Newren1-1/+1
I was going to title this "dir: more synchronizing of treat_leading_path() and read_directory_recursive()", a nod to commit 777b42034764 ("dir: synchronize treat_leading_path() and read_directory_recursive()", 2019-12-19), but the title was too long. Anyway, first the backstory... fill_directory() has always had a slightly error-prone interface: it returns a subset of paths which *might* match the specified pathspec; it was intended to prune away some paths which didn't match the specified pathspec and keep at least all the ones that did match it. Given this interface, callers were responsible to post-process the results and check whether each actually matched the pathspec. builtin/clean.c did this. It would first prune out duplicates (e.g. if "dir" was returned as well as all files under "dir/", then it would simplify this to just "dir"), and after pruning duplicates it would compare the remaining paths to the specified pathspec(s). This post-processing itself could run into problems, though, as noted in commit 404ebceda01c ("dir: also check directories for matching pathspecs", 2019-09-17): For the case of git-clean and a set of pathspecs of "dir/file" and "more", this caused a problem because we'd end up with dir entries for both of "dir" "dir/file" Then correct_untracked_entries() would try to helpfully prune duplicates for us by removing "dir/file" since it's under "dir", leaving us with "dir" Since the original pathspec only had "dir/file", the only entry left doesn't match and leaves nothing to be removed. (Note that if only one pathspec was specified, e.g. only "dir/file", then the common_prefix_len optimizations in fill_directory would cause us to bypass this problem, making it appear in simple tests that we could correctly remove manually specified pathspecs.) That commit fixed the issue -- when multiple pathspecs were specified -- by making sure fill_directory() wouldn't return both "dir" and "dir/file" outside the common_prefix_len optimization path. This is where it starts to get fun. In commit b9670c1f5e6b ("dir: fix checks on common prefix directory", 2019-12-19), we noticed that the common_prefix_len wasn't doing appropriate checks and letting all kinds of stuff through, resulting in recursing into .git/ directories and other craziness. So it started locking down and doing checks on pathnames within that code path. That continued with commit 777b42034764 ("dir: synchronize treat_leading_path() and read_directory_recursive()", 2019-12-19), which noted the following: Our optimization to avoid calling into read_directory_recursive() when all pathspecs have a common leading directory mean that we need to match the logic that read_directory_recursive() would use if we had just called it from the root. Since it does more than call treat_path() we need to copy that same logic. ...and then it more forcefully addressed the issue with this wonderfully ironic statement: Needing to duplicate logic like this means it is guaranteed someone will eventually need to make further changes and forget to update both locations. It is tempting to just nuke the leading_directory special casing to avoid such bugs and simplify the code, but unpack_trees' verify_clean_subdirectory() also calls read_directory() and does so with a non-empty leading path, so I'm hesitant to try to restructure further. Add obnoxious warnings to treat_leading_path() and read_directory_recursive() to try to warn people of such problems. You would think that with such a strongly worded description, that its author would have actually ensured that the logic in treat_leading_path() and read_directory_recursive() did actually match and that *everything* that was needed had at least been copied over at the time that this paragraph was written. But you'd be wrong, I messed it up by missing part of the logic. Copy the missing bits to fix the new final test in t7300. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16clean: demonstrate a bug with pathspecsLibravatar Derrick Stolee1-0/+9
b9670c1f5e (dir: fix checks on common prefix directory, 2019-12-19) modified the way pathspecs are handled when handling a directory during "git clean -f <path>". While this improved the behavior for known test breakages, it also regressed in how the clean command handles cleaning a specified file. Add a test case that demonstrates this behavior. This test passes before b9670c1f5e then fails after. Helped-by: Kevin Willford <Kevin.Willford@microsoft.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15t5604: make hash independentLibravatar brian m. carlson1-2/+3
To make our values hash independent, we turn the directory of the object into "Y" and the file name into "Z" after having sorted items by their name. However, when using SHA-256, one of our file names begins with an "a" character, which means it sorts into the wrong place in the list, causing the test to fail. Since we don't care about the order of these items, just sort them after stripping actual hash contents, which means they'll work with any hash algorithm. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15t5601: switch into repository to hash objectLibravatar brian m. carlson1-2/+2
This test performs a clone from outside any repository. Consequently, the hash algorithm used defaults to SHA-1. When the test is running with SHA-256, this results in an object ID that is not usable by the rest of the test. In order to ensure that we provide a usable value, switch into the source repository before hashing. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-15t5562: use $ZERO_OIDLibravatar brian m. carlson1-1/+1
This test uses $_z40 to express an all-zeros object ID, which doesn't work for SHA-256. Use $ZERO_OID instead, which is the right size for all hash values. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>