summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-05-29list-objects-filter: disable 'sparse:path' filtersLibravatar Christian Couder2-84/+26
If someone wants to use as a filter a sparse file that is in the repository, something like "--filter=sparse:oid=<ref>:<path>" already works. So 'sparse:path' is only interesting if the sparse file is not in the repository. In this case though the current implementation has a big security issue, as it makes it possible to ask the server to read any file, like for example /etc/password, and to explore the filesystem, as well as individual lines of files. If someone is interested in using a sparse file that is not in the repository as a filter, then at the minimum a config option, such as "uploadpack.sparsePathFilter", should be implemented first to restrict the directory from which the files specified by 'sparse:path' can be read. For now though, let's just disable 'sparse:path' filters. Helped-by: Matthew DeVore <matvore@google.com> Helped-by: Jeff Hostetler <git@jeffhostetler.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19Merge branch 'jk/get-oid-indexed-object-name'Libravatar Junio C Hamano1-6/+2
The codepath to parse :<path> that obtains the object name for an indexed object has been made more robust. * jk/get-oid-indexed-object-name: get_oid: handle NULL repo->index
2019-05-19Merge branch 'tz/test-lib-check-working-jgit'Libravatar Junio C Hamano1-1/+1
A prerequiste check in the test suite to see if a working jgit is available was made more robust. * tz/test-lib-check-working-jgit: test-lib: try harder to ensure a working jgit
2019-05-19Merge branch 'es/check-non-portable-pre-5.10'Libravatar Junio C Hamano1-4/+5
Developer support update. * es/check-non-portable-pre-5.10: check-non-portable-shell: support Perl versions older than 5.10
2019-05-19Merge branch 'js/fsmonitor-refresh-after-discarding-index'Libravatar Junio C Hamano2-1/+31
The fsmonitor interface got out of sync after the in-core index file gets discarded, which has been corrected. * js/fsmonitor-refresh-after-discarding-index: fsmonitor: force a refresh after the index was discarded fsmonitor: demonstrate that it is not refreshed after discard_index()
2019-05-19Merge branch 'js/t5580-unc-alternate-test'Libravatar Junio C Hamano1-0/+12
An additional test for MinGW * js/t5580-unc-alternate-test: t5580: verify that alternates can be UNC paths
2019-05-19Merge branch 'bl/t4253-exit-code-from-format-patch'Libravatar Junio C Hamano1-2/+4
Avoid patterns to pipe output from a git command to feed another command in tests. * bl/t4253-exit-code-from-format-patch: t4253-am-keep-cr-dos: avoid using pipes
2019-05-19Merge branch 'dl/difftool-mergetool'Libravatar Junio C Hamano2-61/+126
Update "git difftool" and "git mergetool" so that the combinations of {diff,merge}.{tool,guitool} configuration variables serve as fallback settings of each other in a sensible order. * dl/difftool-mergetool: difftool: fallback on merge.guitool difftool: make --gui, --tool and --extcmd mutually exclusive mergetool: fallback to tool when guitool unavailable mergetool--lib: create gui_mode function mergetool: use get_merge_tool function t7610: add mergetool --gui tests t7610: unsuppress output
2019-05-19Merge branch 'js/t6500-use-windows-pid-on-mingw'Libravatar Junio C Hamano1-1/+9
Future-proof a test against an update to MSYS2 runtime v3.x series. * js/t6500-use-windows-pid-on-mingw: t6500(mingw): use the Windows PID of the shell
2019-05-19Merge branch 'jk/apache-lsan'Libravatar Junio C Hamano1-0/+1
Allow tests that involve httpd to be run under leak sanitizer, just like we can already do so under address sanitizer. * jk/apache-lsan: t/lib-httpd: pass LSAN_OPTIONS through apache
2019-05-19Merge branch 'nd/parse-options-aliases'Libravatar Junio C Hamano2-0/+20
Attempt to use an abbreviated option in "git clone --recurs" is responded by a request to disambiguate between --recursive and --recurse-submodules, which is bad because these two are synonyms. The parse-options API has been extended to define such synonyms more easily and not produce an unnecessary failure. * nd/parse-options-aliases: parse-options: don't emit "ambiguous option" for aliases
2019-05-19Merge branch 'dl/branch-from-3dot-merge-base'Libravatar Junio C Hamano2-30/+40
"git branch new A...B" and "git checkout -b new A...B" have been taught that in their contexts, the notation A...B means "the merge base between these two commits", just like "git checkout A...B" detaches HEAD at that commit. * dl/branch-from-3dot-merge-base: branch: make create_branch accept a merge base rev t2018: cleanup in current test
2019-05-19Merge branch 'ab/perf-installed-fix'Libravatar Junio C Hamano4-27/+53
Performance test framework has been broken and measured the version of Git that happens to be on $PATH, not the specified one to measure, for a while, which has been corrected. * ab/perf-installed-fix: perf-lib.sh: forbid the use of GIT_TEST_INSTALLED perf tests: add "bindir" prefix to git tree test results perf-lib.sh: remove GIT_TEST_INSTALLED from perf-lib.sh perf-lib.sh: make "./run <revisions>" use the correct gits perf aggregate: remove GIT_TEST_INSTALLED from --codespeed perf README: correct docs for 3c8f12c96c regression
2019-05-19Merge branch 'dl/warn-tagging-a-tag'Libravatar Junio C Hamano1-1/+1
Typofix. * dl/warn-tagging-a-tag: tag: fix typo in nested tagging hint
2019-05-15test-lib: try harder to ensure a working jgitLibravatar Todd Zullinger1-1/+1
The JGIT prereq uses `type jgit` to determine whether jgit is present. While this is usually sufficient, it won't help if the jgit found is badly broken. This wastes time running tests which fail due to no fault of our own. Use `jgit --version` instead, to guard against cases where jgit is present on the system, but will fail to run, e.g. because of some JRE issue, or missing Java dependencies. Checking that it gets far enough to process the '--version' argument isn't perfect, but seems to be good enough in practice. It's also consistent with how we detect some other dependencies, see e.g. the CURL and UNZIP prerequisites. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-15get_oid: handle NULL repo->indexLibravatar Jeff King1-6/+2
When get_oid() and its helpers see an index name like ":.gitmodules", they try to load the index on demand, like: if (repo->index->cache) repo_read_index(repo); However, that misses the case when "repo->index" itself is NULL; we'll segfault in the conditional. This never happens with the_repository; there we always point its index field to &the_index. But a submodule repository may have a NULL index field until somebody calls repo_read_index(). This bug is triggered by t7411, but it was hard to notice because it's in an expect_failure block. That test was added by 2b1257e463 (t/helper: add test-submodule-nested-repo-config, 2018-10-25). Back then we had no easy way to access the .gitmodules blob of a submodule repo, so we expected (and got) an error message to that effect. Later, d9b8b8f896 (submodule-config.c: use repo_get_oid for reading .gitmodules, 2019-04-16) started looking in the correct repo, which is when we started triggering the segfault. With this fix, the test starts passing (once we clean it up as its comment instructs). Note that as far as I know, this bug could not be triggered outside of the test suite. It requires resolving an index name in a submodule, and all of the code paths (aside from test-tool) which do that either load the index themselves, or always pass the_repository. Ultimately it comes from 3a7a698e93 (sha1-name.c: remove implicit dependency on the_index, 2019-01-12), which replaced a check of "the_index.cache" with "repo->index->cache". So even if there is another way to trigger it, it wouldn't affect any versions before then. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13Merge branch 'pw/clean-sequencer-state-upon-final-commit'Libravatar Junio C Hamano2-0/+75
"git chery-pick" (and "revert" that shares the same runtime engine) that deals with multiple commits got confused when the final step gets stopped with a conflict and the user concluded the sequence with "git commit". Attempt to fix it by cleaning up the state files used by these commands in such a situation. * pw/clean-sequencer-state-upon-final-commit: fix cherry-pick/revert status after commit commit/reset: try to clean up sequencer state
2019-05-13Merge branch 'jk/perf-aggregate-wo-libjson'Libravatar Junio C Hamano1-2/+2
The script to aggregate perf result unconditionally depended on libjson-perl even though it did not have to, which has been corrected. * jk/perf-aggregate-wo-libjson: t/perf: depend on perl JSON only when using --codespeed
2019-05-13Merge branch 'jk/p5302-avoid-collision-check-cost'Libravatar Junio C Hamano1-13/+18
Fix index-pack perf test so that the repeated invocations always run in an empty repository, which emulates the initial clone situation better. * jk/p5302-avoid-collision-check-cost: p5302: create the repo in each index-pack test
2019-05-13Merge branch 'ew/repack-with-bitmaps-by-default'Libravatar Junio C Hamano4-7/+21
The connectivity bitmaps are created by default in bare repositories now; also the pathname hash-cache is created by default to avoid making crappy deltas when repacking. * ew/repack-with-bitmaps-by-default: pack-objects: default to writing bitmap hash-cache t5310: correctly remove bitmaps for jgit test repack: enable bitmaps by default on bare repos
2019-05-13Merge branch 'js/partial-clone-connectivity-check'Libravatar Junio C Hamano1-0/+26
During an initial "git clone --depth=..." partial clone, it is pointless to spend cycles for a large portion of the connectivity check that enumerates and skips promisor objects (which by definition is all objects fetched from the other side). This has been optimized out. * js/partial-clone-connectivity-check: t/perf: add perf script for partial clones clone: do faster object check for partial clones
2019-05-13Merge branch 'jh/trace2-sid-fix'Libravatar Junio C Hamano3-21/+113
Polishing of the new trace2 facility continues. The system-level configuration can specify site-wide trace2 settings, which can be overridden with per-user configuration and environment variables. * jh/trace2-sid-fix: trace2: fixup access problem on /etc/gitconfig in read_very_early_config trace2: update docs to describe system/global config settings trace2: make SIDs more unique trace2: clarify UTC datetime formatting trace2: report peak memory usage of the process trace2: use system/global config for default trace2 settings config: add read_very_early_config() trace2: find exec-dir before trace2 initialization trace2: add absolute elapsed time to start event trace2: refactor setting process starting time config: initialize opts structure in repo_read_config()
2019-05-13difftool: fallback on merge.guitoolLibravatar Denton Liu1-0/+16
In git-difftool.txt, it says 'git difftool' falls back to 'git mergetool' config variables when the difftool equivalents have not been defined. However, when `diff.guitool` is missing, it doesn't fallback to anything. Make git-difftool fallback to `merge.guitool` when `diff.guitool` is missing. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13difftool: make --gui, --tool and --extcmd mutually exclusiveLibravatar Denton Liu1-0/+8
In git-difftool, these options specify which tool to ultimately run. As a result, they are logically conflicting. Explicitly disallow these options from being used together. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13mergetool: fallback to tool when guitool unavailableLibravatar Denton Liu1-0/+19
In git-difftool, if the tool is called with --gui but `diff.guitool` is not set, it falls back to `diff.tool`. Make git-mergetool also fallback from `merge.guitool` to `merge.tool` if the former is undefined. If git-difftool, when called with `--gui`, were to use `get_configured_mergetool` in a future patch, it would also get the fallback behavior in the following precedence: 1. diff.guitool 2. merge.guitool 3. diff.tool 4. merge.tool The behavior for when difftool or mergetool are called without `--gui` should be identical with or without this patch. Note that the search loop could be written as sections="merge" keys="tool" if diff_mode then sections="diff $sections" fi if gui_mode then keys="guitool $keys" fi merge_tool=$( IFS=' ' for key in $keys do for section in $sections do selected=$(git config $section.$key) if test -n "$selected" then echo "$selected" return fi done done) which would make adding a mode in the future much easier. However, adding a new mode will likely never happen as it is highly discouraged so, as a result, it is written in its current form so that it is more readable for future readers. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13check-non-portable-shell: support Perl versions older than 5.10Libravatar Eric Sunshine1-4/+5
For thoroughness when checking for one-shot environment variable assignments at shell function call sites, check-non-portable-shell stitches together incomplete lines (those ending with backslash). This allows it to correctly flag such undesirable usage even when the variable assignment and function call are split across lines, for example: FOO=bar \ func where 'func' is a shell function. The stitching is accomplished like this: while (<>) { chomp; # stitch together incomplete lines (those ending with "\") while (s/\\$//) { $_ .= readline; chomp; } # detect unportable/undesirable shell constructs ... } Although this implementation is well supported in reasonably modern Perl versions (5.10 and later), it fails with older versions (such as Perl 5.8 shipped with ancient Mac OS 10.5). In particular, in older Perl versions, 'readline' is not connected to the file handle associated with the "magic" while (<>) {...} construct, so 'readline' throws a "readline() on unopened filehandle" error. Work around this problem by dropping readline() and instead incorporating the stitching of incomplete lines directly into the existing while (<>) {...} loop. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-09tag: fix typo in nested tagging hintLibravatar Denton Liu1-1/+1
In eea9c1e78f (tag: advise on nested tags, 2019-04-04), tag was taught to hint at the user if a nested tag is made. However, this message had a typo and it said "The object referred to by your new is...", which was missing a "tag" after "new". Fix this message by adding the "tag". Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-09Merge branch 'jt/submodule-repo-is-with-worktree'Libravatar Junio C Hamano1-0/+24
The logic to tell if a Git repository has a working tree protects "git branch -D" from removing the branch that is currently checked out by mistake. The implementation of this logic was broken for repositories with unusual name, which unfortunately is the norm for submodules these days. This has been fixed. * jt/submodule-repo-is-with-worktree: worktree: update is_bare heuristics
2019-05-09Merge branch 'jk/prune-optim'Libravatar Junio C Hamano1-0/+8
A follow-up test for an earlier "git prune" improvements. * jk/prune-optim: t5304: add a test for pruning with bitmaps
2019-05-09Merge branch 'js/misc-doc-fixes'Libravatar Junio C Hamano8-24/+230
"make check-docs", "git help -a", etc. did not account for cases where a particular build may deliberately omit some subcommands, which has been corrected. * js/misc-doc-fixes: Turn `git serve` into a test helper test-tool: handle the `-C <directory>` option just like `git` check-docs: do not bother checking for legacy scripts' documentation docs: exclude documentation for commands that have been excluded check-docs: allow command-list.txt to contain excluded commands help -a: do not list commands that are excluded from the build Makefile: drop the NO_INSTALL variable remote-testgit: move it into the support directory for t5801
2019-05-09Merge branch 'dr/ref-filter-push-track-fix'Libravatar Junio C Hamano1-2/+11
%(push:track) token used in the --format option to "git for-each-ref" and friends was not showing the right branch, which has been fixed. * dr/ref-filter-push-track-fix: ref-filter: use correct branch for %(push:track)
2019-05-09Merge branch 'jt/clone-server-option'Libravatar Junio C Hamano1-0/+41
"git clone" learned a new --server-option option when talking over the protocol version 2. * jt/clone-server-option: clone: send server options when using protocol v2 transport: die if server options are unsupported
2019-05-09Merge branch 'tb/unexpected'Libravatar Junio C Hamano5-12/+133
Code tightening against a "wrong" object appearing where an object of a different type is expected, instead of blindly assuming that the connection between objects are correctly made. * tb/unexpected: rev-list: detect broken root trees rev-list: let traversal die when --missing is not in use get_commit_tree(): return NULL for broken tree list-objects.c: handle unexpected non-tree entries list-objects.c: handle unexpected non-blob entries t: introduce tests for unexpected object types t: move 'hex2oct' into test-lib-functions.sh
2019-05-09Merge branch 'nd/sha1-name-c-wo-the-repository'Libravatar Junio C Hamano1-5/+1
Further code clean-up to allow the lowest level of name-to-object mapping layer to work with a passed-in repository other than the default one. * nd/sha1-name-c-wo-the-repository: (34 commits) sha1-name.c: remove the_repo from get_oid_mb() sha1-name.c: remove the_repo from other get_oid_* sha1-name.c: remove the_repo from maybe_die_on_misspelt_object_name submodule-config.c: use repo_get_oid for reading .gitmodules sha1-name.c: add repo_get_oid() sha1-name.c: remove the_repo from get_oid_with_context_1() sha1-name.c: remove the_repo from resolve_relative_path() sha1-name.c: remove the_repo from diagnose_invalid_index_path() sha1-name.c: remove the_repo from handle_one_ref() sha1-name.c: remove the_repo from get_oid_1() sha1-name.c: remove the_repo from get_oid_basic() sha1-name.c: remove the_repo from get_describe_name() sha1-name.c: remove the_repo from get_oid_oneline() sha1-name.c: add repo_interpret_branch_name() sha1-name.c: remove the_repo from interpret_branch_mark() sha1-name.c: remove the_repo from interpret_nth_prior_checkout() sha1-name.c: remove the_repo from get_short_oid() sha1-name.c: add repo_for_each_abbrev() sha1-name.c: store and use repo in struct disambiguate_state sha1-name.c: add repo_find_unique_abbrev_r() ...
2019-05-09Merge branch 'cc/replace-graft-peel-tags'Libravatar Junio C Hamano1-3/+28
When given a tag that points at a commit-ish, "git replace --graft" failed to peel the tag before writing a replace ref, which did not make sense because the old graft mechanism the feature wants to mimick only allowed to replace one commit object with another. This has been fixed. * cc/replace-graft-peel-tags: replace: peel tag when passing a tag first to --graft replace: peel tag when passing a tag as parent to --graft t6050: redirect expected error output to a file t6050: use test_line_count instead of wc -l
2019-05-09Merge branch 'js/trace2-to-directory'Libravatar Junio C Hamano1-0/+15
The trace2 tracing facility learned to auto-generate a filename when told to log to a directory. * js/trace2-to-directory: trace2: write to directory targets
2019-05-09Merge branch 'dl/merge-cleanup-scissors-fix'Libravatar Junio C Hamano5-80/+297
The list of conflicted paths shown in the editor while concluding a conflicted merge was shown above the scissors line when the clean-up mode is set to "scissors", even though it was commented out just like the list of updated paths and other information to help the user explain the merge better. * dl/merge-cleanup-scissors-fix: cherry-pick/revert: add scissors line on merge conflict sequencer.c: save and restore cleanup mode merge: add scissors line on merge conflict merge: cleanup messages like commit parse-options.h: extract common --cleanup option commit: extract cleanup_mode functions to sequencer t7502: clean up style t7604: clean up style t3507: clean up style t7600: clean up style
2019-05-09Merge branch 'pw/sequencer-cleanup-with-signoff-x-fix'Libravatar Junio C Hamano1-0/+20
"git cherry-pick" run with the "-x" or the "--signoff" option used to (and more importantly, ought to) clean up the commit log message with the --cleanup=space option by default, but this has been broken since late 2017. This has been fixed. * pw/sequencer-cleanup-with-signoff-x-fix: sequencer: fix cleanup with --signoff and -x
2019-05-09Merge branch 'km/empty-repo-is-still-a-repo'Libravatar Junio C Hamano3-1/+72
Running "git add" on a repository created inside the current repository is an explicit indication that the user wants to add it as a submodule, but when the HEAD of the inner repository is on an unborn branch, it cannot be added as a submodule. Worse, the files in its working tree can be added as if they are a part of the outer repository, which is not what the user wants. These problems are being addressed. * km/empty-repo-is-still-a-repo: add: error appropriately on repository with no commits dir: do not traverse repositories with no commits submodule: refuse to add repository with no commits
2019-05-09Merge branch 'dl/warn-tagging-a-tag'Libravatar Junio C Hamano1-0/+11
"git tag" learned to give an advice suggesting it might be a mistake when creating an annotated or signed tag that points at another tag. * dl/warn-tagging-a-tag: tag: advise on nested tags tag: fix formatting
2019-05-09Merge branch 'en/merge-directory-renames'Libravatar Junio C Hamano3-63/+415
"git merge-recursive" backend recently learned a new heuristics to infer file movement based on how other files in the same directory moved. As this is inherently less robust heuristics than the one based on the content similarity of the file itself (rather than based on what its neighbours are doing), it sometimes gives an outcome unexpected by the end users. This has been toned down to leave the renamed paths in higher/conflicted stages in the index so that the user can examine and confirm the result. * en/merge-directory-renames: merge-recursive: switch directory rename detection default merge-recursive: give callers of handle_content_merge() access to contents merge-recursive: track information associated with directory renames t6043: fix copied test description to match its purpose merge-recursive: switch from (oid,mode) pairs to a diff_filespec merge-recursive: cleanup handle_rename_* function signatures merge-recursive: track branch where rename occurred in rename struct merge-recursive: remove ren[12]_other fields from rename_conflict_info merge-recursive: shrink rename_conflict_info merge-recursive: move some struct declarations together merge-recursive: use 'ci' for rename_conflict_info variable name merge-recursive: rename locals 'o' and 'a' to 'obuf' and 'abuf' merge-recursive: rename diff_filespec 'one' to 'o' merge-recursive: rename merge_options argument from 'o' to 'opt' Use 'unsigned short' for mode, like diff_filespec does
2019-05-08t6500(mingw): use the Windows PID of the shellLibravatar Johannes Schindelin1-1/+9
In Git for Windows, we use the MSYS2 Bash which inherits a non-standard PID model from Cygwin's POSIX emulation layer: every MSYS2 process has a regular Windows PID, and in addition it has an MSYS2 PID (which corresponds to a shadow process that emulates Unix-style signal handling). With the upgrade to the MSYS2 runtime v3.x, this shadow process cannot be accessed via `OpenProcess()` any longer, and therefore t6500 thought incorrectly that the process referenced in `gc.pid` (which is not actually a real `gc` process in this context, but the current shell) no longer exists. Let's fix this by making sure that the Windows PID is written into `gc.pid` in this test script so that `git.exe` is able to understand that that process does indeed still exist. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08t/lib-httpd: pass LSAN_OPTIONS through apacheLibravatar Jeff King1-0/+1
Just as we instruct Apache to pass through ASAN_OPTIONS (so that server-side Git programs it spawns will respect our options while running the tests), we should do the same with LSAN_OPTIONS. Otherwise trying to collect a list of leaks like: export LSAN_OPTIONS=exitcode=0:log_path=/tmp/lsan make SANITIZE=leak test won't work for http tests (the server-side programs won't log their leaks to the right place, and they'll prematurely die, producing a spurious test failure). Signed-off-by: Jeff King <peff@peff.net> Acked-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08fsmonitor: force a refresh after the index was discardedLibravatar Johannes Schindelin1-1/+1
With this change, the `index_state` struct becomes the new home for the flag that says whether the fsmonitor hook has been run, i.e. it is now per-index. It also gets re-set when the index is discarded, fixing the bug demonstrated by the "test_expect_failure" test added in the preceding commit. In that case fsmonitor-enabled Git would miss updates under certain circumstances, see that preceding commit for details. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08fsmonitor: demonstrate that it is not refreshed after discard_index()Libravatar Johannes Schindelin2-1/+31
This one is tricky. When `core.fsmonitor` is set, a `refresh_index()` will not perform a full scan of files that might be modified, but will query the fsmonitor and refresh only the ones that have been actually touched. Due to implementation details, the fsmonitor is queried in `refresh_cache_ent()`, but of course it only has to be queried once, so we set a flag when we did that. But when the index was discarded, we did not re-set that flag. So far, this is only covered by our test suite when running with GIT_TEST_FSMONITOR=$PWD/t7519/fsmonitor-all, and only due to the way the built-in stash interacts with the recursive merge machinery. Let's introduce a straight-forward regression test for this. We simply extend the "read & discard index" loop in `test-tool read-cache` to optionally refresh the index, report on a given file's status, and then modify that file. Due to the bug described above, only the first refresh will actually query the fsmonitor; subsequent loop iterations will not. This problem was reported by Ævar Arnfjörð Bjarmason. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-08perf-lib.sh: forbid the use of GIT_TEST_INSTALLEDLibravatar Ævar Arnfjörð Bjarmason2-0/+13
As noted in preceding commits setting GIT_TEST_INSTALLED has never been supported or documented, and as noted in an earlier t/perf/README change to the extent that it's been documented nobody's notices that the example hasn't worked since 3c8f12c96c ("test-lib: reorder and include GIT-BUILD-OPTIONS a lot earlier", 2012-06-24). We could directly support GIT_TEST_INSTALLED for invocations without the "run" script, such as: GIT_TEST_INSTALLED=../../ ./p0000-perf-lib-sanity.sh GIT_TEST_INSTALLED=/home/avar/g/git ./p0000-perf-lib-sanity.sh But while not having this "error" will "work", it won't write the the resulting "test-results/*" files to the right place, and thus a subsequent call to aggregate.perl won't work as expected. Let's just tell the user that they need to use the "run" script, which'll correctly deal with this and set the right PERF_RESULTS_PREFIX. If someone's in desperate need of bypassing "run" for whatever reason they can trivially do so by setting "PERF_SET_GIT_TEST_INSTALLED", but not we won't have people who expect GIT_TEST_INSTALLED to just work wondering why their aggregation doesn't work, even though they're running the right "git". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
2019-05-08perf tests: add "bindir" prefix to git tree test resultsLibravatar Ævar Arnfjörð Bjarmason2-2/+4
Change the output file names in test-results/ to be "test-results/bindir_<munged dir>" rather than just "test-results/<munged dir>". This is for consistency with the "build_" directories we have for built revisions, i.e. "test-results/build_<SHA-1>". There's no user-visible functional changes here, it just makes it easier to see at a glance what "test-results" files are of what "type" as they're all explicitly grouped together now, and to grep this code to find both the run_dirs_helper() implementation and its corresponding aggregate.perl code. Note that we already guarantee that the rest of the PERF_RESULTS_PREFIX is an absolute path, and since it'll start with e.g. "/" which we munge to "_" we'll up with a readable string like "bindir_home_avar[...]". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
2019-05-08perf-lib.sh: remove GIT_TEST_INSTALLED from perf-lib.shLibravatar Ævar Arnfjörð Bjarmason3-32/+38
Follow-up my preceding change which fixed the immediate "./run <revisions>" regression in 0baf78e7bc ("perf-lib.sh: rely on test-lib.sh for --tee handling", 2019-03-15) and entirely get rid of GIT_TEST_INSTALLED from perf-lib.sh (and aggregate.perl). As noted in that change the dance we're doing with GIT_TEST_INSTALLED perf-lib.sh isn't necessary, but there I was doing the most minimal set of changes to quickly fix a regression. But it's much simpler to never deal with the "GIT_TEST_INSTALLED" we were setting in perf-lib.sh at all. Instead the run_dirs_helper() sets the previously inferred $PERF_RESULTS_PREFIX directly. Setting this at the callsite that's already best positioned to exhaustively know about all the different cases we need to handle where PERF_RESULTS_PREFIX isn't what we want already (the empty string) makes the most sense. In one-off cases like: ./run ./p0000-perf-lib-sanity.sh ./p0000-perf-lib-sanity.sh We'll just do the right thing because PERF_RESULTS_PREFIX will be empty, and test-lib.sh takes care of finding where our git is. Any refactoring of this code needs to change both the shell code and the Perl code in aggregate.perl, because when running e.g.: ./run ../../ -- <test> The "../../" path to a relative bindir needs to be munged to a filename containing the results, and critically aggregate.perl does not get passed the path to those aggregations, just "../..". Let's fix cases where aggregate.perl would print e.g. ".." in its report output for this, and "git" for "/home/avar/g/git", i.e. it would always pick the last element. Now'll always print the full path instead. This also makes the code sturdier, e.g. you can feed "../.." to "./run" and then an absolute path to the aggregate.perl script, as long as the absolute path and "../.." resolved to the same directory printing the aggregation will work. Also simplify the "[_*]" on the RHS of "tr -c", we're trimming everything to "_", so we don't need that. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
2019-05-08perf-lib.sh: make "./run <revisions>" use the correct gitsLibravatar Ævar Arnfjörð Bjarmason2-2/+10
Fix a really bad regression in 0baf78e7bc ("perf-lib.sh: rely on test-lib.sh for --tee handling", 2019-03-15). Since that change all runs of different <revisions> of git have used the git found in the user's $PATH, e.g. /usr/bin/git instead of the <revision> we just built and wanted to performance test. The problem starts with GIT_TEST_INSTALLED not working like our non-perf tests with the "run" script. I.e. you can't run performance tests against a given installed git. Instead we expect to use it ourselves to point GIT_TEST_INSTALLED to the <revision> we just built. However, we had been relying on '$(cd "$GIT_TEST_INSTALLED" && pwd)' to resolve that relative $GIT_TEST_INSTALLED to an absolute path *before* test-lib.sh was loaded, in cases where it was e.g. "build/<rev>/bin-wrappers" and we wanted "<abs_path>build/...". This change post-dates another proposed solution by a few days[1], I didn't notice that version when I initially wrote this. I'm doing the most minimal thing to solve the regression here, a follow-up change will move this result prefix selection logic entirely into the "run" script. This makes e.g. these cases all work: ./run . $PWD/../../ origin/master origin/next HEAD -- <tests> As well as just a plain one-off: ./run <tests> And, since we're passing down the new GIT_PERF_DIR_MYDIR_REL we make sure the bug relating to aggregate.perl not finding our files as described in 0baf78e7bc doesn't happen again. What *doesn't* work is setting GIT_TEST_INSTALLED to a relative path, this will subtly fail in test-lib.sh. This has always been the case even before 0baf78e7bc, and as documented in t/README the GIT_TEST_INSTALLED variable should be set to an absolute path (needs to be set "to the bindir", which is always absolute), and the "perf" framework expects to munge it itself. Perhaps that should be dealt with in the future to allow manually setting GIT_TEST_INSTALLED, but as a preceding commit showed the user can just use the "run" script, which'll also pick the right output directory for the test results as expected by aggregate.perl. 1. https://public-inbox.org/git/20190502222409.GA15631@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
2019-05-08perf aggregate: remove GIT_TEST_INSTALLED from --codespeedLibravatar Ævar Arnfjörð Bjarmason1-3/+0
Remove the setting of the "environment" from the --codespeed output. I don't think this is useful, and it helps with a later refactoring where we GIT_TEST_INSTALLED stop munging/reading GIT_TEST_INSTALLED in the perf tests in so many places. This was added in 05eb1c37ed ("perf/aggregate: implement codespeed JSON output", 2018-01-05), but since the "run" scripts uses "GIT_TEST_INSTALLED" internally this was only ever useful for one-off runs of a single revision as all the "environment" values would be ones for whatever directory the "run" script ran last. Let's instead fall back on the "uname -r" case, which is the sort of thing the environment should be set to, not something that duplicates other parts of the codpseed output. For setting the "environment" to something custom the perf.repoName variable can be used. See 19cf57a92e ("perf/run: read GIT_PERF_REPO_NAME from perf.repoName", 2018-01-05). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>