summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2015-03-03Merge branch 'km/send-email-getopt-long-workarounds'Libravatar Junio C Hamano1-5/+5
Even though we officially haven't dropped Perl 5.8 support, the Getopt::Long package that came with it does not support "--no-" prefix to negate a boolean option; manually add support to help people with older Getopt::Long package. * km/send-email-getopt-long-workarounds: git-send-email.perl: support no- prefix with older GetOptions
2015-03-03Merge branch 'jc/apply-beyond-symlink'Libravatar Junio C Hamano2-0/+247
"git apply" was not very careful about reading from, removing, updating and creating paths outside the working tree (under --index/--cached) or the current directory (when used as a replacement for GNU patch). * jc/apply-beyond-symlink: apply: do not touch a file beyond a symbolic link apply: do not read from beyond a symbolic link apply: do not read from the filesystem under --index apply: reject input that touches outside the working area
2015-02-25Merge branch 'jk/sanity'Libravatar Junio C Hamano4-9/+42
The tests that wanted to see that file becomes unreadable after running "chmod a-r file", and the tests that wanted to make sure it is not run as root, we used "can we write into the / directory?" as a cheap substitute, but on some platforms that is not a good heuristics. The tests and their prerequisites have been updated to check what they really require. * jk/sanity: test-lib.sh: set prerequisite SANITY by testing what we really need tests: correct misuses of POSIXPERM t/lib-httpd: switch SANITY check for NOT_ROOT
2015-02-22Merge branch 'jk/prune-mtime'Libravatar Junio C Hamano1-0/+8
In v2.2.0, we broke "git prune" that runs in a repository that borrows from an alternate object store. * jk/prune-mtime: sha1_file: fix iterating loose alternate objects for_each_loose_file_in_objdir: take an optional strbuf path
2015-02-22Merge branch 'ps/submodule-sanitize-path-upon-add'Libravatar Junio C Hamano1-0/+17
"git submodule add" failed to squash "path/to/././submodule" to "path/to/submodule". * ps/submodule-sanitize-path-upon-add: git-submodule.sh: fix '/././' path normalization
2015-02-22Merge branch 'ab/merge-file-prefix'Libravatar Junio C Hamano1-1/+2
"git merge-file" did not work correctly in a subdirectory. * ab/merge-file-prefix: merge-file: correctly open files when in a subdir
2015-02-18Merge branch 'jk/config-no-ungetc-eof'Libravatar Junio C Hamano1-0/+9
Reading configuration from a blob object, when it ends with a lone CR, use to confuse the configuration parser. * jk/config-no-ungetc-eof: config_buf_ungetc: warn when pushing back a random character config: do not ungetc EOF
2015-02-18Merge branch 'ch/new-gpg-drops-rfc-1991'Libravatar Junio C Hamano2-0/+58
Older GnuPG implementations may not correctly import the keyring material we prepare for the tests to use. * ch/new-gpg-drops-rfc-1991: t/lib-gpg: sanity-check that we can actually sign t/lib-gpg: include separate public keys in keyring.gpg
2015-02-18Merge branch 'ye/http-accept-language'Libravatar Junio C Hamano1-0/+42
Using environment variable LANGUAGE and friends on the client side, HTTP-based transports now send Accept-Language when making requests. * ye/http-accept-language: http: add Accept-Language header if possible
2015-02-17Merge branch 'jc/t4122-use-test-write-lines'Libravatar Junio C Hamano1-9/+2
* jc/t4122-use-test-write-lines: t4122: use test_write_lines from test-lib-functions
2015-02-17Merge branch 'jk/dumb-http-idx-fetch-fix'Libravatar Junio C Hamano1-0/+18
A broken pack .idx file in the receiving repository prevented the dumb http transport from fetching a good copy of it from the other side. * jk/dumb-http-idx-fetch-fix: dumb-http: do not pass NULL path to parse_pack_index
2015-02-17Merge branch 'jc/apply-ws-fix-expands'Libravatar Junio C Hamano1-0/+121
"git apply --whitespace=fix" used to under-allocate the memory when the fix resulted in a longer text than the original patch. * jc/apply-ws-fix-expands: apply: count the size of postimage correctly apply: make update_pre_post_images() sanity check the given postlen apply.c: typofix
2015-02-17Merge branch 'ks/rebase-i-abbrev'Libravatar Junio C Hamano1-0/+7
The insn sheet "git rebase -i" creates did not fully honor core.abbrev settings. * ks/rebase-i-abbrev: rebase -i: use full object name internally throughout the script
2015-02-17Merge branch 'mh/deref-symref-over-helper-transport'Libravatar Junio C Hamano1-0/+24
"git fetch" over a remote-helper that cannot respond to "list" command could not fetch from a symbolic reference e.g. HEAD. * mh/deref-symref-over-helper-transport: transport-helper: do not request symbolic refs to remote helpers
2015-02-16git-send-email.perl: support no- prefix with older GetOptionsLibravatar Kyle J. McKay1-5/+5
Only Perl version 5.8.0 or later is required, but that comes with an older Getopt::Long (2.32) that does not support the 'no-' prefix. Support for that was added in Getopt::Long version 2.33. Since the help only mentions the 'no-' prefix and not the 'no' prefix, add explicit support for the 'no-' prefix to support older GetOptions versions. Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Tested-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-15test-lib.sh: set prerequisite SANITY by testing what we really needLibravatar Torsten Bögershausen1-3/+22
What we wanted out of the SANITY precondition is that the filesystem behaves sensibly with permission bits settings. - You should not be able to remove a file in a read-only directory, - You should not be able to tell if a file in a directory exists if the directory lacks read or execute permission bits. We used to cheat by approximating that condition with "is the / writable?" test and/or "are we running as root?" test. Neither test is sufficient or appropriate in environments like Cygwin. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-11Merge branch 'jc/push-to-checkout'Libravatar Junio C Hamano1-0/+63
Extending the js/push-to-deploy topic, the behaviour of "git push" when updating the working tree and the index with an update to the branch that is checked out can be tweaked by push-to-checkout hook. * jc/push-to-checkout: receive-pack: support push-to-checkout hook receive-pack: refactor updateInstead codepath
2015-02-11Merge branch 'sb/atomic-push'Libravatar Junio C Hamano1-0/+194
"git push" has been taught a "--atomic" option that makes push to update more than one ref an "all-or-none" affair. * sb/atomic-push: Document receive.advertiseatomic t5543-atomic-push.sh: add basic tests for atomic pushes push.c: add an --atomic argument send-pack.c: add --atomic command line argument send-pack: rename ref_update_to_be_sent to check_to_send_update receive-pack.c: negotiate atomic push support receive-pack.c: add execute_commands_atomic function receive-pack.c: move transaction handling in a central place receive-pack.c: move iterating over all commands outside execute_commands receive-pack.c: die instead of error in case of possible future bug receive-pack.c: shorten the execute_commands loop over all commands
2015-02-11Merge branch 'cj/log-invert-grep'Libravatar Junio C Hamano1-0/+15
"git log --invert-grep --grep=WIP" will show only commits that do not have the string "WIP" in their messages. * cj/log-invert-grep: log: teach --invert-grep option
2015-02-11Merge branch 'dk/format-patch-ignore-diff-submodule'Libravatar Junio C Hamano1-0/+72
Setting diff.submodule to 'log' made "git format-patch" produce broken patches. * dk/format-patch-ignore-diff-submodule: format-patch: ignore diff.submodule setting t4255: test am submodule with diff.submodule
2015-02-11Merge branch 'ld/p4-exclude-in-sync'Libravatar Junio C Hamano1-0/+71
Like the "clone" subcommand, allow excluding subdirectories in the "sync" subcommand. * ld/p4-exclude-in-sync: git-p4: support excluding paths on sync
2015-02-11git-p4: support excluding paths on syncLibravatar Luke Diamand1-0/+71
The clone subcommand has long had support for excluding subdirectories, but sync has not. This is a nuisance, since as soon as you do a sync, any changed files that were initially excluded start showing up. Move the "exclude" command-line option into the parent class; the actual behavior was already present there so it simply had to be exposed. Signed-off-by: Luke Diamand <luke@diamand.org> Reviewed-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-11Merge branch 'ak/typofixes'Libravatar Junio C Hamano1-1/+1
* ak/typofixes: t/lib-terminal.sh: fix typo pack-bitmap: fix typo
2015-02-11merge-file: correctly open files when in a subdirLibravatar Aleksander Boruch-Gruszecki1-1/+2
run_setup_gently() is called before merge-file. This may result in changing current working directory, which wasn't taken into account when opening a file for writing. Fix by prepending the passed prefix. Previous var is left so that error messages keep referring to the file from the user's working directory perspective. Signed-off-by: Aleksander Boruch-Gruszecki <aleksander.boruchgruszecki@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-10apply: do not touch a file beyond a symbolic linkLibravatar Junio C Hamano2-4/+91
Because Git tracks symbolic links as symbolic links, a path that has a symbolic link in its leading part (e.g. path/to/dir/file, where path/to/dir is a symbolic link to somewhere else, be it inside or outside the working tree) can never appear in a patch that validly applies, unless the same patch first removes the symbolic link to allow a directory to be created there. Detect and reject such a patch. Things to note: - Unfortunately, we cannot reuse the has_symlink_leading_path() from dir.c, as that is only about the working tree, but "git apply" can be told to apply the patch only to the index or to both the index and to the working tree. - We cannot directly use has_symlink_leading_path() even when we are applying only to the working tree, as an early patch of a valid input may remove a symbolic link path/to/dir and then a later patch of the input may create a path path/to/dir/file, but "git apply" first checks the input without touching either the index or the working tree. The leading symbolic link check must be done on the interim result we compute in-core (i.e. after the first patch, there is no path/to/dir symbolic link and it is perfectly valid to create path/to/dir/file). Similarly, when an input creates a symbolic link path/to/dir and then creates a file path/to/dir/file, we need to flag it as an error without actually creating path/to/dir symbolic link in the filesystem. Instead, for any patch in the input that leaves a path (i.e. a non deletion) in the result, we check all leading paths against the resulting tree that the patch would create by inspecting all the patches in the input and then the target of patch application (either the index or the working tree). This way, we catch a mischief or a mistake to add a symbolic link path/to/dir and a file path/to/dir/file at the same time, while allowing a valid patch that removes a symbolic link path/to/dir and then adds a file path/to/dir/file. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-10apply: do not read from beyond a symbolic linkLibravatar Junio C Hamano1-0/+19
We should reject a patch, whether it renames/copies dir/file to elsewhere with or without modificiation, or updates dir/file in place, if "dir/" part is actually a symbolic link to elsewhere, by making sure that the code to read the preimage does not read from a path that is beyond a symbolic link. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-10apply: reject input that touches outside the working areaLibravatar Junio C Hamano1-0/+141
By default, a patch that affects outside the working area (either a Git controlled working tree, or the current working directory when "git apply" is used as a replacement of GNU patch) is rejected as a mistake (or a mischief). Git itself does not create such a patch, unless the user bends over backwards and specifies a non-standard prefix to "git diff" and friends. When `git apply` is used as a "better GNU patch", the user can pass the `--unsafe-paths` option to override this safety check. This option has no effect when `--index` or `--cached` is in use. The new test was stolen from Jeff King with slight enhancements. Note that a few new tests for touching outside the working area by following a symbolic link are still expected to fail at this step, but will be fixed in later steps. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-09sha1_file: fix iterating loose alternate objectsLibravatar Jonathon Mah1-0/+8
The string in 'base' contains a path suffix to a specific object; when its value is used, the suffix must either be filled (as in stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or cleared (as in prepare_packed_git) to avoid junk at the end. 660c889e (sha1_file: add for_each iterators for loose and packed objects, 2014-10-15) introduced loose_from_alt_odb(), but this did neither and treated 'base' as a complete path to the "base" object directory, instead of a pointer to the "base" of the full path string. The trailing path after 'base' is still initialized to NUL, hiding the bug in some common cases. Additionally the descendent for_each_file_in_obj_subdir() function swallows ENOENT, so an error only shows if the alternate's path was last filled with a valid object (where statting /path/to/existing/00/0bjectfile/00 fails). Signed-off-by: Jonathon Mah <me@JonathonMah.com> Helped-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-05config: do not ungetc EOFLibravatar Jeff King1-0/+9
When we are parsing a config value, if we see a carriage return, we fgetc the next character to see if it is a line feed (in which case we silently drop the CR). If it isn't, we then ungetc the character, and take the literal CR. But we never check whether we in fact got a character at all. If the config file ends in CR, we will get EOF here, and try to ungetc EOF. This works OK for a real stdio stream. The ungetc returns an error, and the next fgetc will then return EOF again. However, our custom buffer-based stream is not so fortunate. It happily rewinds the position of the stream by one character, ignoring the fact that we fed it EOF. The next fgetc call returns the final CR again, over and over, and we end up in an infinite loop. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-02git-submodule.sh: fix '/././' path normalizationLibravatar Patrick Steinhardt1-0/+17
When we add a new submodule the path of the submodule is being normalized. We fail to normalize multiple adjacent '/./', though. Thus 'path/to/././submodule' will become 'path/to/./submodule' where it should be 'path/to/submodule' instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29t/lib-gpg: sanity-check that we can actually signLibravatar Jeff King1-0/+2
Some older versions of gpg (reportedly v1.2.6 from RHEL4) cannot import the keyrings found in our test suite, and thus cannot even make a signature. The previous change works it around, but we cannot anticipate breakages update to GPG would cause in the future. Do a test-sign before declaring the GPG prerequisite fulfilled to future-proof our tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-29t/lib-gpg: include separate public keys in keyring.gpgLibravatar Jeff King2-0/+56
Since 1e3eefb (tests: replace binary GPG keyrings with ASCII-armored keys, 2014-12-12), we import our test GPG keys from a single file. Each keypair in the import stream contains both the secret and public keys. However, older versions of gpg reportedly fail to import the public half of the key. We can solve this by including duplicates of the public keys separately. The duplicates are ignored by modern gpg, and this makes older versions work. Reported by Tom G. Christensen <tgc@statsbiblioteket.dk> on gpg 1.2.6 (from RHEL4). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-28t4122: use test_write_lines from test-lib-functionsLibravatar Junio C Hamano1-9/+2
Instead of using a custom lecho function, just use what the test framework already gives us. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-28http: add Accept-Language header if possibleLibravatar Yi EungJun1-0/+42
Add an Accept-Language header which indicates the user's preferred languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG. Examples: LANGUAGE= -> "" LANGUAGE=ko:en -> "Accept-Language: ko, en;q=0.9, *;q=0.1" LANGUAGE=ko LANG=en_US.UTF-8 -> "Accept-Language: ko, *;q=0.1" LANGUAGE= LANG=en_US.UTF-8 -> "Accept-Language: en-US, *;q=0.1" This gives git servers a chance to display remote error messages in the user's preferred language. Limit the number of languages to 1,000 because q-value must not be smaller than 0.001, and limit the length of Accept-Language header to 4,000 bytes for some HTTP servers which cannot accept such long header. Signed-off-by: Yi EungJun <eungjun.yi@navercorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-27dumb-http: do not pass NULL path to parse_pack_indexLibravatar Jeff King1-0/+18
Once upon a time, dumb http always fetched .idx files directly into their final location, and then checked their validity with parse_pack_index. This was refactored in commit 750ef42 (http-fetch: Use temporary files for pack-*.idx until verified, 2010-04-19), which uses the following logic: 1. If we have the idx already in place, see if it's valid (using parse_pack_index). If so, use it. 2. Otherwise, fetch the .idx to a tempfile, check that, and if so move it into place. 3. Either way, fetch the pack itself if necessary. However, it got step 1 wrong. We pass a NULL path parameter to parse_pack_index, so an existing .idx file always looks broken. Worse, we do not treat this broken .idx as an opportunity to re-fetch, but instead return an error, ignoring the pack entirely. This can lead to a dumb-http fetch failing to retrieve the necessary objects. This doesn't come up much in practice, because it must be a packfile that we found out about (and whose .idx we stored) during an earlier dumb-http fetch, but whose packfile we _didn't_ fetch. I.e., we did a partial clone of a repository, didn't need some packfiles, and now a followup fetch needs them. Discovery and tests by Charles Bailey <charles@hashpling.org>. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-22Merge branch 'js/t1050'Libravatar Junio C Hamano1-6/+6
* js/t1050: t1050-large: generate large files without dd
2015-01-22Merge branch 'jh/empty-notes'Libravatar Junio C Hamano1-1/+1
* jh/empty-notes: Fix unclosed here document in t3301.sh
2015-01-22apply: make update_pre_post_images() sanity check the given postlenLibravatar Junio C Hamano1-0/+121
"git apply --whitespace=fix" used to be able to assume that fixing errors will always reduce the size by e.g. stripping whitespaces at the end of lines or collapsing runs of spaces into tabs at the beginning of lines. An update to accomodate fixes that lengthens the result by e.g. expanding leading tabs into spaces were made long time ago but the logic miscounted the necessary space after such whitespace fixes, leading to either under-allocation or over-usage of already allocated space. Illustrate this with a runtime sanity-check to protect us from future breakage. The test was stolen from Kyle McKay who helped to identify the problem. Helped-by: "Kyle J. McKay" <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-22Fix unclosed here document in t3301.shLibravatar Kacper Kornet1-1/+1
Commit 908a3203632a02568df230c0fccf9a2cd8da24e6 introduced indentation to here documents in t3301.sh. However in one place <<-EOF was missing -, which broke this test when run with mksh-50d. This commit fixes it. Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-22rebase -i: use full object name internally throughout the scriptLibravatar Kirill A. Shutemov1-0/+7
In earlier days, the abbreviated commit object name shown to the end users were generated with hardcoded --abbrev=7; 56895038 (rebase -i: respect core.abbrev, 2013-09-28) tried to make it honor the user specified core.abbrev, but it missed the very initial invocation of the editor. These days, we try to use the full 40-hex object names internally to avoid ambiguity that can arise after rebase starts running. Newly created objects during the rebase may share the same prefix with existing commits listed in the insn sheet. These object names are shortened just before invoking the sequence editor to present the insn sheet to the end user, and then expanded back to full object names when the editor returns. But the code still used the shortened names when preparing the insn sheet for the very first time, resulting "7 hexdigits or more" output to the user. Change the code to use full 40-hex commit object names from the very beginning to make things more uniform. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-21transport-helper: do not request symbolic refs to remote helpersLibravatar Mike Hommey1-0/+24
A typical remote helper will return a `list` of refs containing a symbolic ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all the refs are being requested through `fetch` or `import`, including the symbolic ref. While this works properly, in some cases of a fetch, like `git fetch url` or `git fetch origin HEAD`, or any fetch command involving a symbolic ref without also fetching the corresponding ref it points to, the fetch command fails with: fatal: bad object 0000000000000000000000000000000000000000 error: <remote> did not send all necessary objects (in the case the remote helper returned '?' values to the `list` command). This is because there is only one ref given to fetch(), and it's not further resolved to something at the end of fetch_with_import(). While this can be somehow handled in the remote helper itself, by adding a refspec for the symbolic ref, and storing an explicit ref in a private namespace, and then handling the `import` for that symbolic ref specifically, very few existing remote helpers are actually doing that. So, instead of requesting the exact list of wanted refs to remote helpers, treat symbolic refs differently and request the ref they point to instead. Then, resolve the symbolic refs values based on the pointed ref. This assumes there is no more than one level of indirection (a symbolic ref doesn't point to another symbolic ref). Signed-off-by: Mike Hommey <mh@glandium.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-21t/lib-terminal.sh: fix typoLibravatar Alexander Kuleshov1-1/+1
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-20Merge branch 'jk/colors'Libravatar Junio C Hamano1-0/+4
* jk/colors: parse_color: fix return value for numeric color values 0-8
2015-01-20parse_color: fix return value for numeric color values 0-8Libravatar Jeff King1-0/+4
When commit 695d95d refactored the color parsing, it missed a "return 0" when parsing literal numbers 0-8 (which represent basic ANSI colors), leading us to report these colors as an error. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16tests: correct misuses of POSIXPERMLibravatar Junio C Hamano2-5/+14
POSIXPERM requires that a later call to stat(2) (hence "ls -l") faithfully reproduces what an earlier chmod(2) did. Some filesystems cannot satisify this. SANITY requires that a file or a directory is indeed accessible (or inaccessible) when its permission bits would say it ought to be accessible (or inaccessible). Running tests as root would lose this prerequisite for obvious reasons. Fix a few tests that misuse POSIXPERM. t0061-run-command.sh has two uses of POSIXPERM. - One checks that an attempt to execute a file that is marked as unexecutable results in a failure with EACCES; I do not think having root-ness or any other capability that busts the filesystem permission mode bits will make you run an unexecutable file, so this should be left as-is. The test does not have anything to do with SANITY. - The other one expects 'git nitfol' runs the alias when an alias.nitfol is defined and a directory on the PATH is marked as unreadable and unsearchable. I _think_ the test tries to reject the alternative expectation that we want to refuse to run the alias because it would break "no alias may mask a command" rule if a file 'git-nitfol' exists in the unreadable directory but we cannot even determine if that is the case. Under !SANITY that busts the permission bits, this test no longer checks that, so it must be protected with SANITY. t1509-root-worktree.sh expects to be run on a / that is writable by the user and sees if Git behaves "sensibly" when /.git is the repository to govern a worktree that is the whole filesystem, and also if Git behaves "sensibly" when / itself is a bare repository with refs, objects, and friends (I find the definition of "behaves sensibly" under these conditions hard to fathom, but it is a different matter). The implementation of the test is very much problematic. - It requires POSIXPERM, but it does not do chmod or checks modes in any way. - It runs "rm /*" and "rm -fr /refs /objects ..." in one of the tests, and also does "cd / && git init --bare". If done on a live system that takes advantages of the "feature" being tested, these obviously will clobber the system. But there is no guard against such a breakage. - It uses "test $UID = 0" to see rootness, which now should be spelled "! test_have_prereq NOT_ROOT" Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-16t/lib-httpd: switch SANITY check for NOT_ROOTLibravatar Jeff King2-1/+6
The SANITY prerequisite is really about whether the filesystem will respect the permissions we set, and being root is only one part of that. But the httpd tests really just care about not being root, as they are trying to avoid weirdness in apache (see a1a3011 for details). Let's switch out SANITY for a new NOT_ROOT prerequisite, which will let us tweak SANITY more freely. We implement NOT_ROOT by checking `id -u`, which is in POSIX and seems to be available even on MSYS. Note that we cannot just call this "ROOT" and ask for "!ROOT". The possible outcomes are: 1. we know we are root 2. we know we are not root 3. we could not tell, because `id` was not available We should conservatively treat (3) as "does not have the prerequisite", which means that a naive negation would not work. Helped-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14t1050-large: generate large files without ddLibravatar Johannes Sixt1-6/+6
For some unknown reason, the dd on my Windows box segfaults randomly, but since recently, it does so much more often than it used to, which makes running the test suite burdensome. Use printf to write large files instead of dd. To emphasize that three of the large blobs are exact copies, use cp to allocate them. The new code makes the files a bit smaller, and they are not sparse anymore, but the tests do not depend on these properties. We do not want to use test-genrandom here (which is used to generate large files elsewhere in t1050), so that the files can be compressed well (which keeps the run-time short). The files are now large text files, not binary files. But since they are larger than core.bigfilethreshold they are diagnosed as binary by Git. For this reason, the 'git diff' tests that check the output for "Binary files differ" still pass. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-14Merge branch 'rc/for-each-ref-tracking'Libravatar Junio C Hamano1-0/+13
* rc/for-each-ref-tracking: for-each-ref: always check stat_tracking_info()'s return value
2015-01-14Merge branch 'rh/test-color-avoid-terminfo-in-original-home'Libravatar Junio C Hamano1-44/+48
We try to see if "tput" gives a useful result before switching TERM to dumb and moving HOME to point to our fake location for stability of the tests, and then use the command when coloring the output from the tests, but there is no guarantee "tput" works after switching HOME. * rh/test-color-avoid-terminfo-in-original-home: test-lib.sh: do tests for color support after changing HOME test-lib: use 'test ...' instead of '[ ... ]'
2015-01-14Merge branch 'rh/hide-prompt-in-ignored-directory'Libravatar Junio C Hamano1-0/+106
* rh/hide-prompt-in-ignored-directory: git-prompt.sh: allow to hide prompt for ignored pwd git-prompt.sh: if pc mode, immediately set PS1 to a plain prompt