summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-09-18Merge branch 'jt/avoid-ls-refs-with-http'Libravatar Junio C Hamano2-0/+24
The http transport lacked some optimization the native transports learned to avoid unnecessary ref advertisement, which has been corrected. * jt/avoid-ls-refs-with-http: transport: teach all vtables to allow fetch first transport-helper: skip ls-refs if unnecessary
2019-09-18Merge branch 'md/list-objects-filter-combo'Libravatar Junio C Hamano2-8/+205
The list-objects-filter API (used to create a sparse/lazy clone) learned to take a combined filter specification. * md/list-objects-filter-combo: list-objects-filter-options: make parser void list-objects-filter-options: clean up use of ALLOC_GROW list-objects-filter-options: allow mult. --filter strbuf: give URL-encoding API a char predicate fn list-objects-filter-options: make filter_spec a string_list list-objects-filter-options: move error check up list-objects-filter: implement composite filters list-objects-filter-options: always supply *errbuf list-objects-filter: put omits set in filter struct list-objects-filter: encapsulate filter components
2019-09-18Merge branch 'cc/multi-promisor'Libravatar Junio C Hamano3-9/+59
Teach the lazy clone machinery that there can be more than one promisor remote and consult them in order when downloading missing objects on demand. * cc/multi-promisor: Move core_partial_clone_filter_default to promisor-remote.c Move repository_format_partial_clone to promisor-remote.c Remove fetch-object.{c,h} in favor of promisor-remote.{c,h} remote: add promisor and partial clone config to the doc partial-clone: add multiple remotes in the doc t0410: test fetching from many promisor remotes builtin/fetch: remove unique promisor remote limitation promisor-remote: parse remote.*.partialclonefilter Use promisor_remote_get_direct() and has_promisor_remote() promisor-remote: use repository_format_partial_clone promisor-remote: add promisor_remote_reinit() promisor-remote: implement promisor_remote_get_direct() Add initial support for many promisor remotes fetch-object: make functions return an error code t0410: remove pipes after git commands
2019-09-18Merge branch 'sg/line-log-tree-diff-optim'Libravatar Junio C Hamano1-0/+82
Optimize unnecessary full-tree diff away from "git log -L" machinery. * sg/line-log-tree-diff-optim: line-log: avoid unnecessary full tree diffs line-log: extract pathspec parsing from line ranges into a helper function
2019-09-18Merge branch 'sg/complete-configuration-variables'Libravatar Junio C Hamano1-0/+63
Command line completion updates for "git -c var.name=val" * sg/complete-configuration-variables: completion: complete config variables and values for 'git clone --config=' completion: complete config variables names and values for 'git clone -c' completion: complete values of configuration variables after 'git -c var=' completion: complete configuration sections and variable names for 'git -c' completion: split _git_config() completion: simplify inner 'case' pattern in __gitcomp() completion: use 'sort -u' to deduplicate config variable names completion: deduplicate configuration sections completion: add tests for 'git config' completion completion: complete more values of more 'color.*' configuration variables completion: fix a typo in a comment
2019-09-18Merge branch 'js/pre-merge-commit-hook'Libravatar Junio C Hamano2-139/+281
A new "pre-merge-commit" hook has been introduced. * js/pre-merge-commit-hook: merge: --no-verify to bypass pre-merge-commit hook git-merge: honor pre-merge-commit hook merge: do no-verify like commit t7503: verify proper hook execution
2019-09-18Merge branch 'js/rebase-r-strategy'Libravatar Junio C Hamano5-101/+113
"git rebase --rebase-merges" learned to drive different merge strategies and pass strategy specific options to them. * js/rebase-r-strategy: t3427: accelerate this test by using fast-export and fast-import rebase -r: do not (re-)generate root commits with `--root` *and* `--onto` t3418: test `rebase -r` with merge strategies t/lib-rebase: prepare for testing `git rebase --rebase-merges` rebase -r: support merge strategies other than `recursive` t3427: fix another incorrect assumption t3427: accommodate for the `rebase --merge` backend having been replaced t3427: fix erroneous assumption t3427: condense the unnecessarily repetitive test cases into three t3427: move the `filter-branch` invocation into the `setup` case t3427: simplify the `setup` test case significantly t3427: add a clarifying comment rebase: fold git-rebase--common into the -p backend sequencer: the `am` and `rebase--interactive` scripts are gone .gitignore: there is no longer a built-in `git-rebase--interactive` t3400: stop referring to the scripted rebase Drop unused git-rebase--am.sh
2019-09-09Merge branch 'bc/reread-attributes-during-rebase'Libravatar Junio C Hamano2-0/+88
The "git am" based backend of "git rebase" ignored the result of updating ".gitattributes" done in one step when replaying subsequent steps. * bc/reread-attributes-during-rebase: am: reload .gitattributes after patching it path: add a function to check for path suffix
2019-09-09Merge branch 'tg/t0021-racefix'Libravatar Junio C Hamano1-0/+3
A test fix. * tg/t0021-racefix: t0021: make sure clean filter runs
2019-09-09Merge branch 'mp/for-each-ref-missing-name-or-email'Libravatar Junio C Hamano1-0/+19
"for-each-ref" and friends that shows refs did not protect themselves against ancient tags that did not record tagger names when asked to show "%(taggername)", which have been corrected. * mp/for-each-ref-missing-name-or-email: ref-filter: initialize empty name or email fields
2019-09-09Merge branch 'sb/userdiff-dts'Libravatar Junio C Hamano12-0/+158
Device-tree files learned their own userdiff patterns. * sb/userdiff-dts: userdiff: add a builtin pattern for dts files
2019-09-09Merge branch 'jt/diff-lazy-fetch-submodule-fix'Libravatar Junio C Hamano1-0/+31
On-demand object fetching in lazy clone incorrectly tried to fetch commits from submodule projects, while still working in the superproject, which has been corrected. * jt/diff-lazy-fetch-submodule-fix: diff: skip GITLINK when lazy fetching missing objs
2019-09-09Merge branch 'cb/fetch-set-upstream'Libravatar Junio C Hamano1-0/+178
"git fetch" learned "--set-upstream" option to help those who first clone from their private fork they intend to push to, add the true upstream via "git remote add" and then "git fetch" from it. * cb/fetch-set-upstream: pull, fetch: add --set-upstream option
2019-09-09Merge branch 'rs/pax-extended-header-length-fix'Libravatar Junio C Hamano1-0/+19
"git archive" recorded incorrect length in extended pax header in some corner cases, which has been corrected. * rs/pax-extended-header-length-fix: archive-tar: turn length miscalculation warning into BUG archive-tar: use size_t in strbuf_append_ext_header() archive-tar: fix pax extended header length calculation archive-tar: report wrong pax extended header length
2019-09-09Merge branch 'ds/feature-macros'Libravatar Junio C Hamano7-35/+35
A mechanism to affect the default setting for a (related) group of configuration variables is introduced. * ds/feature-macros: repo-settings: create feature.experimental setting repo-settings: create feature.manyFiles setting repo-settings: parse core.untrackedCache commit-graph: turn on commit-graph by default t6501: use 'git gc' in quiet mode repo-settings: consolidate some config settings
2019-09-09Merge branch 'jk/eoo'Libravatar Junio C Hamano3-0/+22
The command line parser learned "--end-of-options" notation; the standard convention for scripters to have hardcoded set of options first on the command line, and force the command to treat end-user input as non-options, has been to use "--" as the delimiter, but that would not work for commands that use "--" as a delimiter between revs and pathspec. * jk/eoo: gitcli: document --end-of-options parse-options: allow --end-of-options as a synonym for "--" revision: allow --end-of-options to end option parsing
2019-09-09Merge branch 'jk/repo-init-cleanup'Libravatar Junio C Hamano1-1/+6
Further clean-up of the initialization code. * jk/repo-init-cleanup: config: stop checking whether the_repository is NULL common-main: delay trace2 initialization t1309: use short branch name in includeIf.onbranch test
2019-09-05t3427: accelerate this test by using fast-export and fast-importLibravatar Elijah Newren1-1/+4
fast-export and fast-import can easily handle the simple rewrite that was being done by filter-branch, and should be faster on systems with a slow fork. Measuring the overall time taken for all of t3427 (not just the difference between filter-branch and fast-export/fast-import) shows a speedup of about 5% on Linux and 11% on Mac. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-03am: reload .gitattributes after patching itLibravatar brian m. carlson2-0/+88
When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes applied, the file will be written out with the attributes in place as of the time we started the rebase or am operation, not with the attributes applied by the previous patch. This problem does not occur when using the -m or -i flags to rebase. To ensure we write the correct data into the working tree, expire the cache after each patch that touches a path ending in ".gitattributes". Since we load these attributes in multiple separate files, we must expire them accordingly. Verify that both the am and rebase code paths work correctly, including the conflict marker size with am -3. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22transport: teach all vtables to allow fetch firstLibravatar Jonathan Tan1-0/+11
The only transport that does not allow fetch() to be called before get_refs_list() is the bundle transport. Clean up the code by teaching the bundle transport the ability to do this, and removing support for transports that don't support this order of invocation. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22transport-helper: skip ls-refs if unnecessaryLibravatar Jonathan Tan1-0/+13
Commit e70a3030e7 ("fetch: do not list refs if fetching only hashes", 2018-10-07) and its ancestors taught Git, as an optimization, to skip the ls-refs step when it is not necessary during a protocol v2 fetch (for example, when lazy fetching a missing object in a partial clone, or when running "git fetch --no-tags <remote> <SHA-1>"). But that was only done for natively supported protocols; in particular, HTTP was not supported. Teach Git to skip ls-refs when using remote helpers that support connect or stateless-connect. To do this, fetch() is made an acceptable entry point. Because fetch() can now be the first function in the vtable called, "get_helper(transport);" has to be added to the beginning of that function to set the transport up (if not yet set up) before process_connect() is invoked. When fetch() is called, the transport could be taken over (this happens if "connect" or "stateless-connect" is successfully run without any "fallback" response), or not. If the transport is taken over, execution continues like execution for natively supported protocols (fetch_refs_via_pack() is executed, which will fetch refs using ls-refs if needed). If not, the remote helper interface will invoke get_refs_list() if it hasn't been invoked yet, preserving existing behavior. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22Merge branch 'jk/perf-no-dups'Libravatar Junio C Hamano1-0/+0
Test & perf scripts must use unique numeric prefix, but a pair shared the same number, which is fixed here. * jk/perf-no-dups: t/perf: rename duplicate-numbered test script
2019-08-22Merge branch 'sg/show-failed-test-names'Libravatar Junio C Hamano3-12/+14
The first line of verbose output from each test piece now carries the test name and number to help scanning with eyeballs. * sg/show-failed-test-names: tests: show the test name and number at the start of verbose output t0000-basic: use realistic test script names in the verbose tests
2019-08-22Merge branch 'sg/commit-graph-validate'Libravatar Junio C Hamano1-3/+11
The code to write commit-graph over given commit object names has been made a bit more robust. * sg/commit-graph-validate: commit-graph: error out on invalid commit oids in 'write --stdin-commits' commit-graph: turn a group of write-related macro flags into an enum t5318-commit-graph: use 'test_expect_code'
2019-08-22Merge branch 'vn/restore-empty-ita-corner-case-fix'Libravatar Junio C Hamano2-0/+22
"git checkout" and "git restore" to re-populate the index from a tree-ish (typically HEAD) did not work correctly for a path that was removed and then added again with the intent-to-add bit, when the corresponding working tree file was empty. This has been corrected. * vn/restore-empty-ita-corner-case-fix: restore: add test for deleted ita files checkout.c: unstage empty deleted ita files
2019-08-22Merge branch 'sg/do-not-skip-non-httpd-tests'Libravatar Junio C Hamano10-122/+153
Test fix. * sg/do-not-skip-non-httpd-tests: t: warn against adding non-httpd-specific tests after sourcing 'lib-httpd' t5703: run all non-httpd-specific tests before sourcing 'lib-httpd.sh' t5510-fetch: run non-httpd-specific test before sourcing 'lib-httpd.sh'
2019-08-22Merge branch 'sg/t5510-test-i18ngrep-fix'Libravatar Junio C Hamano1-1/+1
Test fix. * sg/t5510-test-i18ngrep-fix: t5510-fetch: fix negated 'test_i18ngrep' invocation
2019-08-22Merge branch 'mt/grep-submodules-working-tree'Libravatar Junio C Hamano1-0/+21
"git grep --recurse-submodules" that looks at the working tree files looked at the contents in the index in submodules, instead of files in the working tree. * mt/grep-submodules-working-tree: grep: fix worktree case in submodules
2019-08-22t0021: make sure clean filter runsLibravatar Thomas Gummerer1-0/+3
In t0021.15 one of the things we are checking is that the clean filter is run when checking out empty-branch. The clean filter needs to be run to make sure there are no modifications on the file system for the test.r file, and thus it isn't dangerous to overwrite it. However in the current test setup it is not always necessary to run the clean filter, and thus the test sometimes fails, as debug.log isn't written. This happens when test.r has an older mtime than the index itself. That mtime is also recorded as stat data for test.r in the index, and based on the heuristic we're using for index entries, git correctly assumes this file is up-to-date. Usually this test succeeds because the mtime of test.r is the same as the mtime of the index. In this case test.r is racily clean, so git actually checks the contents, for which the clean filter is run. Fix the test by updating the mtime of test.r, so git is forced to check the contents of the file, and the clean filter is run as the test expects. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-22ref-filter: initialize empty name or email fieldsLibravatar Mischa POSLAWSKY1-0/+19
Formatting $(taggername) on headerless tags such as v0.99 in Git causes a SIGABRT with error "munmap_chunk(): invalid pointer", because of an oversight in commit f0062d3b74 (ref-filter: free item->value and item->value->s, 2018-10-19). Signed-off-by: Mischa POSLAWSKY <git@shiar.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-21userdiff: add a builtin pattern for dts filesLibravatar Stephen Boyd12-0/+158
The Linux kernel receives many patches to the devicetree files each release. The hunk header for those patches typically show nothing, making it difficult to figure out what node is being modified without applying the patch or opening the file and seeking to the context. Let's add a builtin 'dts' pattern to git so that users can get better diff output on dts files when they use the diff=dts driver. The regex has been constructed based on the spec at devicetree.org[1] and with some help from Johannes Sixt. [1] https://github.com/devicetree-org/devicetree-specification/releases/latest Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-21line-log: avoid unnecessary full tree diffsLibravatar SZEDER Gábor1-0/+82
With rename detection enabled the line-level log is able to trace the evolution of line ranges across whole-file renames [1]. Alas, to achieve that it uses the diff machinery very inefficiently, making the operation very slow [2]. And since rename detection is enabled by default, the line-level log is very slow by default. When the line-level log processes a commit with rename detection enabled, it currently does the following (see queue_diffs()): 1. Computes a full tree diff between the commit and (one of) its parent(s), i.e. invokes diff_tree_oid() with an empty 'diffopt->pathspec'. 2. Checks whether any paths in the line ranges were modified. 3. Checks whether any modified paths in the line ranges are missing in the parent commit's tree. 4. If there is such a missing path, then calls diffcore_std() to figure out whether the path was indeed renamed based on the previously computed full tree diff. 5. Continues doing stuff that are unrelated to the slowness. So basically the line-level log computes a full tree diff for each commit-parent pair in step (1) to be used for rename detection in step (4) in the off chance that an interesting path is missing from the parent. Avoid these expensive and mostly unnecessary full tree diffs by limiting the diffs to paths in the line ranges. This is much cheaper, and makes step (2) unnecessary. If it turns out that an interesting path is missing from the parent, then fall back and compute a full tree diff, so the rename detection will still work. Care must be taken when to update the pathspec used to limit the diff in case of renames. A path might be renamed on one branch and modified on several parallel running branches, and while processing commits on these branches the line-level log might have to alternate between looking at a path's new and old name. However, at any one time there is only a single 'diffopt->pathspec'. So add a step (0) to the above to ensure that the paths in the pathspec match the paths in the line ranges associated with the currently processed commit, and re-parse the pathspec from the paths in the line ranges if they differ. The new test cases include a specially crafted piece of history with two merged branches and two files, where each branch modifies both files, renames on of them, and then modifies both again. Then two separate 'git log -L' invocations check the line-level log of each of those two files, which ensures that at least one of those invocations have to do that back-and-forth between the file's old and new name (no matter which branch is traversed first). 't/t4211-line-log.sh' already contains two tests involving renames, they don't don't trigger this back-and-forth. Avoiding these unnecessary full tree diffs can have huge impact on performance, especially in big repositories with big trees and mergy history. Tracing the evolution of a function through the whole history: # git.git $ time git --no-pager log -L:read_alternate_refs:sha1-file.c v2.23.0 Before: real 0m8.874s user 0m8.816s sys 0m0.057s After: real 0m2.516s user 0m2.456s sys 0m0.060s # linux.git $ time ~/src/git/git --no-pager log \ -L:build_restore_work_registers:arch/mips/mm/tlbex.c v5.2 Before: real 3m50.033s user 3m48.041s sys 0m0.300s After: real 0m2.599s user 0m2.466s sys 0m0.157s That's just over 88x speedup. [1] Line-level log's rename following is quite similar to 'git log --follow path', with the notable differences that it does handle multiple paths at once as well, and that it doesn't show the commit performing the rename if it's an exact rename. [2] This slowness might not have been apparent initially, because back when the line-level log feature was introduced rename detection was not yet enabled by default; 12da1d1f6f (Implement line-history search (git log -L), 2013-03-28) and 5404c116aa (diff: activate diff.renames by default, 2016-02-25). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-20diff: skip GITLINK when lazy fetching missing objsLibravatar Jonathan Tan1-0/+31
In 7fbbcb21b1 ("diff: batch fetching of missing blobs", 2019-04-08), diff was taught to batch the fetching of missing objects when operating on a partial clone, but was not taught to refrain from fetching GITLINKs. Teach diff to check if an object is a GITLINK before including it in the set to be fetched. (As stated in the commit message of that commit, unpack-trees was also taught a similar thing prior, but unpack-trees correctly checks for GITLINK before including objects in the set to be fetched.) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19pull, fetch: add --set-upstream optionLibravatar Corentin BOMPARD1-0/+178
Add the --set-upstream option to git pull/fetch which lets the user set the upstream configuration (branch.<current-branch-name>.merge and branch.<current-branch-name>.remote) for the current branch. A typical use-case is: git clone http://example.com/my-public-fork git remote add main http://example.com/project-main-repo git pull --set-upstream main master or, instead of the last line: git fetch --set-upstream main master git merge # or git rebase This is mostly equivalent to cloning project-main-repo (which sets upsteam) and then "git remote add" my-public-fork, but may feel more natural for people using a hosting system which allows forking from the web UI. This functionality is analog to "git push --set-upstream". Signed-off-by: Corentin BOMPARD <corentin.bompard@etu.univ-lyon1.fr> Signed-off-by: Nathan BERBEZIER <nathan.berbezier@etu.univ-lyon1.fr> Signed-off-by: Pablo CHABANNE <pablo.chabanne@etu.univ-lyon1.fr> Signed-off-by: Matthieu Moy <git@matthieu-moy.fr> Patch-edited-by: Matthieu Moy <git@matthieu-moy.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19archive-tar: turn length miscalculation warning into BUGLibravatar René Scharfe1-2/+1
Now that we're confident our pax extended header calculation is correct, turn the criticality of the assertion up to the maximum, from warning right up to BUG. Simplify the test, as the stderr comparison step would not be reached in case the BUG message is triggered. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19archive-tar: fix pax extended header length calculationLibravatar René Scharfe1-1/+1
A pax extended header record starts with a decimal number. Its value is the length of the whole record, including its own length. The calculation of that number in strbuf_append_ext_header() is off by one in case the length of the rest is close to a higher order of magnitude. This affects paths and link targets a bit shorter than 1000, 10000, 100000 etc. characters -- paths with a length of up to 100 fit into the tar header and don't need a pax extended header. The mistake has been present since the function was added by ae64bbc18c ("tar-tree: Introduce write_entry()", 2006-03-25). Account for digits added to len during the loop and keep incrementing until we have enough space for len and the rest. The crucial change is to check against the current value of len before each iteration, instead of against its value before the loop. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-19archive-tar: report wrong pax extended header lengthLibravatar René Scharfe1-0/+20
Extended header entries contain a length value that is a bit tricky to calculate because it includes its own length (number of decimal digits) as well. We get it wrong in corner cases. Add a check, report wrong results as a warning and add a test for exercising it. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13repo-settings: create feature.experimental settingLibravatar Derrick Stolee1-23/+0
The 'feature.experimental' setting includes config options that are not committed to become defaults, but could use additional testing. Update the following config settings to take new defaults, and to use the repo_settings struct if not already using them: * 'pack.useSparse=true' * 'fetch.negotiationAlgorithm=skipping' In the case of fetch.negotiationAlgorithm, the existing logic would load the config option only when about to use the setting, so had a die() statement on an unknown string value. This is removed as now the config is parsed under prepare_repo_settings(). In general, this die() is probably misplaced and not valuable. A test was removed that checked this die() statement executed. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13repo-settings: create feature.manyFiles settingLibravatar Derrick Stolee1-5/+26
The feature.manyFiles setting is suitable for repos with many files in the working directory. By setting index.version=4 and core.untrackedCache=true, commands such as 'git status' should improve. While adding this setting, modify the index version precedence tests to check how this setting overrides the default for index.version is unset. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13commit-graph: turn on commit-graph by defaultLibravatar Derrick Stolee4-4/+6
The commit-graph feature has seen a lot of activity in the past year or so since it was introduced. The feature is a critical performance enhancement for medium- to large-sized repos, and does not significantly hurt small repos. Change the defaults for core.commitGraph and gc.writeCommitGraph to true so users benefit from this feature by default. There are several places in the test suite where the environment variable GIT_TEST_COMMIT_GRAPH is disabled to avoid reading a commit-graph, if it exists. The config option overrides the environment, so swap these. Some GIT_TEST_COMMIT_GRAPH assignments remain, and those are to avoid writing a commit-graph when a new commit is created. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13t6501: use 'git gc' in quiet modeLibravatar Derrick Stolee1-3/+3
t6501-freshen-objects.sh sends the standard error from 'git gc' to a file and verifies that it is empty. This is intended as a way to ensure no warnings are written during the operation. However, as the commit-graph is added as a step to 'git gc', its progress will appear in the output. Pass the '-q' argument to avoid a failing test case when progress is written. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete config variables and values for 'git clone --config='Libravatar SZEDER Gábor1-0/+21
Completing configuration sections and variable names for the stuck argument of 'git clone --config=<TAB>' requires a bit of extra care compared to doing the same for the unstuck argument of 'git clone --config <TAB>', because we have to deal with that '--config=' being part of the current word to be completed. Add an option to the __git_complete_config_variable_name_and_value() and in turn to the __git_complete_config_variable_name() helper functions to specify the current section/variable name to be completed, so they can be used even when completing the stuck argument of '--config='. __git_complete_config_variable_value() already has such an option, and thus no further changes were necessary to complete possible values after 'git clone --config=section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete values of configuration variables after 'git -c var='Libravatar SZEDER Gábor1-0/+7
'git config' expects a configuration variable's name and value in separate options, so we complete values as they stand on their own on the command line. 'git -c', however, expects them in a single option joined by a '=' character, so we should be able to complete values when they are following 'section.name=' in the same word. Add new options to the __git_complete_config_variable_value() function to allow callers to specify the current word to be completed and the configuration variable whose value is to be completed, and use these to complete possible values after 'git -c 'section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete configuration sections and variable names for 'git -c'Libravatar SZEDER Gábor1-0/+14
'git config' expects a configuration variable's name and value in separate arguments, so we let the __gitcomp() helper append a space character to each variable name by default, like we do for most other things (--options, refs, paths, etc.). 'git -c', however, expects them in a single option joined by a '=' character, i.e. 'section.name=value', so we should append a '=' character to each fully completed variable name, but no space, so the user can continue typing the value right away. Add an option to the __git_complete_config_variable_name() function to allow callers to specify an alternate suffix to add, and use it to append that '=' character to configuration variables. Update the __gitcomp() helper function to not append a trailing space to any completion words ending with a '=', not just to those option with a stuck argument. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: deduplicate configuration sectionsLibravatar SZEDER Gábor1-1/+1
The number of configuration variables listed by the completion script grew quite when we started to auto-generate it from the documentation [1], so we now complete them in two steps: first we list only the section names, then the rest [2]. To get the section names we simply strip everything following the first dot in each variable name, resulting in a lot of repeated section names, because most sections contain more than one configuration variable. This is not a correctness issue in practice, because Bash's completion facilities remove all repetitions anyway, but these repetitions make testing a bit harder. Replace the small 'sed' script removing subsections and variable names with an 'awk' script that does the same, and in addition removes any repeated configuration sections as well (by first creating and filling an associative array indexed by all encountered configuration sections, and then iterating over this array and printing the indices, i.e. the unique section names). This change makes the failing 'git config - section' test in 't9902-completion.sh' pass. Note that this changes the order of section names in the output, and makes it downright undeterministic, but this is not an issue, because Bash sorts them before presenting them to the user, and our completion tests sort them as well before comparing with the expected output. Yeah, it would be simpler and shorter to just append '| sort -u' to that command, but that would incur the overhead of one more external process and pipeline stage every time a user completes configuration sections. [1] e17ca92637 (completion: drop the hard coded list of config vars, 2018-05-26) [2] f22f682695 (completion: complete general config vars in two steps, 2018-05-27) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: add tests for 'git config' completionLibravatar SZEDER Gábor1-0/+21
The next patches will change/refactor the way we complete configuration variable names and values, so add a few tests to cover the basics, namely the completion of matching configuration sections, full variable names, and their values. Note that the test checking the completion of configuration sections is currently failing, though it's not a sign of an actual bug. If a section contains multiple variables, then that section is currently repeated as many times as the number of variables in there. This is not a correctness issue in practice, because Bash's completion facilities remove all repetitions anyway. Consequently, we could list all those repeated sections in the expected output of this test as well, but then it would have to be updated whenever a new configuration variable is added to those sections. Instead, list each matching configuration section only once, mark the test as failing for now, and the next patch will update the completion script to avoid those repetitions. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-12t/perf: rename duplicate-numbered test scriptLibravatar Jeff King1-0/+0
There are two perf scripts numbered p5600, but with otherwise different names ("clone-reference" versus "partial-clone"). We store timing results in files named after the whole script, so internally we don't get confused between the two. But "aggregate.perl" just prints the test number for each result, giving multiple entries for "5600.3". It also makes it impossible to skip one test but not the other with GIT_SKIP_TESTS. Let's renumber the one that appeared later (by date -- the source of the problem is that the two were developed on independent branches). For the non-perf test suite, our test-lint rule would have complained about this when the two were merged, but t/perf never learned that trick. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-09Merge branch 'jk/xdiff-clamp-funcname-context-index' into maintLibravatar Junio C Hamano1-0/+22
The internal diff machinery can be made to read out of bounds while looking for --funcion-context line in a corner case, which has been corrected. * jk/xdiff-clamp-funcname-context-index: xdiff: clamp function context indices in post-image
2019-08-09Merge branch 'bc/hash-independent-tests-part-4'Libravatar Junio C Hamano2-9/+8
Test fix. * bc/hash-independent-tests-part-4: t0000: reword comments for "local" test t: decrease nesting in test_oid_to_path
2019-08-09Merge branch 'mt/dir-iterator-updates'Libravatar Junio C Hamano1-3/+1
Leakfix. * mt/dir-iterator-updates: test-dir-iterator: use path argument directly dir-iterator: release strbuf after use