summaryrefslogtreecommitdiff
path: root/t/t3700-add.sh
AgeCommit message (Collapse)AuthorFilesLines
2018-08-20Merge branch 'ab/test-must-be-empty-for-master'Libravatar Junio C Hamano1-2/+1
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-07-30tests: make use of the test_must_be_empty functionLibravatar Ævar Arnfjörð Bjarmason1-2/+1
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t3000-t3999: fix broken &&-chainsLibravatar Eric Sunshine1-4/+4
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-27t/helper: merge test-chmtime into test-toolLibravatar 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>
2017-11-06Merge branch 'ex/deprecate-empty-pathspec-as-match-all'Libravatar Junio C Hamano1-3/+2
The final step to make an empty string as a pathspec element illegal. We started this by first deprecating and warning a pathspec that has such an element in 2.11 (Nov 2016). Hopefully we can merge this down to the 'master' by the end of the year? A deprecation warning period that is about 1 year does not sound too bad. * ex/deprecate-empty-pathspec-as-match-all: pathspec: die on empty strings as pathspec t0027: do not use an empty string as a pathspec element
2017-08-08t3700: fix broken test under !POSIXPERMLibravatar René Scharfe1-0/+1
76e368c378 (t3700: fix broken test under !SANITY) explains that the test 'git add --chmod=[+-]x changes index with already added file' can fail if xfoo3 is still present as a symlink from a previous test and deletes it with rm(1). That still leaves it present in the index, which causes the test to fail if POSIXPERM is not defined. Get rid of it by calling "git reset --hard" as well, as 76e368c378 already mentioned in passing. Helped-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23pathspec: die on empty strings as pathspecLibravatar Emily Xie1-3/+2
An empty string as a pathspec element matches all paths. A buggy script, however, could accidentally assign an empty string to a variable that then gets passed to a Git command invocation, e.g.: path=... compute a path to be removed in $path ... git rm -r "$path" which would unintentionally remove all paths in the current directory. The fix for this issue comprises of two steps. Step 1, which warns that empty strings as pathspecs will become invalid, has already been implemented in commit d426430 ("pathspec: warn on empty strings as pathspec", 2016-06-22). This patch is step 2. It removes the warning and throws an error instead. Signed-off-by: Emily Xie <emilyxxie@gmail.com> Reported-by: David Turner <novalis@novalis.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-26Merge branch 'ex/deprecate-empty-pathspec-as-match-all'Libravatar Junio C Hamano1-0/+5
An empty string used as a pathspec element has always meant 'everything matches', but it is too easy to write a script that finds a path to remove in $path and run 'git rm "$paht"', which ends up removing everything. Start warning about this use of an empty string used for 'everything matches' and ask users to use a more explicit '.' for that instead. The hope is that existing users will not mind this change, and eventually the warning can be turned into a hard error, upgrading the deprecation into removal of this (mis)feature. * ex/deprecate-empty-pathspec-as-match-all: pathspec: warn on empty strings as pathspec
2016-10-20t3700: fix broken test under !SANITYLibravatar Junio C Hamano1-0/+1
An "add --chmod=+x" test recently added by 610d55af0f ("add: modify already added files when --chmod is given", 2016-09-14) used "xfoo3" as a test file. The paths xfoo[1-3] were used by earlier tests for symbolic links but they were expected to have been removed by the time the execution reached this new test. The removal with "git reset --hard" however happened in a pair of earlier tests, both of which are protected by POSIXPERM,SANITY prerequisites. Platforms and test environments that lacked these would have seen xfoo3 as a leftover symbolic link that points at somewhere else at this point of the sequence, and the chmod test would have given a wrong result. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-21t3700-add: do not check working tree file mode without POSIXPERMLibravatar Johannes Sixt1-4/+2
A recently introduced test checks the result of 'git status' after setting the executable bit on a file. This check does not yield the expected result when the filesystem does not support the executable bit. What we care about is that a file added with "--chmod=+x" has executable bit in the index and that "--chmod=+x" (or any other options for that matter) does not muck with working tree files. The former is tested by other existing tests, so let's check the latter more explicitly and only under POSIXPERM prerequisite. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-21t3700-add: create subdirectory gentlyLibravatar Johannes Sixt1-1/+1
The subdirectory 'sub' is created early in the test file. Later, a test case removes it during its clean-up actions. However, this test case is protected by POSIXPERM. Consequently, 'sub' remains when the POSIXPERM prerequisite is not satisfied. Later, a recently introduced test case creates 'sub' again. Use -p with mkdir so that it does not fail if 'sub' already exists. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-15add: modify already added files when --chmod is givenLibravatar Thomas Gummerer1-0/+50
When the chmod option was added to git add, it was hooked up to the diff machinery, meaning that it only works when the version in the index differs from the version on disk. As the option was supposed to mirror the chmod option in update-index, which always changes the mode in the index, regardless of the status of the file, make sure the option behaves the same way in git add. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01t3700: add a test_mode_in_index helper functionLibravatar Ingo Brückl1-32/+22
The case statement to check the file mode of a staged file appears a number of times. Simplify the test by utilizing a test_mode_in_index helper function. Signed-off-by: Ingo Brückl <ib@wupperonline.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01t3700: merge two tests into oneLibravatar Ingo Brückl1-12/+6
Depending on the underlying platform a chmod may be a noop. Although it wouldn't harm the result of the '--chmod=-x' test, there is a more robust way to make sure the --chmod option works both ways. Merge the two separate tests for the --chmod option into one, checking both permissions on the same file. Signed-off-by: Ingo Brückl <ib@wupperonline.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-01t3700: remove unwanted leftover files before running new testsLibravatar Ingo Brückl1-0/+3
When an earlier test that has prerequisite is skipped, files used by later tests may be left in the working tree in an unexpected state. For example, a test runs this sequence: echo foo >xfoo1 && chmod 755 xfoo1 to create an executable file xfoo1, expecting that xfoo1 does not exist before it runs in the test sequence. However, the absence of this file depends on "git reset --hard" done in an earlier test, that is skipped when SANITY prerequisite is not met, and worse yet, xfoo1 originally is created as a symbolic link, which means the chmod does not affect the modes of xfoo1 as this test expects. Fix this by starting the test with "rm -f xfoo1" to make sure the file is created from scratch, and do the same to other similar tests. Signed-off-by: Ingo Brückl <ib@wupperonline.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-22pathspec: warn on empty strings as pathspecLibravatar Emily Xie1-0/+5
An empty string as a pathspec element matches all paths. A buggy script, however, could accidentally assign an empty string to a variable that then gets passed to a Git command invocation, e.g.: path=... compute a path to be removed in $path ... git rm -r "$paht" which would unintentionally remove all paths in the current directory. The fix for this issue requires a two-step approach. As there may be existing scripts that knowingly use empty strings in this manner, the first step simply gives a warning that (1) tells that an empty string will become an invalid pathspec element and (2) asks the user to use "." if they mean to match all. For step two, a follow-up patch several release cycles later will remove the warning and throw an error instead. This patch is the first step. Signed-off-by: Emily Xie <emilyxxie@gmail.com> Reported-by: David Turner <novalis@novalis.org> Mentored-by: Michail Denchev <mdenchev@gmail.com> Thanks-to: Sarah Sharp <sarah@thesharps.us> and James Sharp <jamey@minilop.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-07add: add --chmod=+x / --chmod=-x optionsLibravatar Edward Thomson1-0/+30
The executable bit will not be detected (and therefore will not be set) for paths in a repository with `core.filemode` set to false, though the users may still wish to add files as executable for compatibility with other users who _do_ have `core.filemode` functionality. For example, Windows users adding shell scripts may wish to add them as executable for compatibility with users on non-Windows. Although this can be done with a plumbing command (`git update-index --add --chmod=+x foo`), teaching the `git-add` command allows users to set a file executable with a command that they're already familiar with. Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-28t/t3700-add.sh: use the $( ... ) construct for command substitutionLibravatar Elia Pinto1-8/+8
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>
2014-11-21add: ignore only ignored filesLibravatar Michael J Gruber1-1/+7
"git add foo bar" adds neither foo nor bar when bar is ignored, but dies to let the user recheck their command invocation. This becomes less helpful when "git add foo.*" is subject to shell expansion and some of the expanded files are ignored. "git add --ignore-errors" is supposed to ignore errors when indexing some files and adds the others. It does ignore errors from actual indexing attempts, but does not ignore the error "file is ignored" as outlined above. This is unexpected. Change "git add foo bar" to add foo when bar is ignored, but issue a warning and return a failure code as before the change. That is, in the case of trying to add ignored files we now act the same way (with or without "--ignore-errors") in which we act for more severe indexing errors when "--ignore-errors" is specified. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-26add: don't complain when adding empty project rootLibravatar Nguyễn Thái Ngọc Duy1-0/+19
This behavior was added in 07d7bed (add: don't complain when adding empty project root - 2009-04-28) then broken by 84b8b5d (remove match_pathspec() in favor of match_pathspec_depth() - 2013-07-14). Reinstate it. Noticed-by: Thomas Ferris Nicolaisen <tfnico@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-07tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)Libravatar Johannes Sixt1-9/+6
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>
2012-02-17refresh_index: do not show unmerged path that is outside pathspecLibravatar Junio C Hamano1-0/+15
When running "git add --refresh <pathspec>", we incorrectly showed the path that is unmerged even if it is outside the specified pathspec, even though we did honor pathspec and refreshed only the paths that matched. Note that this cange does not affect "git update-index --refresh"; for hysterical raisins, it does not take a pathspec (it takes real paths) and more importantly itss command line options are parsed and executed one by one as they are encountered, so "git update-index --refresh foo" means "first refresh the index, and then update the entry 'foo' by hashing the contents in file 'foo'", not "refresh only entry 'foo'". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014Libravatar Junio C Hamano1-5/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-add "did not match any files" messageLibravatar Ævar Arnfjörð Bjarmason1-2/+6
Make the "did not match any files" message translatable, and skip the test that checks for it when the C_LOCALE_OUTPUT prereq is not present. 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>
2011-03-09i18n: git-add "The following paths are ignored" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+4
The tests t2204 (.gitignore) and t3700 (add) explicitly check for these messages, so while at it, split each relevant test into a part that just checks "git add"'s exit status and a part that checks porcelain output. 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-08-18tests: A SANITY test prereq for testing if we're rootLibravatar Ævar Arnfjörð Bjarmason1-5/+5
Some tests depend on not being able to write to files after chmod -w. This doesn't work when running the tests as root. Change test-lib.sh to test if this works, and if so it sets a new SANITY test prerequisite. The tests that use this previously failed when run under root. There was already a test for this in t3600-rm.sh, added by Junio C Hamano in 2283645 in 2006. That check now uses the new SANITY prerequisite. Some of this was resurrected from the "Tests in Cygwin" thread in May 2009: http://thread.gmane.org/gmane.comp.version-control.git/116729/focus=118385 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-25t3700-add: fix dependence on stdout and stderr bufferingLibravatar Johannes Sixt1-3/+6
One test case checked the stdout and stderr of 'git add' by constructing a single 'expect' file that contained both streams. But when the command runs, the order of stdout and stderr output is unpredictable because it depends on how the streams are buffered. At least on Windows, the buffering is different from what the test case expected. Hence, check the two output texts separately. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-20t/t3700: convert two uses of negation operator '!' to use test_must_failLibravatar Brandon Casey1-2/+2
These two lines use the negation '!' operator to negate the result of a simple command. Since these commands do not contain any pipes or other complexities, the test_must_fail function can be used and is preferred since it will additionally detect termination due to a signal. This was noticed because the second use of '!' does not include a space between the '!' and the opening parens. Ksh interprets this as follows: !(pattern-list) Matches anything except one of the given patterns. Ksh performs a file glob using the pattern-list and then tries to execute the first file in the list. If a space is added between the '!' and the open parens, then Ksh will not interpret it as a pattern list, but in this case, it is preferred to use test_must_fail, so lets do so. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-12git add: Add the "--ignore-missing" option for the dry runLibravatar Jens Lehmann1-0/+25
Sometimes it is useful to know if a file or directory will be ignored before it is added to the work tree. An example is "git submodule add", where it would be really nice to be able to fail with an appropriate error message before the submodule is cloned and checked out. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25tests: Say "pass" rather than "ok" on empty lines for TAPLibravatar Ævar Arnfjörð Bjarmason1-6/+6
Lines that begin with "ok" confuse the TAP harness because it can't distinguish them from a test counter. Work around the issue by saying "pass" instead, which isn't a reserved TAP word. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-16test for add with non-existent pathspecLibravatar Chris Packham1-0/+5
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-06-22Merge branch 'maint'Libravatar Junio C Hamano1-1/+1
* maint: t3700-add: add a POSIXPERM prerequisite to a new test
2009-06-22t3700-add: add a POSIXPERM prerequisite to a new testLibravatar Johannes Sixt1-1/+1
The new test does a 'chmod 0', which does not have the intended effect on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-22Merge branch 'sb/maint-1.6.0-add-config-fix' into maintLibravatar Junio C Hamano1-0/+13
* sb/maint-1.6.0-add-config-fix: add: allow configurations to be overriden by command line
2009-06-20Merge branch 'sb/maint-1.6.0-add-config-fix'Libravatar Junio C Hamano1-0/+13
* sb/maint-1.6.0-add-config-fix: add: allow configurations to be overriden by command line use xstrdup, not strdup in ll-merge.c Conflicts: builtin-add.c
2009-06-18add: allow configurations to be overriden by command lineLibravatar Stephen Boyd1-0/+13
Don't call git_config after parsing the command line options, otherwise the config settings will override any settings made by the command line. This can be seen by setting add.ignore_errors and then specifying --no-ignore-errors when using git-add. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31git-add: no need for -f when resolving a conflict in already tracked pathLibravatar Jeff King1-0/+12
When a path F that matches ignore pattern has a conflict, "git add F" insisted the -f option be given, which did not make sense. It would have required -f when the path was originally added, but when resolving a conflict, it already is tracked. So this should work (and does): $ echo file >.gitignore $ echo content >file $ git add -f file ;# need -f because we are adding new path $ echo more content >>file $ git add file ;# don't need -f; it is not actually an "other" file This is handled under the hood by the COLLECT_IGNORED option to read_directory. When that code finds an ignored file, it checks the index to make sure it is not actually a tracked file. However, the test it uses does not take into account unmerged entries, and considers them to still be ignored. "git ls-files" uses a more elaborate test and gets the right answer and the same test should be used here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22t3700: Skip a test with backslashes in pathspecLibravatar Johannes Sixt1-1/+1
The test verifies that glob special characters can be escaped with backslashes. In particular, the string fo\[ou\]bar is given to git. On Windows, this does not work because backslashes are first of all directory separators, and first thing git does with a pathspec from the command line is to convert backslashes to forward slashes. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-03-22Skip tests that require a filesystem that obeys POSIX permissionsLibravatar Johannes Sixt1-4/+4
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-03-22Use prerequisite tags to skip tests that depend on symbolic linksLibravatar Johannes Sixt1-3/+3
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>
2008-09-30tests: grep portability fixesLibravatar Jeff King1-1/+1
We try to avoid using the "-q" or "-e" options, as they are largely useless, as explained in aadbe44f. There is one exception for "-e" here, which is in t7701 used to produce an "or" of patterns. This can be rewritten as an egrep pattern. This patch also removes use of "grep -F" in favor of the more widely available "fgrep". [sp: Tested on AIX 5.3 by Mike Ralphson, Tested on MinGW by Johannes Sixt] Signed-off-by: Jeff King <peff@peff.net> Tested-by: Mike Ralphson <mike@abacus.co.uk> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-08-15Fix t3700 on filesystems which do not support question marks in namesLibravatar Alex Riesen1-4/+4
Use square brackets instead. And the prominent example of the deficiency are, as usual, the filesystems of Microsoft house. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-13Merge branch 'maint'Libravatar Junio C Hamano1-0/+8
* maint: t5304-prune: adjust file mtime based on system time rather than file mtime Fix escaping of glob special characters in pathspecs
2008-08-13Fix escaping of glob special characters in pathspecsLibravatar Kevin Ballard1-0/+8
match_one implements an optimized pathspec match where it only uses fnmatch if it detects glob special characters in the pattern. Unfortunately it didn't treat \ as a special character, so attempts to escape a glob special character would fail even though fnmatch() supports it. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-2/+2
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-21Merge branch 'ar/add-unreadable'Libravatar Junio C Hamano1-0/+43
* ar/add-unreadable: Add a config option to ignore errors for git-add Add a test for git-add --ignore-errors Add --ignore-errors to git-add to allow it to skip files with read errors Extend interface of add_files_to_cache to allow ignore indexing errors Make the exit code of add_file_to_index actually useful
2008-05-13fix bsd shell negationLibravatar Jeff King1-3/+3
On some shells (notably /bin/sh on FreeBSD 6.1), the construct foo && ! bar | baz is true if foo && baz whereas for most other shells (such as bash) is true if foo && ! baz We can work around this by specifying foo && ! (bar | baz) which works everywhere. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Add a config option to ignore errors for git-addLibravatar Alex Riesen1-0/+21
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12Add a test for git-add --ignore-errorsLibravatar Alex Riesen1-0/+22
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-16Fix per-directory exclude handing for "git add"Libravatar Junio C Hamano1-0/+24
In "dir_struct", each exclusion element in the exclusion stack records a base string (pointer to the beginning with length) so that we can tell where it came from, but this pointer is just pointing at the parameter that is given by the caller to the push_exclude_per_directory() function. While read_directory_recursive() runs, calls to excluded() makes use the data in the exclusion elements, including this base string. The caller of read_directory_recursive() is not supposed to free the buffer it gave to push_exclude_per_directory() earlier, until it returns. The test case Bruce Stephens gave in the mailing list discussion was simplified and added to the t3700 test. Signed-off-by: Junio C Hamano <gitster@pobox.com>