Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-04-14revisions API: have release_revisions() release "cmdline"Ævar Arnfjörð Bjarmason
Extend the the release_revisions() function so that it frees the "cmdline" in the "struct rev_info". This in combination with a preceding change to free "commits" and "mailmap" means that we can whitelist another test under "TEST_PASSES_SANITIZE_LEAK=true". There was a proposal in [1] to do away with xstrdup()-ing this add_rev_cmdline(), perhaps that would be worthwhile, but for now let's just free() it. We could also make that a "char *" in "struct rev_cmdline_entry" itself, but since we own it let's expose it as a constant to outside callers. I proposed that in [2] but have since changed my mind. See 14d30cdfc04 (ref-filter: fix memory leak in `free_array_item()`, 2019-07-10), c514c62a4fd (checkout: fix leak of non-existent branch names, 2020-08-14) and other log history hits for "free((char *)" for prior art. This includes the tests we had false-positive passes on before my 6798b08e848 (perl Git.pm: don't ignore signalled failure in _cmd_close(), 2022-02-01), now they pass for real. Since there are 66 tests matching t/t[0-9]*git-svn*.sh it's easier to list those that don't pass than to touch most of those 66. So let's introduce a "TEST_FAILS_SANITIZE_LEAK=true", which if set in the tests won't cause lib-git-svn.sh to set "TEST_PASSES_SANITIZE_LEAK=true. This change also marks all the tests that we removed "TEST_FAILS_SANITIZE_LEAK=true" from in an earlier commit due to removing the UNLEAK() from cmd_format_patch(), we can now assert that its API use doesn't leak any "struct rev_info" memory. This change also made commit "t5503-tagfollow.sh" pass on current master, but that would regress when combined with ps/fetch-atomic-fixup's de004e848a9 (t5503: simplify setup of test which exercises failure of backfill, 2022-03-03) (through no fault of that topic, that change started using "git clone" in the test, which has an outstanding leak). Let's leave that test out for now to avoid in-flight semantic conflicts. 1. https://lore.kernel.org/git/YUj%2FgFRh6pwrZalY@carlos-mbp.lan/ 2. https://lore.kernel.org/git/87o88obkb1.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13t5000-t5999: detect and signal failure within loopEric Sunshine
Failures within `for` and `while` loops can go unnoticed if not detected and signaled manually since the loop itself does not abort when a contained command fails, nor will a failure necessarily be detected when the loop finishes since the loop returns the exit code of the last command it ran on the final iteration, which may not be the command which failed. Therefore, detect and signal failures manually within loops using the idiom `|| return 1` (or `|| exit 1` within subshells). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13tests: fix broken &&-chains in `{...}` groupsEric Sunshine
The top-level &&-chain checker built into t/test-lib.sh causes tests to magically exit with code 117 if the &&-chain is broken. However, it has the shortcoming that the magic does not work within `{...}` groups, `(...)` subshells, `$(...)` substitutions, or within bodies of compound statements, such as `if`, `for`, `while`, `case`, etc. `chainlint.sed` partly fills in the gap by catching broken &&-chains in `(...)` subshells, but bugs can still lurk behind broken &&-chains in the other cases. Fix broken &&-chains in `{...}` groups in order to reduce the number of possible lurking bugs. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-12-13tests: simplify construction of large blocks of textEric Sunshine
Take advantage of here-docs to create large blocks of text rather than using a series of `echo` statements. Not only are here-docs a natural fit for such a task, but there is less opportunity for a broken &&-chain. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-03t5515: use `main` as the name of the main branch for testing (conclusion)Johannes Schindelin
In the previous three commits, We prepared the `t5515` script and the files in `t/t5515/` for the upcoming change of the default branch name to `main`. The changes were made over the course of three commits because the overall patch would have been too big to send to the Git mailing list for review. Naturally, the test could not pass in the transitional stages and was therefore disabled via the `PREPARE_FOR_MAIN_BRANCH` prereq. Now that the transition is complete, we can re-enable it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-03t5515: use `main` as the name of the main branch for testing (part 1)Johannes Schindelin
As part of the effort to change the default branch name to `main`, let's prepare t5515. In addition to adjusting the references to the branch name itself, this also requires two commit hashes to be adjusted (actually four, as there is a SHA-1 _and_ a SHA-256 of both). That trick was performed by running sed -i -e 's/master/main/g' -e 's/Master/Main/g' \ -e 's/6c9dec2b923228c9ff994c6cfe4ae16c12408dc5/ecf3b3627b498bdcb735cc4343bf165f76964e9a/g' \ -e 's/8521c3072461fcfe8f32d67f95cc6e6b832a2db2fa29769ffc788bce85ebcd75/fff666109892bb4b1c80cd1649d2d8762a0663db8b5d46c8be98360b64fbba5f/g' \ -e 's/754b754407bf032e9a2f9d5a9ad05ca79a6b228f/b4ab76b1a01ea602209932134a44f1e6bd610832/g' \ -e 's/6c7abaea8a6d8ef4d89877e68462758dc6774690fbbbb0e6d7dd57415c9abde0/380ebae0113f877ce46fcdf39d5bc33e4dc0928db5c5a4d5fdc78381c4d55ae3/g' \ -- t/t5515-*.sh These commit hashes have been determined manually, of course, by running the test after adjusting only the branch names, and then copying the hashes from the log of the failed run. Note: this patch only touches the t5515 script so far, not the supporting material in t/t5515/. The resulting patch would have weighed over 100kB and therefore the Git mailing list would have dropped it. The files in t/t5515/ will be adjusted in the next two commits. As t5515 would fail without these adjustments, we temporarily skip it via the `PREPARE_FOR_MAIN_BRANCH` prereq. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27tests: avoid variations of the `master` branch nameJohannes Schindelin
The term `master` has a loaded history that serves as a constant reminder of racial injustice. The Git project has no desire to perpetuate this and already started avoiding it. The test suite uses variations of this name for branches other than the default one. Apart from t3200, where we just addressed this in the previous commit, those instances can be renamed in an automated manner because they do not require any changes outside of the test script, so let's do that. Seeing as the touched branches have very little (if anything) to do with the default branch, we choose to use a completely separate naming scheme: `topic_<number>` (it cannot be `topic-<number>` because t5515 uses the `test_oid` machinery with the term, and that machinery uses shell variables internally, whose names cannot contain dashes). This trick was performed by this (GNU) sed invocation: $ sed -i 's/master\([a-z0-9]\)/topic_\1/g' t/t*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-18Merge branch 'bc/hash-independent-tests-part-8'Junio C Hamano
Preparation for SHA-256 migration continues. * bc/hash-independent-tests-part-8: (21 commits) t6024: update for SHA-256 t6006: make hash size independent t6000: abstract away SHA-1-specific constants t5703: make test work with SHA-256 t5607: make hash size independent t5318: update for SHA-256 t5515: make test hash independent t5321: make test hash independent t5313: make test hash independent t5309: make test hash independent t5302: make hash size independent t4060: make test work with SHA-256 t4211: add test cases for SHA-256 t4211: move SHA-1-specific test cases into a directory t4013: make test hash independent t3311: make test work with SHA-256 t3310: make test work with SHA-256 t3309: make test work with SHA-256 t3308: make test work with SHA-256 t3206: make hash size independent ...
2020-02-07t5515: make test hash independentbrian m. carlson
This test contains a large number of data files, mostly using the same object ID values for refs. Instead of producing two separate sets of test files, keep the test files using SHA-1 and translate them on the fly by replacing the SHA-1 values with the values for the current hash algorithm in use. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-16test: request GIT_TEST_PROTOCOL_VERSION=0 when appropriateJonathan Nieder
Since 8cbeba0632 (tests: define GIT_TEST_PROTOCOL_VERSION, 2019-02-25), it has been possible to run tests with a newer protocol version by setting the GIT_TEST_PROTOCOL_VERSION envvar to a version number. Tests that assume protocol v0 handle this by explicitly setting GIT_TEST_PROTOCOL_VERSION= or similar constructs like 'test -z "$GIT_TEST_PROTOCOL_VERSION" || return 0' to declare that they only handle the default (v0) protocol. The emphasis there is a bit off: it would be clearer to specify GIT_TEST_PROTOCOL_VERSION=0 to inform the reader that these tests are specifically testing and relying on details of protocol v0. Do so. This way, a reader does not need to know what the default protocol version is, and the tests can continue to work when the default protocol version used by Git advances past v0. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05t: use LF variable defined in the test harnessJunio C Hamano
A few test scripts assign a single LF to $LF, but that is already given by test-lib.sh to everybody. Remove the unnecessary reassignment. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07tests: fix protocol version for overspecificationsJonathan Tan
These tests are also marked with a NEEDSWORK comment. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-29t/t5515-fetch-merge-logic.sh: use the $( ... ) construct for command ↵Elia Pinto
substitution The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-19test-lib: Simplify test counting.Johannes Sixt
Since the test case counter was incremented very late, there were a few users of the counter had to do their own incrementing. Now we increment it early and simplify these users. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2008-08-17tests: use $TEST_DIRECTORY to refer to the t/ directoryJunio C Hamano
Many test scripts assumed that they will start in a 'trash' subdirectory that is a single level down from the t/ directory, and referred to their test vector files by asking for files like "../t9999/expect". This will break if we move the 'trash' subdirectory elsewhere. To solve this, we earlier introduced "$TEST_DIRECTORY" so that they can refer to t/ directory reliably. This finally makes all the tests use it to refer to the outside environment. With this patch, and a one-liner not included here (because it would contradict with what Dscho really wants to do): | diff --git a/t/test-lib.sh b/t/test-lib.sh | index 70ea7e0..60e69e4 100644 | --- a/t/test-lib.sh | +++ b/t/test-lib.sh | @@ -485,7 +485,7 @@ fi | . ../GIT-BUILD-OPTIONS | | # Test repository | -test="trash directory" | +test="trash directory/another level/yet another" | rm -fr "$test" || { | trap - exit | echo >&5 "FATAL: Cannot prepare test area" all the tests still pass, but we would want extra sets of eyeballs on this type of change to really make sure. [jc: with help from Stephan Beyer on http-push tests I do not run myself; credits for locating silly quoting errors go to Olivier Marin.] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-20Prepare testsuite for a "git clone" that packs refsJohan Herland
t5515-fetch-merge-logic removes many, but not all, refs between each test. This is done by removing the corresponding refs/foo/* files in the .git/refs hierarchy. However, once "git clone" starts producing packed refs, these refs will no longer be in the .git/refs hierarchy, but rather listed in .git/packed-refs. This patch teaches t5515-fetch-merge-logic to remove the refs using "git update-ref -d" which properly handles packed refs. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24tests: do not use implicit "git diff --no-index"Junio C Hamano
As a general principle, we should not use "git diff" to validate the results of what git command that is being tested has done. We would not know if we are testing the command in question, or locating a bug in the cute hack of "git diff --no-index". Rather use test_cmp for that purpose. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-26git-fetch test: test tracking fetch results, not just FETCH_HEADJunio C Hamano
We really should have done this long time ago. Existing t5515 test was written for the specific purpose of catching regression to the contents of generated FETCH_HEAD file, but it also is a good place to make sure various fetch configurations do fetch what they intend to fetch (and nothing else). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-19Don't attempt to merge non-existant remotes in t5515Shawn O. Pearce
This was actually reverted in 756373da by Junio. We no longer support merging the right hand side of a fetchspec in a branch's branch.$name.merge configuration setting as we interpret these names as being only those published by the remote we are going to fetch from. The older shell based implementation of git-fetch did not report an error when branch.$name.merge was referencing a branch that does not exist on the remote and we are running `git fetch` for the current branch. The new builtin-fetch does notice this failure and aborts the fetch, thus breaking the tests. Junio and I kicked it around on #git earlier today and decided that the best approach here is to error out and tell the user that their configuration is wrong, as this is likely more user friendly than silently ignoring the user's request. Since the new builtin-fetch is already issuing the error there is no code change required, we just need to remove the bad configuration from our test. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-03-11Merge branch 'js/diff-ni'Junio C Hamano
* js/diff-ni: Get rid of the dependency to GNU diff in the tests diff --no-index: support /dev/null as filename diff-ni: fix the diff with standard input diff: support reading a file from stdin via "-"
2007-03-07t/t5515-fetch-merge-logic.sh: Add two more testsSanti B,Ai(Bjar
They test the behaviour with just a URL in the command line. Signed-off-by: Santi B,Ai(Bjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-05t/t5515-fetch-merge-logic.sh: Added tests for the merge login in git-fetchSanti Béjar
Signed-off-by: Santi Béjar <sbejar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>