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: call diff_free(&revs->pruning) in revisions_release()Ævar Arnfjörð Bjarmason
Call diff_free() on the "pruning" member of "struct rev_info". Doing so makes several tests pass under SANITIZE=leak. This was also the last missing piece that allows us to remove the UNLEAK() in "cmd_diff" and "cmd_diff_index", which allows us to use those commands as a canary for general leaks in the revisions API. See [1] for further rationale, and 886e1084d78 (builtin/: add UNLEAKs, 2017-10-01) for the commit that added the UNLEAK() there. 1. https://lore.kernel.org/git/220218.861r00ib86.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-03-08tests: change some 'test $(git) = "x"' to test_cmpÆvar Arnfjörð Bjarmason
Change some of the patterns in the test suite where we were hiding the exit code from "git" by invoking it in a sub-shell within a "test" expression to use temporary files and test_cmp instead. These are not all the occurrences of this anti-pattern, but these in particular hid issues where LSAN was dying, and I'd thus marked these tests as passing under the linux-leaks CI job in past commits with "TEST_PASSES_SANITIZE_LEAK=true". Let's deal with that by either removing that marking, or skipping specific tests under !SANITIZE_LEAK. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-01-04Merge branch 'es/test-chain-lint'Junio C Hamano
Broken &&-chains in the test scripts have been corrected. * es/test-chain-lint: t6000-t9999: detect and signal failure within loop t5000-t5999: detect and signal failure within loop t4000-t4999: detect and signal failure within loop t0000-t3999: detect and signal failure within loop tests: simplify by dropping unnecessary `for` loops tests: apply modern idiom for exiting loop upon failure tests: apply modern idiom for signaling test failure tests: fix broken &&-chains in `{...}` groups tests: fix broken &&-chains in `$(...)` command substitutions tests: fix broken &&-chains in compound statements tests: use test_write_lines() to generate line-oriented output tests: simplify construction of large blocks of text t9107: use shell parameter expansion to avoid breaking &&-chain t6300: make `%(raw:size) --shell` test more robust t5516: drop unnecessary subshell and command invocation t4202: clarify intent by creating expected content less cleverly t1020: avoid aborting entire test script when one test fails t1010: fix unnoticed failure on Windows t/lib-pager: use sane_unset() to avoid breaking &&-chain
2021-12-13t0000-t3999: 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: fix broken &&-chains in compound statementsEric 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 compound statements 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-11-01leak tests: mark some add tests as passing with SANITIZE=leakÆvar Arnfjörð Bjarmason
Mark some tests that match "*add*" as passing when git is compiled with SANITIZE=leak. They'll now be listed as running under the "GIT_TEST_PASSING_SANITIZE_LEAK=true" test mode (the "linux-leaks" CI target). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12add: don't write objects with --dry-runRené Scharfe
When the option --dry-run/-n is given, "git add" doesn't change the index, but still writes out new object files. Only hash the latter without writing instead to make the run as dry as possible. Use this opportunity to also make the hash_flags variable unsigned, to match the index_path() parameter it is used as. Reported-by: git.mexon@spamgourmet.com Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-11tests: remove most uses of test_i18ncmpÆvar Arnfjörð Bjarmason
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving t6300-for-each-ref.sh out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-18t2200,t9832: avoid using 'git' upstream in a pipeAmanda Shafack
Avoid placing `git` upstream in a pipe since doing so throws away its exit code, thus an unexpected failure may go unnoticed. Signed-off-by: Amanda Shafack <shafack.likhene@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'SZEDER Gábor
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-25add: simplify -u/-A without pathspecJunio C Hamano
Since Git 2.0, "add -u" and "add -A" run from a subdirectory without any pathspec mean "everything in the working tree" (before 2.0, they were limited to the current directory). The limiting to the current directory was implemented by inserting "." to the command line when the end user did not give us any pathspec. At 2.0, we updated the code to insert ":/" (instead of '.') to consider everything from the top-level, by using a pathspec magic "top". The call to parse_pathspec() using the command line arguments is, however, made with PATHSPEC_PREFER_FULL option since 5a76aff1 (add: convert to use parse_pathspec, 2013-07-14), which predates Git 2.0. In retrospect, there was no need to turn "adding . to limit to the directory" into "adding :/ to unlimit to everywhere" in Git 2.0; instead we could just have done "if there is no pathspec on the command line, just let it be". The parse_pathspec() then would give us a pathspec that matches everything and all is well. Incidentally such a simplification also fixes a corner case bug that stems from the fact that ":/" does not necessarily mean any magic. A user would say "git --literal-pathspecs add -u :/" from the command line when she has a directory ':' and wants to add everything in it (and she knows that her :/ will be taken as 'everything under the sun' magic pathspec unless she disables the magic with --literal-pathspecs). The internal use of ':/' would behave the same way as such an explicitly given ":/" when run with "--literal-pathspecs", and will not add everything under the sun as the code originally intended. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-08Merge branch 'jn/add-2.0-u-A-sans-pathspec'Junio C Hamano
"git add -u" and "git add -A" without any pathspec is a tree-wide operation now, even when they are run in a subdirectory of the working tree.
2013-06-08tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)Johannes Sixt
There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where "trivial" means: - merely a replacement of 'ln -s a b && git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-27git add: -u/-A now affects the entire working treeJunio C Hamano
As promised in 0fa2eb530fb7 (add: warn when -u or -A is used without pathspec, 2013-01-28), in Git 2.0, "git add -u/-A" that is run without pathspec in a subdirectory updates all updated paths in the entire working tree, not just the current directory and its subdirectories. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22Merge branch 'jc/add-2.0-delete-default' (early part)Junio C Hamano
Preparatory steps to make "git add <pathspec>" take notice of removed paths that match <pathspec> by default in Git 2.0. * 'jc/add-2.0-delete-default' (early part): git add: rephrase the "removal will cease to be ignored" warning git add: rework the logic to warn "git add <pathspec>..." default change git add: start preparing for "git add <pathspec>..." to default to "-A" builtin/add.c: simplify boolean variables
2013-03-14t2200: check that "add -u" limits itself to subdirectoryJeff King
This behavior is due to change in the future, but let's test it anyway. That helps make sure we do not accidentally switch the behavior too soon while we are working in the area, and it means that we can easily verify the change when we do make it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-09git add: start preparing for "git add <pathspec>..." to default to "-A"Junio C Hamano
When "git add subdir/" is run without "-u" or "-A" option, e.g. $ edit subdir/x $ create subdir/y $ rm subdir/z $ git add subdir/ the command does not notice removal of paths (e.g. subdir/z) from the working tree. This sometimes confuses new people, as arguably "git add" is told to record the current state of "subdir/" as a whole, not the current state of the paths that exist in the working tree that matches that pathspec (the latter by definition excludes the state of "subdir/z" because it does not exist in the working tree). Plan to eventually make "git add" pretend as if "-A" is given when there is a pathspec on the command line. When resolving a conflict to remove a path, the current code tells you to "git rm $path", but with such a change, you will be able to say "git add $path" (of course you can do "git add -A $path" today). That means that we can simplify the advice messages given by "git status". That all will be in Git 2.0 or later, if we are going to do so. For that transition to work, people need to learn either to say "git add --no-all subdir/" when they want to ignore the removed paths like "subdir/z", or to say "git add -A subdir/" when they want to take the state of the directory as a whole. "git add" without any argument will continue to be a no-op. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-13Merge branch 'jc/fix-add-u-unmerged'Junio C Hamano
* jc/fix-add-u-unmerged: Fix "add -u" that sometimes fails to resolve unmerged paths
2011-04-24Fix "add -u" that sometimes fails to resolve unmerged pathsJunio C Hamano
"git add -u" updates the index with the updated contents from the working tree by internally running "diff-files" to grab the set of paths that are different from the index. Then it updates the index entries for the paths that are modified in the working tree, and deletes the index entries for the paths that are deleted in the working tree. It ignored the output from the diff-files that indicated that a path is unmerged. For these paths, it instead relied on the fact that an unmerged path is followed by the result of comparison between stage #2 (ours) and the working tree, and used that to update or delete such a path when it is used to record the resolution of a conflict. As the result, when a path did not have stage #2 (e.g. "we deleted while the other side added"), these unmerged stages were left behind, instead of recording what the user resolved in the working tree. Since we recently fixed "diff-files" to indicate if the corresponding path exists on the working tree for an unmerged path, we do not have to rely on the comparison with stage #2 anymore. We can instead tell the diff-files not to compare with higher stages, and use the unmerged output to update the index to reflect the state of the working tree. The changes to the test vector in t2200 illustrates the nature of the bug and the fix. The test expected stage #1 and #3 entries be left behind, but it was codifying the buggy behaviour. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-14i18n: use test_i18ncmp in t1200 and t2200Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10i18n: git-add "remove '%s'" messageÆvar Arnfjörð Bjarmason
Make the "remove '%s'" message translatable. It's displayed under `git add -u --verbose`. Also skip the corresponding test when output is not in the C locale. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Jonathan Nieder
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17test for add with non-existent pathspecChris Packham
Add a test for 'git add -u pathspec' and 'git add pathspec' where pathspec does not exist. The expected result is that git add exits with an error message and an appropriate exit code. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22Use prerequisite tags to skip tests that depend on symbolic linksJohannes Sixt
Many tests depend on that symbolic links work. This introduces a check that sets the prerequisite tag SYMLINKS if the file system supports symbolic links. Since so many tests have to check for this prerequisite, we do the check in test-lib.sh, so that we don't need to repeat the test in many scripts. To check for 'ln -s' failures, you can use a FAT partition on Linux: $ mkdosfs -C git-on-fat 1000000 $ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt Clone git to /mnt and $ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7 t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \ make test (These additionally skipped tests depend on POSIX permissions that FAT on Linux does not provide.) Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-03-19t2200, t7004: Avoid glob pattern that also matches filesJohannes Sixt
On Windows, there is an unfortunate interaction between the MSYS bash and git's command line processing: - Since Windows's CMD does not do the wildcard expansion, but passes arguments like path* through to the programs, the programs must do the expansion themselves. This happens in the startup code before main() is entered. - bash, however, passes the argument "path*" to git, assuming that git will see the unquoted word unchanged as a single argument. But actually git expands the unquoted word before main() is entered. In t2200, not all names that the test case is interested in exist as files at the time when 'git ls-files' is invoked. git expands "path?" to only the subset of files the exist, and only that subset was listed, so that the test failed. We now list all interesting paths explicitly. In t7004, git exanded the pattern "*a*" to "actual" (the file that stdout was redirected to), which is not what the was tested for. We fix it by renaming the output file (and removing any existing files matching *a*). This was originally fixed by Johannes Schindelin. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-01-29add -u: do not fail to resolve a path as deletedJunio C Hamano
After you resolve a conflicted merge to remove the path, "git add -u" failed to record the removal. Instead it errored out by saying that the removed path is not found in the work tree, but that is what the user already knows, and the wanted to record the removal as the resolution, so the error does not make sense. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03tests: use "git xyzzy" form (t0000 - t3599)Nanako Shiraishi
Converts tests between t0050-t3903. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21"git-add -n -u" should not add but just reportJunio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-13add test_cmp function for test scriptsJeff King
Many scripts compare actual and expected output using "diff -u". This is nicer than "cmp" because the output shows how the two differ. However, not all versions of diff understand -u, leading to unnecessary test failure. This adds a test_cmp function to the test scripts and switches all "diff -u" invocations to use it. The function uses the contents of "$GIT_TEST_CMP" to compare its arguments; the default is "diff -u". On systems with a less-capable diff, you can do: GIT_TEST_CMP=cmp make test Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12t2200: test more cases of "add -u"Junio C Hamano
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-15Add test to check recent fix to "git add -u"Benoit Sigoure
An earlier commit fixed type-change case in "git add -u". This adds a test to make sure we do not introduce regression. At the same time, it fixes a stupid typo in the error message. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-16Merge branch 'maint' to sync with 1.5.2.5Junio C Hamano
* maint: GIT 1.5.2.5 git-add -u paths... now works from subdirectory Fix "git add -u" data corruption.
2007-08-16git-add -u paths... now works from subdirectorySalikh Zakirov
git-add -u also takes the path limiters, but unlike the command without the -u option, the code forgot that it could be invoked from a subdirectory, and did not correctly handle the prefix. Signed-off-by: Salikh Zakirov <salikh@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-16Fix "git add -u" data corruption.Junio C Hamano
This applies to 'maint' to fix a rather serious data corruption issue. When "git add -u" affects a subdirectory in such a way that the only changes to its contents are path removals, the next tree object written out of that index was bogus, as the remove codepath forgot to invalidate the cache-tree entry. Reported by Salikh Zakirov. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03Rewrite "git-frotz" to "git frotz"Junio C Hamano
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-05-12git-add: allow path limiting with -uJeff King
Rather than updating all working tree paths, we limit ourselves to paths listed on the command line. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>