summaryrefslogtreecommitdiff
path: root/t/helper
AgeCommit message (Collapse)AuthorFilesLines
2019-10-15Merge branch 'ew/hashmap'Libravatar Junio C Hamano2-31/+31
Code clean-up of the hashmap API, both users and implementation. * ew/hashmap: hashmap_entry: remove first member requirement from docs hashmap: remove type arg from hashmap_{get,put,remove}_entry OFFSETOF_VAR macro to simplify hashmap iterators hashmap: introduce hashmap_free_entries hashmap: hashmap_{put,remove} return hashmap_entry * hashmap: use *_entry APIs for iteration hashmap_cmp_fn takes hashmap_entry params hashmap_get{,_from_hash} return "struct hashmap_entry *" hashmap: use *_entry APIs to wrap container_of hashmap_get_next returns "struct hashmap_entry *" introduce container_of macro hashmap_put takes "struct hashmap_entry *" hashmap_remove takes "const struct hashmap_entry *" hashmap_get takes "const struct hashmap_entry *" hashmap_add takes "struct hashmap_entry *" hashmap_get_next takes "const struct hashmap_entry *" hashmap_entry_init takes "struct hashmap_entry *" packfile: use hashmap_entry in delta_base_cache_entry coccicheck: detect hashmap_entry.hash assignment diff: use hashmap_entry_init on moved_entry.ent
2019-10-15Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano1-0/+153
CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
2019-10-07Merge branch 'sg/t-helper-gitignore'Libravatar Junio C Hamano1-5/+4
Update the way build artifacts in t/helper/ directory are ignored. * sg/t-helper-gitignore: t/helper: ignore only executable files
2019-10-07Merge branch 'sg/progress-fix'Libravatar Junio C Hamano3-0/+83
Regression fix for progress output. * sg/progress-fix: Test the progress display Revert "progress: use term_clear_line()"
2019-10-07Merge branch 'ss/get-time-cleanup'Libravatar Junio C Hamano1-18/+9
Code simplification. * ss/get-time-cleanup: test_date.c: remove reference to GIT_TEST_DATE_NOW Quit passing 'now' to date code
2019-10-07hashmap_entry: remove first member requirement from docsLibravatar Eric Wong1-0/+1
Comments stating that "struct hashmap_entry" must be the first member in a struct are no longer valid. Suggested-by: Phillip Wood <phillip.wood123@gmail.com> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap: remove type arg from hashmap_{get,put,remove}_entryLibravatar Eric Wong1-3/+1
Since these macros already take a `keyvar' pointer of a known type, we can rely on OFFSETOF_VAR to get the correct offset without relying on non-portable `__typeof__' and `offsetof'. Argument order is also rearranged, so `keyvar' and `member' are sequential as they are used as: `keyvar->member' Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07OFFSETOF_VAR macro to simplify hashmap iteratorsLibravatar Eric Wong2-6/+3
While we cannot rely on a `__typeof__' operator being portable to use with `offsetof'; we can calculate the pointer offset using an existing pointer and the address of a member using pointer arithmetic for compilers without `__typeof__'. This allows us to simplify usage of hashmap iterator macros by not having to specify a type when a pointer of that type is already given. In the future, list iterator macros (e.g. list_for_each_entry) may also be implemented using OFFSETOF_VAR to save hackers the trouble of using container_of/list_entry macros and without relying on non-portable `__typeof__'. v3: use `__typeof__' to avoid clang warnings Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap: introduce hashmap_free_entriesLibravatar Eric Wong1-3/+3
`hashmap_free_entries' behaves like `container_of' and passes the offset of the hashmap_entry struct to the internal `hashmap_free_' function, allowing the function to free any struct pointer regardless of where the hashmap_entry field is located. `hashmap_free' no longer takes any arguments aside from the hashmap itself. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap: hashmap_{put,remove} return hashmap_entry *Libravatar Eric Wong1-2/+7
And add *_entry variants to perform container_of as necessary to simplify most callers. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap: use *_entry APIs for iterationLibravatar Eric Wong2-11/+8
Inspired by list_for_each_entry in the Linux kernel. Once again, these are somewhat compromised usability-wise by compilers lacking __typeof__ support. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap_cmp_fn takes hashmap_entry paramsLibravatar Eric Wong1-4/+6
Another step in eliminating the requirement of hashmap_entry being the first member of a struct. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap: use *_entry APIs to wrap container_ofLibravatar Eric Wong1-7/+5
Using `container_of' can be verbose and choosing names for intermediate "struct hashmap_entry" pointers is a hard problem. So introduce "*_entry" APIs inspired by similar linked-list APIs in the Linux kernel. Unfortunately, `__typeof__' is not portable C, so we need an extra parameter to specify the type. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap_get_next returns "struct hashmap_entry *"Libravatar Eric Wong1-4/+6
This is a step towards removing the requirement for hashmap_entry being the first field of a struct. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap_put takes "struct hashmap_entry *"Libravatar Eric Wong1-1/+1
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap_add takes "struct hashmap_entry *"Libravatar Eric Wong1-3/+3
This is less error-prone than "void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap_get_next takes "const struct hashmap_entry *"Libravatar Eric Wong1-1/+1
This is less error-prone than "const void *" as the compiler now detects invalid types being passed. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-07hashmap_entry_init takes "struct hashmap_entry *"Libravatar Eric Wong1-3/+3
C compilers do type checking to make life easier for us. So rely on that and update all hashmap_entry_init callers to take "struct hashmap_entry *" to avoid future bugs while improving safety and readability. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06test-tool run-command: learn to run (parts of) the testsuiteLibravatar Johannes Schindelin1-0/+153
Git for Windows jumps through hoops to provide a development environment that allows to build Git and to run its test suite. To that end, an entire MSYS2 system, including GNU make and GCC is offered as "the Git for Windows SDK". It does come at a price: an initial download of said SDK weighs in with several hundreds of megabytes, and the unpacked SDK occupies ~2GB of disk space. A much more native development environment on Windows is Visual Studio. To help contributors use that environment, we already have a Makefile target `vcxproj` that generates a commit with project files (and other generated files), and Git for Windows' `vs/master` branch is continuously re-generated using that target. The idea is to allow building Git in Visual Studio, and to run individual tests using a Portable Git. The one missing thing is a way to run the entire test suite: neither `make` nor `prove` are required to run Git, therefore Git for Windows does not support those commands in the Portable Git. To help with that, add a simple test helper that exercises the `run_processes_parallel()` function to allow for running test scripts in parallel (which is really necessary, especially on Windows, as Git's test suite takes such a long time to run). This will also come in handy for the upcoming change to our Azure Pipeline: we will use this helper in a Portable Git to test the Visual Studio build of Git. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-20t/helper: ignore only executable filesLibravatar SZEDER Gábor1-5/+4
This patch conceptually reverts 44103f4197 (t/helper: ignore everything but sources, 2017-12-12). Back in those days we did have a lot of separate test helper executables under 't/helper', and its '.gitignore' did get out of sync every once in a while. Since then, however, most of those separate executables were integrated into a single 'test-tool' command [1], and new test helpers are added as new subcommands, so the chances of that '.gitignore' getting out of sync again are much lower. And even if a contributor were not careful enough and submits a patch that adds a new executable under 't/helper' but forgets to update '.gitignore' accordingly, our CI builds would catch it in a timely manner [2]. Ignoring everything but sources has the drawback that building an older version of Git (e.g. during bisecting) creates all those executables, and after going back to e.g. current 'master' the usual cleanup commands like 'make clean' or 'git clean -fd' don't remove them (the former doesn't know about them, and the latter doesn't remove ignored files). So let's ignore only the executable files under 't/helper/, i.e. 'test-tool' and the three other remaining executables that could not be integrated into 'test-tool' (no need to ignore object files, as they are already ignored by our toplevel '.gitignore'). [1] The topic starting with efd71f8913 (t/helper: add an empty test-tool program, 2018-03-24), and leading up to the merge commit 27f25845cf (Merge branch 'nd/combined-test-helper', 2018-04-11). [2] b92cb86ea1 (travis-ci: check that all build artifacts are .gitignore-d, 2017-12-31) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18test_date.c: remove reference to GIT_TEST_DATE_NOWLibravatar Stephen P. Smith1-1/+0
Remove the reference to the GIT_TEST_DATE_NOW which is done in date.c. We can't get rid of the "x" variable, since it serves as a generic scratch variable for parsing later in the function. Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-17Test the progress displayLibravatar SZEDER Gábor3-0/+83
'progress.c' has seen a few fixes recently [1], and, unfortunately, some of those fixes required further fixes [2]. It seems it's time to have a few tests focusing on the subtleties of the progress display. Add the 'test-tool progress' subcommand to help testing the progress display, reading instructions from standard input and turning them into calls to the display_progress() and display_throughput() functions with the given parameters. The progress display is, however, critically dependent on timing, because it's only updated once every second or, if the toal is known in advance, every 1%, and there is the throughput rate as well. These make the progress display far too undeterministic for testing as-is. To address this, add a few testing-specific variables and functions to 'progress.c', allowing the the new test helper to: - Disable the triggered-every-second SIGALRM and set the 'progress_update' flag explicitly based in the input instructions. This way the progress line will be updated deterministically when the test wants it to be updated. - Specify the time elapsed since start_progress() to make the throughput rate calculations deterministic. Add the new test script 't0500-progress-display.sh' to check a few simple cases with and without throughput, and that a shorter progress line properly covers up the previously displayed line in different situations. [1] See commits 545dc345eb (progress: break too long progress bar lines, 2019-04-12) and 9f1fd84e15 (progress: clear previous progress update dynamically, 2019-04-12). [2] 1aed1a5f25 (progress: avoid empty line when breaking the progress line, 2019-05-19) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12Quit passing 'now' to date codeLibravatar Stephen P. Smith1-17/+9
Commit b841d4ff43 (Add `human` format to test-tool, 2019-01-28) added a get_time() function which allows $GIT_TEST_DATE_NOW in the environment to override the current time. So we no longer need to interpret that variable in cmd__date(). Therefore, we can stop passing the "now" parameter down through the date functions, since nobody uses them. Note that we do need to make sure all of the previous callers that took a "now" parameter are correctly using get_time(). Signed-off-by: Stephen P. Smith <ischis2@cox.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-06test-read-cache: drop namelen variableLibravatar Jeff King1-3/+2
Early in the function we set "namelen = strlen(name)" if "name" is non-NULL. Later, we use "namelen" only if "name" is non-NULL. However, it's hard to immediately see this, and it seems to confuse gcc 9.2.1 (with "-flto" interestingly, though all of the involved logic is in inline functions; it also triggers when building with ASan). Let's simplify the code and remove the variable entirely. There's only one use of namelen anyway, so we can just call strlen() then. It's true this is in a loop, so we might execute strlen() more often. But: - this is test code that only ever loops twice in our test suite (we do loop 1000 times in a t/perf test, but without using this option). - a decent compiler ought to be able to hoist that out of the loop anyway (though I wouldn't count on gcc 9.2.1 doing so!) Reported-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
2019-08-07test-dir-iterator: use path argument directlyLibravatar René Scharfe1-3/+1
Avoid allocating and leaking a strbuf for holding a verbatim copy of the path argument and pass the latter directly to dir_iterator_begin() instead. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-01Merge branch 'jc/dir-iterator-test-fix'Libravatar Junio C Hamano1-1/+10
* jc/dir-iterator-test-fix: test-dir-iterator: do not assume errno values
2019-07-30test-dir-iterator: do not assume errno valuesLibravatar Junio C Hamano1-1/+10
A few tests printed 'errno' as an integer and compared with hardcoded integers; this is obviously not portable. A two things to note are: - the string obtained by strerror() is not portable, and cannot be used for the purpose of these tests. - there unfortunately isn't a portable way to map error numbers to error names. As we only care about a few selected errors, just map the error number to the name before emitting for comparison. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-25Merge branch 'mt/dir-iterator-updates'Libravatar Junio C Hamano3-0/+60
Adjust the dir-iterator API and apply it to the local clone optimization codepath. * mt/dir-iterator-updates: clone: replace strcmp by fspathcmp clone: use dir-iterator to avoid explicit dir traversal clone: extract function from copy_or_link_directory clone: copy hidden paths at local clone dir-iterator: add flags parameter to dir_iterator_begin dir-iterator: refactor state machine model dir-iterator: use warning_errno when possible dir-iterator: add tests for dir-iterator API clone: better handle symlinked files at .git/objects/ clone: test for our behavior on odd objects/* content
2019-07-19Merge branch 'nd/tree-walk-with-repo'Libravatar Junio C Hamano1-1/+1
The tree-walk API learned to pass an in-core repository instance throughout more codepaths. * nd/tree-walk-with-repo: t7814: do not generate same commits in different repos Use the right 'struct repository' instead of the_repository match-trees.c: remove the_repo from shift_tree*() tree-walk.c: remove the_repo from get_tree_entry_follow_symlinks() tree-walk.c: remove the_repo from get_tree_entry() tree-walk.c: remove the_repo from fill_tree_descriptor() sha1-file.c: remove the_repo from read_object_with_reference()
2019-07-19Merge branch 'cc/test-oidmap'Libravatar Junio C Hamano4-8/+115
Extend the test coverage a bit. * cc/test-oidmap: t0016: add 'remove' subcommand test test-oidmap: remove 'add' subcommand test-hashmap: remove 'hash' command oidmap: use sha1hash() instead of static hash() function t: add t0016-oidmap.sh t/helper: add test-oidmap.c
2019-07-11dir-iterator: add flags parameter to dir_iterator_beginLibravatar Matheus Tavares1-7/+27
Add the possibility of giving flags to dir_iterator_begin to initialize a dir-iterator with special options. Currently possible flags are: - DIR_ITERATOR_PEDANTIC, which makes dir_iterator_advance abort immediately in the case of an error, instead of keep looking for the next valid entry; - DIR_ITERATOR_FOLLOW_SYMLINKS, which makes the iterator follow symlinks and include linked directories' contents in the iteration. These new flags will be used in a subsequent patch. Also add tests for the flags' usage and adjust refs/files-backend.c to the new dir_iterator_begin signature. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-11dir-iterator: refactor state machine modelLibravatar Matheus Tavares1-0/+5
dir_iterator_advance() is a large function with two nested loops. Let's improve its readability factoring out three functions and simplifying its mechanics. The refactored model will no longer depend on level.initialized and level.dir_state to keep track of the iteration state and will perform on a single loop. Also, dir_iterator_begin() currently does not check if the given string represents a valid directory path. Since the refactored model will have to stat() the given path at initialization, let's also check for this kind of error and make dir_iterator_begin() return NULL, on failures, with errno appropriately set. And add tests for this new behavior. Improve documentation at dir-iteration.h and code comments at dir-iterator.c to reflect the changes and eliminate possible ambiguities. Finally, adjust refs/files-backend.c to check for now possible dir_iterator_begin() failures. Original-patch-by: Daniel Ferreira <bnmvco@gmail.com> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-11dir-iterator: add tests for dir-iterator APILibravatar Daniel Ferreira3-0/+35
Create t/helper/test-dir-iterator.c, which prints relevant information about a directory tree iterated over with dir-iterator. Create t/t0066-dir-iterator.sh, which tests that dir-iterator does iterate through a whole directory tree as expected. Signed-off-by: Daniel Ferreira <bnmvco@gmail.com> [matheus.bernardino: update to use test-tool and some minor aesthetics] Helped-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-01test-oidmap: remove 'add' subcommandLibravatar Christian Couder1-15/+1
The 'add' subcommand is useless as it is mostly identical to the 'put' subcommand, so let's remove it. Helped-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-27match-trees.c: remove the_repo from shift_tree*()Libravatar Nguyễn Thái Ngọc Duy1-1/+1
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-20object: convert lookup_unknown_object() to use object_idLibravatar Jeff King1-3/+3
There are no callers left of lookup_unknown_object() that aren't just passing us the "hash" member of a "struct object_id". Let's take the whole struct, which gets us closer to removing all raw sha1 variables. It also matches the existing conversions of lookup_blob(), etc. The conversions of callers were done by hand, but they're all mechanical one-liners. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-17test-hashmap: remove 'hash' commandLibravatar Christian Couder1-8/+1
If hashes like strhash() are updated, for example to use a different hash algorithm, we should not have to be updating t0011 to change out the hashes. As long as hashmap can store and retrieve values, and that it performs well, we should not care what are the values of the hashes. Let's just focus on the externally visible behavior instead. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-17t/helper: add test-oidmap.cLibravatar Christian Couder3-0/+128
This new helper is very similar to "test-hashmap.c" and will help test how `struct oidmap` from oidmap.{c,h} can be used. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-19Merge branch 'js/fsmonitor-refresh-after-discarding-index'Libravatar Junio C Hamano1-1/+23
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 'nd/parse-options-aliases'Libravatar Junio C Hamano1-0/+3
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-09Merge branch 'js/misc-doc-fixes'Libravatar Junio C Hamano3-0/+52
"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-08fsmonitor: demonstrate that it is not refreshed after discard_index()Libravatar Johannes Schindelin1-1/+23
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-07parse-options: don't emit "ambiguous option" for aliasesLibravatar Nguyễn Thái Ngọc Duy1-0/+3
Change the option parsing machinery so that e.g. "clone --recurs ..." doesn't error out because "clone" understands both "--recursive" and "--recurse-submodules" to mean the same thing. Initially "clone" just understood --recursive until the --recurses-submodules alias was added in ccdd3da652 ("clone: Add the --recurse-submodules option as alias for --recursive", 2010-11-04). Since bb62e0a99f ("clone: teach --recurse-submodules to optionally take a pathspec", 2017-03-17) the longer form has been promoted to the default. But due to the way the options parsing machinery works this resulted in the rather absurd situation of: $ git clone --recurs [...] error: ambiguous option: recurs (could be --recursive or --recurse-submodules) Add OPT_ALIAS() to express this link between two or more options and use it in git-clone. Multiple aliases of an option could be written as OPT_ALIAS(0, "alias1", "original-name"), OPT_ALIAS(0, "alias2", "original-name"), ... The current implementation is not exactly optimal in this case. But we can optimize it when it becomes a problem. So far we don't even have two aliases of any option. A big chunk of code is actually from Junio C Hamano. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25Merge branch 'jk/xmalloc'Libravatar Junio C Hamano1-1/+1
The code is updated to check the result of memory allocation before it is used in more places, by using xmalloc and/or xcalloc calls. * jk/xmalloc: progress: use xmalloc/xcalloc xdiff: use xmalloc/xrealloc xdiff: use git-compat-util test-prio-queue: use xmalloc
2019-04-25Merge branch 'js/difftool-no-index'Libravatar Junio C Hamano1-1/+1
"git difftool" can now run outside a repository. * js/difftool-no-index: difftool: allow running outside Git worktrees with --no-index parse-options: make OPT_ARGUMENT() more useful difftool: remove obsolete (and misleading) comment
2019-04-19Turn `git serve` into a test helperLibravatar Johannes Schindelin3-0/+33
The `git serve` built-in was introduced in ed10cb952d31 (serve: introduce git-serve, 2018-03-15) as a backend to serve Git protocol v2, probably originally intended to be spawned by `git upload-pack`. However, in the version that the protocol v2 patches made it into core Git, `git upload-pack` calls the `serve()` function directly instead of spawning `git serve`; The only reason in life for `git serve` to survive as a built-in command is to provide a way to test the protocol v2 functionality. Meaning that it does not even have to be a built-in that is installed with end-user facing Git installations, but it can be a test helper instead. Let's make it so. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-19test-tool: handle the `-C <directory>` option just like `git`Libravatar Johannes Schindelin1-0/+19
In preparation for moving `git serve` into `test-tool` (because it really is only used by the test suite), we teach the `test-tool` the useful trick to change the working directory before running the test command, which will avoid introducing subshells in the test code. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-12test-prio-queue: use xmallocLibravatar Jeff King1-1/+1
test-prio-queue.c doesn't check the return value of malloc, and could segfault. It's unlikely for this to matter in practice; it's a small allocation, and this code isn't even installed alongside the rest of Git. But let's use xmalloc(), which makes auditing for other accidental uses of bare malloc() easier. Reported-by: 王健强 <jianqiang.wang@securitygossip.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-20test-date: drop unused "now" parameter from parse_dates()Libravatar Jeff King1-2/+2
We only need the current time for relative dates like "5 minutes ago", and those are parsed only through approxidate, not the strict parser used by parse_dates(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>