summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2012-09-14Merge branch 'rj/tap-fix'Libravatar Junio C Hamano4-63/+81
* rj/tap-fix: test-lib.sh: Suppress the "passed all ..." message if no tests run test-lib.sh: Add check for invalid use of 'skip_all' facility test-lib.sh: Fix some shell coding style violations t4016-*.sh: Skip all tests rather than each test t3902-*.sh: Skip all tests rather than each test t3300-*.sh: Fix a TAP parse error
2012-09-12Merge branch 'nd/maint-remote-remove'Libravatar Junio C Hamano2-3/+3
* nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'
2012-09-11Merge branch 'rj/test-regex'Libravatar Junio C Hamano1-0/+5
Git ships with a fall-back regexp implementation for platforms with buggy regexp library; give people a tool to see if they should be using it on their platform. * rj/test-regex: test-regex: Add a test to check for a bug in the regex routines
2012-09-10Merge branch 'cn/branch-set-upstream-to'Libravatar Junio C Hamano1-0/+70
"git branch --set-upstream origin/master" is a common mistake to create a local branch 'origin/master' and set it to integrate with the current branch. With a plan to deprecate this option, introduce "git branch (-u|--set-upstream-to) origin/master" that sets the current branch to integrate with 'origin/master' remote tracking branch. * cn/branch-set-upstream-to: branch: deprecate --set-upstream and show help if we detect possible mistaken use branch: add --unset-upstream option branch: introduce --set-upstream-to
2012-09-10Merge branch 'mz/cherry-pick-cmdline-order'Libravatar Junio C Hamano2-0/+25
"git cherry-pick A C B" used to replay changes in A and then B and then C if these three commits had committer timestamps in that order, which is not what the user who said "A C B" naturally expects. * mz/cherry-pick-cmdline-order: cherry-pick/revert: respect order of revisions to pick demonstrate broken 'git cherry-pick three one two' teach log --no-walk=unsorted, which avoids sorting
2012-09-10Merge branch 'jk/maint-quiet-is-synonym-to-s-in-log'Libravatar Junio C Hamano1-0/+12
We tried to bend backwards to allow "--quiet" to be a synonym as "-s" when given as e.g. "git show --quiet", but did not quite succeed. * jk/maint-quiet-is-synonym-to-s-in-log: log: fix --quiet synonym for -s
2012-09-07Merge branch 'jk/maint-http-half-auth-push'Libravatar Junio C Hamano6-75/+127
Pushing to smart HTTP server with recent Git fails without having the username in the URL to force authentication, if the server is configured to allow GET anonymously, while requiring authentication for POST. * jk/maint-http-half-auth-push: http: prompt for credentials on failed POST http: factor out http error code handling t: test http access to "half-auth" repositories t: test basic smart-http authentication t/lib-httpd: recognize */smart/* repos as smart-http t/lib-httpd: only route auth/dumb to dumb repos t5550: factor out http auth setup t5550: put auth-required repo in auth/dumb
2012-09-07Merge branch 'jc/apply-binary-p0'Libravatar Junio C Hamano1-21/+33
"git apply -p0" did not parse pathnames on "diff --git" line correctly. This caused patches that had pathnames in no other places to be mistakenly rejected (most notably, binary patch that does not rename nor change mode). Textual patches, renames or mode changes have preimage and postimage pathnames in different places in a form that can be parsed unambiguously and did not suffer from this problem. * jc/apply-binary-p0: apply: compute patch->def_name correctly under -p0
2012-09-07Merge branch 'jc/dotdot-is-parent-directory'Libravatar Junio C Hamano2-0/+21
"git log .." errored out saying it is both rev range and a path when there is no disambiguating "--" is on the command line. Update the command line parser to interpret ".." as a path in such a case. * jc/dotdot-is-parent-directory: specifying ranges: we did not mean to make ".." an empty set
2012-09-07Merge branch 'kk/maint-for-each-ref-multi-sort'Libravatar Junio C Hamano1-0/+10
"git for-each-ref" did not currectly support more than one --sort option. * kk/maint-for-each-ref-multi-sort: for-each-ref: Fix sort with multiple keys t6300: test sort with multiple keys
2012-09-07Merge branch 'pw/p4-use-client-spec-branch-detection'Libravatar Junio C Hamano3-17/+94
Fix "git p4" when "--use-client-spec" and "--detect-branches" are used together (the command used to misdetect branches). * pw/p4-use-client-spec-branch-detection: git p4: make branch detection work with --use-client-spec git p4: do wildcard decoding in stripRepoPath git p4: set self.branchPrefixes in initialization git p4 test: add broken --use-client-spec --detect-branches tests git p4 test: move client_view() function to library
2012-09-07Merge branch 'nd/i18n-poison-test-updates'Libravatar Junio C Hamano23-53/+83
Update tests that can be broken with gettext-poison builds. * nd/i18n-poison-test-updates: Fix tests under GETTEXT_POISON on parseopt Fix tests under GETTEXT_POISON on git-remote Fix tests under GETTEXT_POISON on pack-object Fix tests under GETTEXT_POISON on git-apply Fix tests under GETTEXT_POISON on diffstat Fix tests under GETTEXT_POISON on git-stash Fix tests under GETTEXT_POISON on relative dates
2012-09-06remote: prefer subcommand name 'remove' to 'rm'Libravatar Nguyễn Thái Ngọc Duy2-3/+3
All remote subcommands are spelled out words except 'rm'. 'rm', being a popular UNIX command name, may mislead users that there are also 'ls' or 'mv'. Use 'remove' to fit with the rest of subcommands. 'rm' is still supported and used in the test suite. It's just not widely advertised. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-03Merge branch 'sz/submodule-force-update'Libravatar Junio C Hamano1-0/+12
"git submodule update --force" used to leave the working tree of the submodule intact when there were local changes. It is more intiutive to make "--force" a sign to run "checkout -f" to overwrite them. * sz/submodule-force-update: Make 'git submodule update --force' always check out submodules.
2012-09-03Merge branch 'ph/stash-rerere'Libravatar Junio C Hamano1-0/+38
"git stash" internally used "git merge-recursive" backend, which did not trigger "rerere" upon conflicts unlike other mergy operations. * ph/stash-rerere: stash: invoke rerere in case of conflict test: git-stash conflict sets up rerere
2012-09-03Merge branch 'cw/cherry-pick-allow-empty-message'Libravatar Junio C Hamano1-0/+5
"git cherry-pick" by default stops when it sees a commit without any log message. The "--allow-empty-message" option can be used to silently proceed. * cw/cherry-pick-allow-empty-message: cherry-pick: add --allow-empty-message option
2012-09-02test-lib.sh: Suppress the "passed all ..." message if no tests runLibravatar Ramsay Jones1-1/+4
If a test script issues a test_done without executing any tests, for example when using the 'skip_all' facility, the output looks something like this: $ ./t9159-git-svn-no-parent-mergeinfo.sh # passed all 0 test(s) 1..0 # SKIP skipping git svn tests, svn not found $ The "passed all 0 test(s)" comment line, while correct, looks a little strange. Add a check to suppress this message if no tests have actually been run. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02test-lib.sh: Add check for invalid use of 'skip_all' facilityLibravatar Ramsay Jones1-0/+4
The 'skip_all' facility cannot be used after one or more tests have been executed using (for example) 'test_expect_success'. To do so results in invalid TAP output, which leads to 'prove' complaining of "Parse errors: No plan found in TAP output". Add a check for such invalid usage and abort the test with an error message to alert the test author. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02test-lib.sh: Fix some shell coding style violationsLibravatar Ramsay Jones1-22/+38
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02t4016-*.sh: Skip all tests rather than each testLibravatar Ramsay Jones1-11/+9
Each test in this file is skipped if the TABS_IN_FILENAMES test prerequisite is set. Use the 'skip_all' facility at the head of the file to skip all of the tests instead. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02t3902-*.sh: Skip all tests rather than each testLibravatar Ramsay Jones1-16/+15
Each test in this file is skipped if the TABS_IN_FILENAMES test prerequisite is set. Use the 'skip_all' facility at the head of the file to skip all of the tests instead. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02t3300-*.sh: Fix a TAP parse errorLibravatar Ramsay Jones1-13/+11
At present, running the t3300-*.sh test on cygwin looks like: $ cd t $ ./t3300-funny-names.sh ok 1 - setup # passed all 1 test(s) 1..1 # SKIP Your filesystem does not allow tabs in filenames $ Unfortunately, this is not valid TAP output, which prove notes as follows: $ prove --exec sh t3300-funny-names.sh t3300-funny-names.sh .. All 1 subtests passed Test Summary Report ------------------- t3300-funny-names.sh (Wstat: 0 Tests: 1 Failed: 0) Parse errors: No plan found in TAP output Files=1, Tests=1, 2 wallclock secs ( 0.05 usr 0.00 sys + \ 0.90 cusr 0.49 csys = 1.43 CPU) Result: FAIL $ This is due to the 'trailing_plan' having a 'skip_directive' attached to it. This is not allowed by the TAP grammar, which only allows a 'leading_plan' to be followed by an optional 'skip_directive'. (see perldoc TAP::Parser::Grammar). A trailing_plan is one that appears in the TAP output after one or more test status lines (that start 'not '? 'ok ' ...), whereas a leading_plan must appear before all test status lines (if any). In practice, this means that the test script cannot contain a use of the 'skip all' facility: skip_all='Some reason to skip *all* tests in this file' test_done after having already executed one or more tests with (for example) 'test_expect_success'. Unfortunately, this is exactly what this test script is doing. The first 'setup' test is actually used to determine if the test prerequisite is satisfied by the filesystem (ie does it allow tabs in filenames?). In order to fix the parse errors, place the code to determine the test prerequisite at the top level of the script, prior to the first test, rather than as a parameter to test_expect_success. This allows us to correctly use 'skip_all', thus: $ ./t3300-funny-names.sh # passed all 0 test(s) 1..0 # SKIP Your filesystem does not allow tabs in filenames $ $ prove --exec sh t3300-funny-names.sh t3300-funny-names.sh .. skipped: Your filesystem does not \ allow tabs in filenames Files=1, Tests=0, 2 wallclock secs ( 0.02 usr 0.03 sys + \ 0.84 cusr 0.41 csys = 1.29 CPU) Result: NOTESTS $ Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-02test-regex: Add a test to check for a bug in the regex routinesLibravatar Ramsay Jones1-0/+5
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30cherry-pick/revert: respect order of revisions to pickLibravatar Martin von Zweigbergk1-1/+1
When giving multiple individual revisions to cherry-pick or revert, as in 'git cherry-pick A B' or 'git revert B A', one would expect them to be picked/reverted in the order given on the command line. They are instead ordered by their commit timestamp -- in chronological order for "cherry-pick" and in reverse chronological order for "revert". This matches the order in which one would usually give them on the command line, making this bug somewhat hard to notice. Still, it has been reported at least once before [1]. It seems like the chronological sorting happened by accident because the revision walker has traditionally always sorted commits in reverse chronological order when rev_info.no_walk was enabled. In the case of 'git revert B A' where B is newer than A, this sorting is a no-op. For 'git cherry-pick A B', the sorting would reverse the arguments, but because the sequencer also flips the rev_info.reverse flag when picking (as opposed to reverting), the end result is a chronological order. The rev_info.reverse flag was probably flipped so that the revision walker emits B before C in 'git cherry-pick A..C'; that it happened to effectively undo the unexpected sorting done when not walking, was probably a coincidence that allowed this bug to happen at all. Fix the bug by telling the revision walker not to sort the commits when not walking. The only case we want to reverse the order is now when cherry-picking and walking revisions (rev_info.no_walk = 0). [1] http://thread.gmane.org/gmane.comp.version-control.git/164794 Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30demonstrate broken 'git cherry-pick three one two'Libravatar Martin von Zweigbergk1-0/+15
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't currently work. Add a test case to demonstrate it. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30teach log --no-walk=unsorted, which avoids sortingLibravatar Martin von Zweigbergk1-0/+10
When 'git log' is passed the --no-walk option, no revision walk takes place, naturally. Perhaps somewhat surprisingly, however, the provided revisions still get sorted by commit date. So e.g 'git log --no-walk HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result (unless the two revisions share the commit date, in which case they will retain the order given on the command line). As the commit that introduced --no-walk (8e64006 (Teach revision machinery about --no-walk, 2007-07-24)) points out, the sorting is intentional, to allow things like git log --abbrev-commit --pretty=oneline --decorate --all --no-walk to show all refs in order by commit date. But there are also other cases where the sorting is not wanted, such as <command producing revisions in order> | git log --oneline --no-walk --stdin To accomodate both cases, leave the decision of whether or not to sort up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting to 'sorted' for backward-compatibility reasons. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30branch: deprecate --set-upstream and show help if we detect possible ↵Libravatar Carlos Martín Nieto1-0/+34
mistaken use This interface is error prone, and a better one (--set-upstream-to) exists. Add a message listing the alternatives and suggest how to fix a --set-upstream invocation in case the user only gives one argument which causes a local branch with the same name as a remote-tracking one to be created. The typical case is git branch --set-upstream origin/master when the user meant git branch --set-upstream master origin/master assuming that the current branch is master. Show a message telling the user how to undo their action and get what they wanted. For the command above, the message would be The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch origin/master set up to track local branch master. If you wanted to make 'master' track 'origin/master', do this: git branch -d origin/master git branch --set-upstream-to origin/master Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30branch: add --unset-upstream optionLibravatar Carlos Martín Nieto1-0/+22
We have ways of setting the upstream information, but if we want to unset it, we need to resort to modifying the configuration manually. Teach branch an --unset-upstream option that unsets this information. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-29Merge branch 'ef/win32-cred-helper'Libravatar Junio C Hamano1-0/+4
Credential helper for Win32 to allow access to the keychain of the logged-in user. * ef/win32-cred-helper: contrib: add win32 credential-helper
2012-08-29Merge branch 'hv/submodule-path-unmatch'Libravatar Junio C Hamano1-4/+22
* hv/submodule-path-unmatch: Let submodule command exit with error status if path does not exist
2012-08-29Merge branch 'mz/empty-rebase-test'Libravatar Junio C Hamano1-1/+17
* mz/empty-rebase-test: add tests for 'git rebase --keep-empty'
2012-08-28log: fix --quiet synonym for -sLibravatar Jeff King1-0/+12
Originally the "--quiet" option was parsed by the diff-option parser into the internal QUICK option. This had the effect of silencing diff output from the log (which was not intended, but happened to work and people started to use it). But it also had other odd side effects at the diff level (for example, it would suppress the second commit in "git show A B"). To fix this, commit 1c40c36 converted log to parse-options and handled the "quiet" option separately, not passing it on to the diff code. However, it simply ignored the option, which was a regression for people using it as a synonym for "-s". Commit 01771a8 then fixed that by interpreting the option to add DIFF_FORMAT_NO_OUTPUT to the list of output formats. However, that commit did not fix it in all cases. It sets the flag after setup_revisions is called. Naively, this makes sense because you would expect the setup_revisions parser to overwrite our output format flag if "-p" or another output format flag is seen. However, that is not how the NO_OUTPUT flag works. We actually store it in the bit-field as just another format. At the end of setup_revisions, we call diff_setup_done, which post-processes the bitfield and clears any other formats if we have set NO_OUTPUT. By setting the flag after setup_revisions is done, diff_setup_done does not have a chance to make this tweak, and we end up with other format options still set. As a result, the flag would have no effect in "git log -p --quiet" or "git show --quiet". Fix it by setting the format flag before the call to setup_revisions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Merge branch 'js/grep-patterntype-config'Libravatar Junio C Hamano1-0/+181
"grep" learned to use a non-standard pattern type by default if a configuration variable tells it to. * js/grep-patterntype-config: grep: add a grep.patternType configuration setting
2012-08-27Merge branch 'bc/receive-pack-stdout-protection'Libravatar Junio C Hamano1-0/+35
When "git push" triggered the automatic gc on the receiving end, a message from "git prune" that said it was removing cruft leaked to the standard output, breaking the communication protocol. * bc/receive-pack-stdout-protection: receive-pack: do not leak output from auto-gc to standard output t/t5400: demonstrate breakage caused by informational message from prune
2012-08-27Merge branch 'ab/diff-write-incomplete-line'Libravatar Junio C Hamano1-0/+30
The output from "git diff -B" for a file that ends with an incomplete line did not put "\ No newline..." on a line of its own. * ab/diff-write-incomplete-line: Fix '\ No newline...' annotation in rewrite diffs
2012-08-27Merge branch 'jc/maint-t7406-rev-parse-max-count-huh'Libravatar Junio C Hamano1-8/+8
Test clean-up, with no behaviour change. * jc/maint-t7406-rev-parse-max-count-huh: t7406: fix misleading "rev-parse --max-count=1 HEAD"
2012-08-27Merge branch 'jk/maint-null-in-trees'Libravatar Junio C Hamano3-0/+128
We do not want a link to 0{40} object stored anywhere in our objects. * jk/maint-null-in-trees: fsck: detect null sha1 in tree entries do not write null sha1s to on-disk index diff: do not use null sha1 as a sentinel value
2012-08-27Merge branch 'mm/push-default-switch-warning'Libravatar Junio C Hamano1-1/+4
In the next major release, we will switch "git push [$there]" that does not say what to push from the traditional "matching" to the updated "simple" semantics, that pushes the current branch to the branch with the same name only when the current branch is set to integrate with that remote branch (all other cases will error out). * mm/push-default-switch-warning: push: start warning upcoming default change for push.default
2012-08-27http: prompt for credentials on failed POSTLibravatar Jeff King1-1/+1
All of the smart-http GET requests go through the http_get_* functions, which will prompt for credentials and retry if we see an HTTP 401. POST requests, however, do not go through any central point. Moreover, it is difficult to retry in the general case; we cannot assume the request body fits in memory or is even seekable, and we don't know how much of it was consumed during the attempt. Most of the time, this is not a big deal; for both fetching and pushing, we make a GET request before doing any POSTs, so typically we figure out the credentials during the first request, then reuse them during the POST. However, some servers may allow a client to get the list of refs from receive-pack without authentication, and then require authentication when the client actually tries to POST the pack. This is not ideal, as the client may do a non-trivial amount of work to generate the pack (e.g., delta-compressing objects). However, for a long time it has been the recommended example configuration in git-http-backend(1) for setting up a repository with anonymous fetch and authenticated push. This setup has always been broken without putting a username into the URL. Prior to commit 986bbc0, it did work with a username in the URL, because git would prompt for credentials before making any requests at all. However, post-986bbc0, it is totally broken. Since it has been advertised in the manpage for some time, we should make sure it works. Unfortunately, it is not as easy as simply calling post_rpc again when it fails, due to the input issue mentioned above. However, we can still make this specific case work by retrying in two specific instances: 1. If the request is large (bigger than LARGE_PACKET_MAX), we will first send a probe request with a single flush packet. Since this request is static, we can freely retry it. 2. If the request is small and we are not using gzip, then we have the whole thing in-core, and we can freely retry. That means we will not retry in some instances, including: 1. If we are using gzip. However, we only do so when calling git-upload-pack, so it does not apply to pushes. 2. If we have a large request, the probe succeeds, but then the real POST wants authentication. This is an extremely unlikely configuration and not worth worrying about. While it might be nice to cover those instances, doing so would be significantly more complex for very little real-world gain. In the long run, we will be much better off when curl learns to internally handle authentication as a callback, and we can cleanly handle all cases that way. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27t: test http access to "half-auth" repositoriesLibravatar Jeff King3-0/+28
Some sites set up http access to repositories such that fetching is anonymous and unauthenticated, but pushing is authenticated. While there are multiple ways to do this, the technique advertised in the git-http-backend manpage is to block access to locations matching "/git-receive-pack$". Let's emulate that advice in our test setup, which makes it clear that this advice does not actually work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27t: test basic smart-http authenticationLibravatar Jeff King2-0/+25
We do not currently test authentication over smart-http at all. In theory, it should work exactly as it does for dumb http (which we do test). It does indeed work for these simple tests, but this patch lays the groundwork for more complex tests in future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27t/lib-httpd: recognize */smart/* repos as smart-httpLibravatar Jeff King1-9/+7
We do not currently test authentication for smart-http repos at all. Part of the infrastructure to do this is recognizing that auth/smart is indeed a smart-http repo. The current apache config recognizes only "^/smart/*" as smart-http. Let's instead treat anything with /smart/ in the URL as smart-http. This is obviously a stupid thing to do for a real production site, but for our test suite we know that our repositories will not have this magic string in the name. Note that we will route /foo/smart/bar.git directly to git-http-backend/bar.git; in other words, everything before the "/smart/" is irrelevant to finding the repo on disk (but may impact apache config, for example by triggering auth checks). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27t/lib-httpd: only route auth/dumb to dumb reposLibravatar Jeff King1-1/+1
Our test apache config points all of auth/ directly to the on-disk repositories via an Alias directive. This works fine because everything authenticated is currently in auth/dumb, which is a subset. However, this would conflict with a ScriptAlias for auth/smart (which will come in future patches), so let's narrow the Alias. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27t5550: factor out http auth setupLibravatar Jeff King3-54/+55
The t5550 script sets up a nice askpass helper for simulating user input and checking what git prompted for. Let's make it available to other http scripts by migrating it to lib-httpd. We can use this immediately in t5540 to make our tests more robust (previously, we did not check at all that hitting the password-protected repo actually involved a password). Unfortunately, we end up failing the test because the current code erroneously prompts twice (once for git-remote-http, and then again when the former spawns git-http-push). More importantly, though, it will let us easily add smart-http authentication tests in t5541 and t5551; we currently do not test smart-http authentication at all. As part of making it generic, let's always look for and store auxiliary askpass files at the top-level trash directory; this makes it compatible with t5540, which runs some tests from sub-repositories. We can abstract away the ugliness with a short helper function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27t5550: put auth-required repo in auth/dumbLibravatar Jeff King1-9/+9
In most of our tests, we put repos to be accessed by dumb protocols in /dumb, and repos to be accessed by smart protocols in /smart. In our test apache setup, the whole /auth hierarchy requires authentication. However, we don't bother to split it by smart and dumb here because we are not currently testing smart-http authentication at all. That will change in future patches, so let's be explicit that we are interested in testing dumb access here. This also happens to match what t5540 does for the push tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on parseoptLibravatar Jiang Xin11-22/+46
Use the i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on git-remoteLibravatar Jiang Xin1-11/+17
Use the i18n-specific test functions in test scripts for git-remote. This issue was was introduced in v1.7.10-233-gbb16d5: bb16d5 i18n: remote: mark strings for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on pack-objectLibravatar Jiang Xin2-4/+4
Use the i18n-specific test functions in test scripts for pack-object. This issue was was introduced in v1.7.10.2-556-g46140: 46140 index-pack: use streaming interface for collision test on large blobs cf2ba pack-objects: use streaming interface for reading large loose blobs and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on git-applyLibravatar Jiang Xin3-6/+6
Use the i18n-specific test functions in test scripts for git-apply. This issue was was introduced in the following commits: de373 i18n: apply: mark parseopt strings for translation 3638e i18n: apply: mark strings for translation and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on diffstatLibravatar Jiang Xin4-8/+8
Use the i18n-specific test functions in test scripts for diffstat. This issue was was introduced in v1.7.9-1-g7f814: 7f814 Use correct grammar in diffstat summary line and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>