summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-05-23Merge branch 'da/difftool'Libravatar Junio C Hamano1-0/+23
"git difftool" learned to handle unmerged paths correctly in dir-diff mode. * da/difftool: difftool: handle unmerged files in dir-diff mode difftool: initialize variables for readability
2016-05-23Merge branch 'jk/test-z-n-unquoted'Libravatar Junio C Hamano13-111/+121
t9xxx series has been updated primarily for readability, while fixing small bugs in it. A few scripted Porcelains have also been updated to fix possible bugs around their use of "test -z" and "test -n". * jk/test-z-n-unquoted: always quote shell arguments to test -z/-n t9103: modernize test style t9107: switch inverted single/double quotes in test t9107: use "return 1" instead of "exit 1" t9100,t3419: enclose all test code in single-quotes t/lib-git-svn: drop $remote_git_svn and $git_svn_id
2016-05-23Merge branch 'ar/diff-args-osx-precompose'Libravatar Junio C Hamano1-0/+42
Many commands normalize command line arguments from NFD to NFC variant of UTF-8 on OSX, but commands in the "diff" family did not, causing "git diff $path" to complain that no such path is known to Git. They have been taught to do the normalization. * ar/diff-args-osx-precompose: diff: run arguments through precompose_argv
2016-05-23Merge branch 'js/perf-rebase-i'Libravatar Junio C Hamano2-8/+47
Add perf test for "rebase -i" * js/perf-rebase-i: perf: run "rebase -i" under perf perf: make the tests work in worktrees perf: let's disable symlinks when they are not available
2016-05-23Merge branch 'jc/test-parse-options-expect'Libravatar Junio C Hamano2-60/+93
t0040 had too many unnecessary repetitions in its test data. Teach test-parse-options program so that a caller can tell what it expects in its output, so that these repetitions can be cleaned up. * jc/test-parse-options-expect: t0040: convert a few tests to use test-parse-options --expect t0040: remove unused test helpers test-parse-options: --expect=<string> option to simplify tests test-parse-options: fix output when callback option fails
2016-05-23Merge branch 'pb/commit-verbose-config'Libravatar Junio C Hamano3-71/+244
"git commit" learned to pay attention to "commit.verbose" configuration variable and act as if "--verbose" option was given from the command line. * pb/commit-verbose-config: commit: add a commit.verbose config variable t7507-commit-verbose: improve test coverage by testing number of diffs parse-options.c: make OPTION_COUNTUP respect "unspecified" values t/t7507: improve test coverage t0040-parse-options: improve test coverage test-parse-options: print quiet as integer t0040-test-parse-options.sh: fix style issues
2016-05-23Merge branch 'xy/format-patch-base'Libravatar Junio C Hamano1-0/+105
"git format-patch" learned a new "--base" option to record what (public, well-known) commit the original series was built on in its output. * xy/format-patch-base: format-patch: introduce format.useAutoBase configuration format-patch: introduce --base=auto option format-patch: add '--base' option to record base tree info patch-ids: make commit_patch_id() a public helper function
2016-05-23Merge branch 'tb/core-eol-fix'Libravatar Junio C Hamano1-170/+131
A couple of bugs around core.autocrlf have been fixed. * tb/core-eol-fix: convert.c: ident + core.autocrlf didn't work t0027: test cases for combined attributes convert: allow core.autocrlf=input and core.eol=crlf t0027: make commit_chk_wrnNNO() reliable
2016-05-23Merge branch 'nd/worktree-various-heads'Libravatar Junio C Hamano1-0/+59
The experimental "multiple worktree" feature gains more safety to forbid operations on a branch that is checked out or being actively worked on elsewhere, by noticing that e.g. it is being rebased. * nd/worktree-various-heads: branch: do not rename a branch under bisect or rebase worktree.c: check whether branch is bisected in another worktree wt-status.c: split bisect detection out of wt_status_get_state() worktree.c: check whether branch is rebased in another worktree worktree.c: avoid referencing to worktrees[i] multiple times wt-status.c: make wt_status_check_rebase() work on any worktree wt-status.c: split rebase detection out of wt_status_get_state() path.c: refactor and add worktree_git_path() worktree.c: mark current worktree worktree.c: make find_shared_symref() return struct worktree * worktree.c: store "id" instead of "git_dir" path.c: add git_common_path() and strbuf_git_common_path() dir.c: rename str(n)cmp_icase to fspath(n)cmp
2016-05-23Merge branch 'ss/commit-dry-run-resolve-merge-to-no-op'Libravatar Junio C Hamano1-0/+20
"git commit --dry-run" reported "No, no, you cannot commit." in one case where "git commit" would have allowed you to commit, and this improves it a little bit ("git commit --dry-run --short" still does not give you the correct answer, for example). This is a stop-gap measure in that "commit --short --dry-run" still gives an incorrect result. * ss/commit-dry-run-resolve-merge-to-no-op: wt-status.c: set commitable bit if there is a meaningful merge.
2016-05-17Merge branch 'js/windows-dotgit'Libravatar Junio C Hamano2-0/+50
On Windows, .git and optionally any files whose name starts with a dot are now marked as hidden, with a core.hideDotFiles knob to customize this behaviour. * js/windows-dotgit: mingw: remove unnecessary definition mingw: introduce the 'core.hideDotFiles' setting
2016-05-17Merge branch 'jk/test-send-sh-x-trace-elsewhere'Libravatar Junio C Hamano2-3/+16
Running tests with '-x' option to trace the individual command executions is a useful way to debug test scripts, but some tests that capture the standard error stream and check what the command said can be broken with the trace output mixed in. When running our tests under "bash", however, we can redirect the trace output to another file descriptor to keep the standard error of programs being tested intact. * jk/test-send-sh-x-trace-elsewhere: test-lib: set BASH_XTRACEFD automatically
2016-05-17Merge branch 'js/http-custom-headers'Libravatar Junio C Hamano2-6/+24
Update tests for "http.extraHeaders=<header>" to be portable back to Apache 2.2 (the original depended on <RequireAll/> which is a more recent feature). * js/http-custom-headers: submodule: ensure that -c http.extraheader is heeded t5551: make the test for extra HTTP headers more robust tests: adjust the configuration for Apache 2.2
2016-05-17Merge branch 'jc/fsck-nul-in-commit'Libravatar Junio C Hamano1-0/+18
"git fsck" learned to catch NUL byte in a commit object as potential error and warn. * jc/fsck-nul-in-commit: fsck: detect and warn a commit with embedded NUL fsck_commit_buffer(): do not special case the last validation
2016-05-17Merge branch 'jc/ll-merge-internal'Libravatar Junio C Hamano2-85/+3
"git rerere" can get confused by conflict markers deliberately left by the inner merge step, because they are indistinguishable from the real conflict markers left by the outermost merge which are what the end user and "rerere" need to look at. This was fixed by making the conflict markers left by the inner merges a bit longer. * jc/ll-merge-internal: t6036: remove pointless test that expects failure ll-merge: use a longer conflict marker for internal merge ll-merge: fix typo in comment
2016-05-17Merge branch 'tb/t5601-sed-fix'Libravatar Junio C Hamano1-1/+1
Test fix. * tb/t5601-sed-fix: t5601: Remove trailing space in sed expression
2016-05-17Merge branch 'jc/test-seq'Libravatar Junio C Hamano1-15/+13
Test fix. * jc/test-seq: test-lib-functions.sh: rewrite test_seq without Perl test-lib-functions.sh: remove misleading comment on test_seq
2016-05-17Merge branch 'es/test-gpg-tags'Libravatar Junio C Hamano1-23/+22
Test fix. * es/test-gpg-tags: t6302: simplify non-gpg cases
2016-05-17Merge branch 'ak/t4151-ls-files-could-be-empty'Libravatar Junio C Hamano1-1/+1
Test fix. * ak/t4151-ls-files-could-be-empty: t4151: make sure argument to 'test -z' is given
2016-05-17Merge branch 'jk/submodule-c-credential'Libravatar Junio C Hamano2-29/+35
An earlier addition of "sanitize_submodule_env" with 14111fc4 (git: submodule honor -c credential.* from command line, 2016-02-29) turned out to be a convoluted no-op; implement what it wanted to do correctly, and stop filtering settings given via "git -c var=val". * jk/submodule-c-credential: submodule: stop sanitizing config options submodule: use prepare_submodule_repo_env consistently submodule--helper: move config-sanitizing to submodule.c submodule: export sanitized GIT_CONFIG_PARAMETERS t5550: break submodule config test into multiple sub-tests t5550: fix typo in $HTTPD_URL
2016-05-17Merge branch 'va/i18n-misc-updates'Libravatar Junio C Hamano1-9/+9
Mark several messages for translation. * va/i18n-misc-updates: i18n: unpack-trees: avoid substituting only a verb in sentences i18n: builtin/pull.c: split strings marked for translation i18n: builtin/pull.c: mark placeholders for translation i18n: git-parse-remote.sh: mark strings for translation i18n: branch: move comment for translators i18n: branch: unmark string for translation i18n: builtin/rm.c: remove a comma ',' from string i18n: unpack-trees: mark strings for translation i18n: builtin/branch.c: mark option for translation i18n: index-pack: use plural string instead of normal one
2016-05-17Merge branch 'js/t3404-typofix'Libravatar Junio C Hamano1-1/+1
* js/t3404-typofix: t3404: fix typo
2016-05-17Merge branch 'sb/z-is-gnutar-ism'Libravatar Junio C Hamano2-4/+4
* sb/z-is-gnutar-ism: t6041: do not compress backup tar file t3513: do not compress backup tar file
2016-05-17Merge branch 'lp/typofixes'Libravatar Junio C Hamano1-1/+1
* lp/typofixes: typofix: assorted typofixes in comments, documentation and messages
2016-05-17Merge branch 'sb/submodule-deinit-all'Libravatar Junio C Hamano1-1/+23
Correct faulty recommendation to use "git submodule deinit ." when de-initialising all submodules, which would result in a strange error message in a pathological corner case. * sb/submodule-deinit-all: submodule deinit: require '--all' instead of '.' for all submodules
2016-05-17Merge branch 'ab/hooks'Libravatar Junio C Hamano1-0/+37
A new configuration variable core.hooksPath allows customizing where the hook directory is. * ab/hooks: hooks: allow customizing where the hook directory is githooks.txt: minor improvements to the grammar & phrasing githooks.txt: amend dangerous advice about 'update' hook ACL githooks.txt: improve the intro section
2016-05-17Merge branch 'sb/submodule-init'Libravatar Junio C Hamano3-6/+80
Update of "git submodule" to move pieces of logic to C continues. * sb/submodule-init: submodule init: redirect stdout to stderr submodule--helper update-clone: abort gracefully on missing .gitmodules submodule init: fail gracefully with a missing .gitmodules file submodule: port init from shell to C submodule: port resolve_relative_url from shell to C
2016-05-16difftool: handle unmerged files in dir-diff modeLibravatar David Aguilar1-0/+23
When files are unmerged they can show up as both unmerged and modified in the output of `git diff --raw`. This causes difftool's dir-diff to create filesystem entries for the same path twice, which fails when it encounters a duplicate path. Ensure that each worktree path is only processed once. Add a test to demonstrate the breakage. Reported-by: Jan Smets <jan@smets.cx> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-14always quote shell arguments to test -z/-nLibravatar Jeff King1-1/+1
In shell code like: test -z $foo test -n $foo that does not quote its arguments, it's easy to think that it is actually looking at the contents of $foo in each case. But if $foo is empty, then "test" does not see any argument at all! The results are quite subtle. POSIX specifies that test's behavior depends on the number of arguments it sees, and if $foo is empty, it sees only one. The behavior in this case is: 1 argument: Exit true (0) if $1 is not null; otherwise, exit false. So in the "-z $foo" case, if $foo is empty, then we check that "-z" is non-null, and it returns success. Which happens to match what we expected. But for "-n $foo", if $foo is empty, we'll see that "-n" is non-null and still return success. That's the opposite of what we intended! Furthermore, if $foo contains whitespace, we'll end up with more than 2 arguments. The results in this case are generally unspecified (unless the first part of $foo happens to be a valid binary operator, in which case the results are specified but certainly not what we intended). And on top of this, even though "test -z $foo" _should_ work for the empty case, some older shells (reportedly ksh88) complain about the missing argument. So let's make sure we consistently quote our variable arguments to "test". After this patch, the results of: git grep 'test -[zn] [^"]' are empty. Reported-by: Armin Kunaschik <megabreit@googlemail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-14t9103: modernize test styleLibravatar Jeff King1-10/+12
The main goal here was to avoid double-quotes for surrounding the test snippet, since it makes the code hard to read (and to grep for common problems). But while we're here, we can fix a few other things: - use test_path_* helpers, which are more robust and give better error messages - only "cd" inside a subshell, which leaves the environment pristine if further tests are added - consistently quote shell arguments. These aren't wrong if we assume find-rev output doesn't have any whitespace, but it doesn't hurt to be careful. - replace the old-style 'test x$foo = x' with 'test -z "$foo"'. Besides the quoting fix, this is the form we generally use in our test suite. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-14t9107: switch inverted single/double quotes in testLibravatar Jeff King1-2/+3
One of the test snippets in t9107 is enclosed in double quotes, but then uses single quotes to surround an interpolated variable inside the snippet, like: test_expect_success '...' " test -n '$head' " This happens to work because the variable is interpolated _before_ the snippet is run, and the result is eval'd. So as long as the variable does not contain any single quotes, the two are equivalent. And it doesn't, as we know it is a sha1 from rev-parse above. But this construct is unnecessarily confusing. But we can go a step further in cleaning up. The test is really checking that a particular ref has a value. Rather than checking if rev-parse produced output, we can just move rev-parse into the test itself, and rely on the exit code from --verify. Nobody else cares about the $head variable at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-14t9107: use "return 1" instead of "exit 1"Libravatar Jeff King1-16/+26
When a test runs a loop, it cannot rely on the usual &&-chaining to propagate a failure inside the loop; it needs to break out with a failure signal. However, unless you are in a subshell, doing so with "exit 1" will exit the entire test script, not just the test snippet we are in (and cause the harness to complain that test_done was never reached). So the fundamental point of this patch is s/exit/return/. But while we're there, let's fix a number of style and readability issues: - snippets in double-quotes need an extra layer of quoting for their meta-characters; let's avoid that by using single quotes - accumulating loop output by appending to a file in each iteration is brittle, as it can be affected by content left in the file by earlier tests. Instead, it's better to redirect stdout for the whole loop, so we know the output only comes from that loop. - using "test -z" to check that diff output is empty is overly verbose; we can just ask diff to use --exit-code. - we can factor out long lists of refs to make it more obvious we're using the same ones in each loop - subshells are unnecessary when ending an &&-chain with "|| return 1" - minor style fixups like space-after-redirection, and "do" and "done" on their own lines Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-13diff: run arguments through precompose_argvLibravatar Alexander Rinass1-0/+42
When running diff commands, a pathspec containing decomposed unicode code points is not converted to precomposed unicode form under Mac OS X, but we normalize the paths in the index and the history to precomposed form on that platform. As a result, the pathspec would not match and no diff is shown. Unlike many builtin commands, the "diff" family of commands do not use parse_options(), which is how other builtin commands indirectly call precompose_argv() to normalize argv[] into precomposed form on Mac OSX. Teach these commands to call precompose_argv() themselves. Note that precomopose_argv() normalizes not just paths but all command line arguments, so things like "git diff -G $string" when $string has the decomposed form would first be normalized into the precomposed form and would stop hitting the same string in the decomposed form in the diff output with this change. It is not a problem per-se, as "log" family of commands already use parse_options() and call precompose_argv()--we can think of this change as making the "diff" family of commands behave in a similar way as the commands in the "log" family. Signed-off-by: Alexander Rinass <alex@fournova.com> Helped-by: Torsten Bòˆgershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-13t9100,t3419: enclose all test code in single-quotesLibravatar Jeff King2-20/+20
A few tests here use double-quotes around the snippets of shell code to run the tests. None of these tests wants to do any interpolation at all, and it just leads to an extra layer of quoting around all double-quotes and dollar signs inside the snippet. Let's switch to single quotes, like most other test scripts. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-13t/lib-git-svn: drop $remote_git_svn and $git_svn_idLibravatar Jeff King11-63/+60
These variables were added in 16805d3 (t/t91XX-svn: start removing use of "git-" from these tests, 2008-09-08) so that running: git grep git- would return fewer hits. At the time, we were transitioning away from the use of the "dashed" git-foo form. That transition has been over for years, and grepping for "git-" in the test suite yields thousands of hits anyway (all presumably false positives). With their original purpose gone, these variables serve only to obfuscate the tests. Let's get rid of them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-13Merge branch 'sb/submodule-module-list-pathspec-fix'Libravatar Junio C Hamano1-1/+1
* sb/submodule-module-list-pathspec-fix: submodule deinit test: fix broken && chain in subshell
2016-05-13Merge branch 'jc/commit-tree-ignore-commit-gpgsign'Libravatar Junio C Hamano1-3/+10
"git commit-tree" plumbing command required the user to always sign its result when the user sets the commit.gpgsign configuration variable, which was an ancient mistake. Rework "git rebase" that relied on this mistake so that it reads commit.gpgsign and pass (or not pass) the -S option to "git commit-tree" to keep the end-user expectation the same, while teaching "git commit-tree" to ignore the configuration variable. This will stop requiring the users to sign commit objects used internally as an implementation detail of "git stash". * jc/commit-tree-ignore-commit-gpgsign: commit-tree: do not pay attention to commit.gpgsign
2016-05-13perf: run "rebase -i" under perfLibravatar Johannes Schindelin1-0/+36
This developer spent a lot of time trying to speed up the interactive rebase, in particular on Windows. And will continue to do so. To make it easier to demonstrate the performance improvement, let's have a reproducible performance test. The topic branch we use to test performance was found using these shell commands (essentially searching for a long-enough topic branch in Git's own history that touched the same file multiple times): git rev-list --parents origin/master | grep ' .* ' | while read commit rest do patch_count=$(git rev-list --count $commit^..$commit^2) test $patch_count -gt 20 || continue merges="$(git rev-list --parents $commit^..$commit^2 | grep ' .* ')" test -z "$merges" || continue patches_per_file="$(git log --pretty=%H --name-only \ $commit^..$commit^2 | grep -v '^$' | sort | uniq -c -d | sort -n -r)" test -n "$patches_per_file" && test 20 -lt $(echo "$patches_per_file" | sed -n '1s/^ *\([0-9]*\).*/\1/p') || continue printf 'commit %s\n%s\n' "$commit" "$patches_per_file" done Note that we can get away with *not* having to reset to the original branch tip before rebasing: we switch the first two "pick" lines every time, so we end up with the same patch order after two rebases, and the complexity of both rebases is equivalent. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-13perf: make the tests work in worktreesLibravatar Johannes Schindelin1-7/+7
This patch makes perf-lib.sh more robust so that it can run correctly even inside a worktree. For example, it assumed that $GIT_DIR/objects is the objects directory (which is not the case for worktrees) and it used the commondir file verbatim, even if it contained a relative path. Furthermore, the setup code expected `git rev-parse --git-dir` to spit out a relative path, which is also not true for worktrees. Let's just change the code to accept both relative and absolute paths, by avoiding the `cd` into the copied working directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-13perf: let's disable symlinks when they are not availableLibravatar Johannes Schindelin1-1/+4
We already have a perfectly fine prereq to tell us whether it is safe to use symlinks. So let's use it. This fixes the performance tests in Git for Windows' SDK, where symlinks are not really available ([*1*]). This is not an issue with Git for Windows itself because it configures core.symlinks=false in its system config. However, the system config is disabled for the performance tests, for obvious reasons: we want them to be independent of the vagaries of any local configuration. Footnote *1*: Windows has symbolic links. Git for Windows disables them by default, though (for example: in standard setups, non-admins lack the privilege to create symbolic links). For details, see https://github.com/git-for-windows/git/wiki/Symbolic-Links Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-12i18n: unpack-trees: avoid substituting only a verb in sentencesLibravatar Vasco Almeida1-9/+9
Instead of reusing the same set of message templates for checkout and other actions and substituting the verb with "%s", prepare separate message templates for each known action. That would make it easier for translation into languages where the same verb may conjugate differently depending on the message we are giving. See gettext documentation for details: http://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11test-lib: set BASH_XTRACEFD automaticallyLibravatar Jeff King2-3/+16
Passing "-x" to a test script enables the shell's "set -x" tracing, which can help with tracking down the command that is causing a failure. Unfortunately, it can also _cause_ failures in some tests that redirect the stderr of a shell function. Inside the function the shell continues to respect "set -x", and the trace output is collected along with whatever stderr is generated normally by the function. You can see an example of this by running: ./t0040-parse-options.sh -x -i which will fail immediately in the first test, as it expects: test_must_fail some-cmd 2>output.err to leave output.err empty (but with "-x" it has our trace output). Unfortunately there isn't a portable or scalable solution to this. We could teach test_must_fail to disable "set -x", but that doesn't help any of the other functions or subshells. However, we can work around it by pointing the "set -x" output to our descriptor 4, which always points to the original stderr of the test script. Unfortunately this only works for bash, but it's better than nothing (and other shells will just ignore the BASH_XTRACEFD variable). The patch itself is a simple one-liner, but note the caveats in the accompanying comments. Automatic tests for our "-x" option may be a bit too meta (and a pain, because they are bash-specific), but I did confirm that it works correctly both with regular "-x" and with "--verbose-only=1". This works because the latter flips "set -x" off and on for particular tests (if it didn't, we would get tracing for all tests, as going to descriptor 4 effectively circumvents the verbose flag). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11mingw: introduce the 'core.hideDotFiles' settingLibravatar Johannes Schindelin2-0/+50
On Unix (and Linux), files and directories whose names start with a dot are usually not shown by default. This convention is used by Git: the .git/ directory should be left alone by regular users, and only accessed through Git itself. On Windows, no such convention exists. Instead, there is an explicit flag to mark files or directories as hidden. In the early days, Git for Windows did not mark the .git/ directory (or for that matter, any file or directory whose name starts with a dot) hidden. This lead to quite a bit of confusion, and even loss of data. Consequently, Git for Windows introduced the core.hideDotFiles setting, with three possible values: true, false, and dotGitOnly, defaulting to marking only the .git/ directory as hidden. The rationale: users do not need to access .git/ directly, and indeed (as was demonstrated) should not really see that directory, either. However, not all dot files should be hidden by default, as e.g. Eclipse does not show them (and the user would therefore be unable to see, say, a .gitattributes file). In over five years since the last attempt to bring this patch into core Git, a slightly buggy version of this patch has served Git for Windows' users well: no single report indicated problems with the hidden .git/ directory, and the stream of problems caused by the previously non-hidden .git/ directory simply stopped. The bugs have been fixed during the process of getting this patch upstream. Note that there is a funny quirk we have to pay attention to when creating hidden files: we use Win32's _wopen() function which transmogrifies its arguments and hands off to Win32's CreateFile() function. That latter function errors out with ERROR_ACCESS_DENIED (the equivalent of EACCES) when the equivalent of the O_CREAT flag was passed and the file attributes (including the hidden flag) do not match an existing file's. And _wopen() accepts no parameter that would be transmogrified into said hidden flag. Therefore, we simply try again without O_CREAT. A slightly different method is required for our fopen()/freopen() function as we cannot even *remove* the implicit O_CREAT flag. Therefore, we briefly mark existing files as unhidden when opening them via fopen()/freopen(). The ERROR_ACCESS_DENIED error can also be triggered by opening a file that is marked as a system file (which is unlikely to be tracked in Git), and by trying to create a file that has *just* been deleted and is awaiting the last open handles to be released (which would be handled better by the "Try again?" logic, a story for a different patch series, though). In both cases, it does not matter much if we try again without the O_CREAT flag, read: it does not hurt, either. For details how ERROR_ACCESS_DENIED can be triggered, see https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858 Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com> Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-10Merge branch 'sb/clean-test-fix'Libravatar Junio C Hamano1-1/+1
* sb/clean-test-fix: t7300: mark test with SANITY
2016-05-10Merge branch 'js/close-packs-before-gc'Libravatar Junio C Hamano1-0/+1
* js/close-packs-before-gc: t5510: run auto-gc in the foreground
2016-05-10Merge branch 'ls/p4-lfs'Libravatar Junio C Hamano1-0/+4
Recent update to Git LFS broke "git p4" by changing the output from its "lfs pointer" subcommand. * ls/p4-lfs: git-p4: fix Git LFS pointer parsing travis-ci: express Linux/OS X dependency versions more clearly travis-ci: update Git-LFS and P4 to the latest version
2016-05-10t0040: convert a few tests to use test-parse-options --expectLibravatar Junio C Hamano1-18/+2
As a small example of using "test-parse-options --expect", rewrite the "check" helper using it, instead of comparing the whole variable dump. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-10t0040: remove unused test helpersLibravatar Junio C Hamano1-24/+0
9a001381 (Fix tests under GETTEXT_POISON on parseopt, 2012-08-27) introduced check_i18n, but the helper was never used from the beginning. The same commit also introduced check_unknown_i18n to replace the helper check_unknown and changed all users of the latter to use the former, but failed to remove check_unknown itself. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-10test-parse-options: --expect=<string> option to simplify testsLibravatar Junio C Hamano1-0/+1
Existing tests in t0040 follow a rather verbose pattern: cat >expect <<\EOF boolean: 0 integer: 0 magnitude: 0 timestamp: 0 string: (not set) abbrev: 7 verbose: 0 quiet: 3 dry run: no file: (not set) EOF test_expect_success 'multiple quiet levels' ' test-parse-options -q -q -q >output 2>output.err && test_must_be_empty output.err && test_cmp expect output ' But the only thing this test cares about is if "quiet: 3" is in the output. We should be able to write the above 18 lines with just four lines, like this: test_expect_success 'multiple quiet levels' ' test-parse-options --expect="quiet: 3" -q -q -q ' Teach the new --expect=<string> option to test-parse-options helper. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-10test-parse-options: fix output when callback option failsLibravatar Junio C Hamano1-3/+1
When test-parse-options detects an error on the command line, it gives the usage string just like any parse-options API users do, without showing any "variable dump". An exception is the callback test, where a "variable dump" for the option is done before the command line options are fully parsed. Do not expose this implementation detail by separating the handling of callback test into two phases, one to capture the fact that an option was given during the option parsing phase, and the other to show that fact as a part of normal "variable dump". The effect of this fix is seen in the patch to t/t0040 where it tried "test-parse-options --no-length" where "--length" is a callback that does not take a negative form. Signed-off-by: Junio C Hamano <gitster@pobox.com>