summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2011-12-19Merge branch 'jk/maint-push-over-dav'Libravatar Junio C Hamano2-0/+37
* jk/maint-push-over-dav: http-push: enable "proactive auth" t5540: test DAV push with authentication Conflicts: http.c
2011-12-19Merge branch 'jk/fetch-no-tail-match-refs'Libravatar Junio C Hamano2-3/+32
* jk/fetch-no-tail-match-refs: connect.c: drop path_match function fetch-pack: match refs exactly t5500: give fully-qualified refs to fetch-pack drop "match" parameter from get_remote_heads
2011-12-19Merge branch 'jn/maint-sequencer-fixes'Libravatar Junio C Hamano2-58/+156
* jn/maint-sequencer-fixes: revert: stop creating and removing sequencer-old directory Revert "reset: Make reset remove the sequencer state" revert: do not remove state until sequence is finished revert: allow single-pick in the middle of cherry-pick sequence revert: pass around rev-list args in already-parsed form revert: allow cherry-pick --continue to commit before resuming revert: give --continue handling its own function
2011-12-19Merge branch 'rr/test-chaining'Libravatar Junio C Hamano15-199/+123
* rr/test-chaining: t3401: use test_commit in setup t3401: modernize style t3040 (subprojects-basic): fix '&&' chaining, modernize style t1510 (worktree): fix '&&' chaining t3030 (merge-recursive): use test_expect_code test: fix '&&' chaining t3200 (branch): fix '&&' chaining
2011-12-19Merge branch 'tr/cache-tree'Libravatar Junio C Hamano1-0/+95
* tr/cache-tree: reset: update cache-tree data when appropriate commit: write cache-tree data when writing index anyway Refactor cache_tree_update idiom from commit Test the current state of the cache-tree optimization Add test-scrap-cache-tree
2011-12-19Merge branch 'jk/credentials'Libravatar Junio C Hamano7-12/+665
* jk/credentials: t: add test harness for external credential helpers credentials: add "store" helper strbuf: add strbuf_add*_urlencode Makefile: unix sockets may not available on some platforms credentials: add "cache" helper docs: end-user documentation for the credential subsystem credential: make relevance of http path configurable credential: add credential.*.username credential: apply helper config http: use credential API to get passwords credential: add function for parsing url components introduce credentials API t5550: fix typo test-lib: add test_config_global variant Conflicts: strbuf.c
2011-12-17git-p4: fix skipSubmitEdit regressionLibravatar Pete Wyckoff1-1/+23
Commit 7c766e5 (git-p4: introduce skipSubmitEdit, 2011-12-04) made it easier to automate submission to p4, but broke the most common case. Add a test for when the user really does edit and save the change template, and fix the bug that causes the test to fail. Also add a confirmation message when submission is cancelled. Reported-by: Michael Horowitz <michael.horowitz@ieee.org> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-16Merge branch 'jc/commit-amend-no-edit'Libravatar Junio C Hamano1-152/+167
* jc/commit-amend-no-edit: test: commit --amend should honor --no-edit commit: honour --no-edit t7501 (commit): modernize style test: remove a porcelain test that hard-codes commit names test: add missing "&&" after echo command
2011-12-16Merge branch 'jc/stream-to-pack'Libravatar Junio C Hamano1-9/+85
* jc/stream-to-pack: bulk-checkin: replace fast-import based implementation csum-file: introduce sha1file_checkpoint finish_tmp_packfile(): a helper function create_tmp_packfile(): a helper function write_pack_header(): a helper function Conflicts: pack.h
2011-12-16Merge branch 'jh/fast-import-notes'Libravatar Junio C Hamano1-5/+58
* jh/fast-import-notes: fast-import: Fix incorrect fanout level when modifying existing notes refs t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
2011-12-16Merge branch 'jk/upload-archive-use-start-command'Libravatar Junio C Hamano1-5/+5
* jk/upload-archive-use-start-command: upload-archive: use start_command instead of fork
2011-12-13Merge branch 'bc/maint-apply-check-no-patch'Libravatar Junio C Hamano2-1/+20
* bc/maint-apply-check-no-patch: builtin/apply.c: report error on failure to recognize input t/t4131-apply-fake-ancestor.sh: fix broken test
2011-12-13Merge branch 'jn/branch-move-to-self'Libravatar Junio C Hamano2-4/+21
* jn/branch-move-to-self: Allow checkout -B <current-branch> to update the current branch branch: allow a no-op "branch -M <current-branch> HEAD"
2011-12-13Merge branch 'jk/maint-upload-archive'Libravatar Junio C Hamano1-0/+8
* jk/maint-upload-archive: archive: don't let remote clients get unreachable commits
2011-12-13Merge branch 'jn/gitweb-side-by-side-diff'Libravatar Junio C Hamano1-1/+72
* jn/gitweb-side-by-side-diff: gitweb: Add navigation to select side-by-side diff gitweb: Use href(-replay=>1,...) for formats links in "commitdiff" t9500: Add basic sanity tests for side-by-side diff in gitweb t9500: Add test for handling incomplete lines in diff by gitweb gitweb: Give side-by-side diff extra CSS styling gitweb: Add a feature to show side-by-side diff gitweb: Extract formatting of diff chunk header gitweb: Refactor diff body line classification
2011-12-13http-push: enable "proactive auth"Libravatar Jeff King1-1/+1
Before commit 986bbc08, git was proactive about asking for http passwords. It assumed that if you had a username in your URL, you would also want a password, and asked for it before making any http requests. However, this could interfere with the use of .netrc (see 986bbc08 for details). And it was also unnecessary, since the http fetching code had learned to recognize an HTTP 401 and prompt the user then. Furthermore, the proactive prompt could interfere with the usage of .netrc (see 986bbc08 for details). Unfortunately, the http push-over-DAV code never learned to recognize HTTP 401, and so was broken by this change. This patch does a quick fix of re-enabling the "proactive auth" strategy only for http-push, leaving the dumb http fetch and smart-http as-is. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13t5540: test DAV push with authenticationLibravatar Jeff King2-0/+37
We don't currently test this case at all, and instead just test the DAV mechanism over an unauthenticated push. That isn't very realistic, as most people will want to authenticate pushes. Two of the tests expect_failure as they reveal bugs: 1. Pushing without a username in the URL fails to ask for credentials when we get an HTTP 401. This has always been the case, but it would be nice if it worked like smart-http. 2. Pushing with a username fails to ask for the password since 986bbc0 (http: don't always prompt for password, 2011-11-04). This is a severe regression in v1.7.8, as authenticated push-over-DAV is now totally unusable unless you have credentials in your .netrc. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13fetch-pack: match refs exactlyLibravatar Jeff King1-0/+29
When we are determining the list of refs to fetch via fetch-pack, we have two sets of refs to compare: those on the remote side, and a "match" list of things we want to fetch. We iterate through the remote refs alphabetically, seeing if each one is wanted by the "match" list. Since def88e9 (Commit first cut at "git-fetch-pack", 2005-07-04), we have used the "path_match" function to do a suffix match, where a remote ref is considered wanted if any of the "match" elements is a suffix of the remote refname. This enables callers of fetch-pack to specify unqualified refs and have them matched up with remote refs (e.g., ask for "A" and get remote's "refs/heads/A"). However, if you provide a fully qualified ref, then there are corner cases where we provide the wrong answer. For example, given a remote with two refs: refs/foo/refs/heads/master refs/heads/master asking for "refs/heads/master" will first match "refs/foo/refs/heads/master" by the suffix rule, and we will erroneously fetch it instead of refs/heads/master. As it turns out, all callers of fetch_pack do provide fully-qualified refs for the match list. There are two ways fetch_pack can get match lists: 1. Through the transport code (i.e., via git-fetch) 2. On the command-line of git-fetch-pack In the first case, we will always be providing the names of fully-qualified refs from "struct ref" objects. We will have pre-matched those ref objects already (since we have to handle more advanced matching, like wildcard refspecs), and are just providing a list of the refs whose objects we need. In the second case, users could in theory be providing non-qualified refs on the command-line. However, the fetch-pack documentation claims that refs should be fully qualified (and has always done so since it was written in 2005). Let's change this path_match call to simply check for string equality, matching what the callers of fetch_pack are expecting. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-13t5500: give fully-qualified refs to fetch-packLibravatar Jeff King1-3/+3
The fetch-pack documentation is very clear that refs given on the command line are to be full refs: <refs>...:: The remote heads to update from. This is relative to $GIT_DIR (e.g. "HEAD", "refs/heads/master"). When unspecified, update from all heads the remote side has. and this has been the case since fetch-pack was originally documented in 8b3d9dc ([PATCH] Documentation: clone/fetch/upload., 2005-07-14). Let's follow our own documentation to set a good example, and to avoid breaking when this restriction is enforced in the next patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12t: add test harness for external credential helpersLibravatar Jeff King1-0/+39
We already have tests for the internal helpers, but it's nice to give authors of external tools an easy way to sanity-check their helpers. If you have written the "git-credential-foo" helper, you can do so with: GIT_TEST_CREDENTIAL_HELPER=foo \ make t0303-credential-external.sh This assumes that your helper is capable of both storing and retrieving credentials (some helpers may be read-only, and they will fail these tests). If your helper supports time-based expiration with a configurable timeout, you can test that feature like this: GIT_TEST_CREDENTIAL_HELPER_TIMEOUT="foo --timeout=1" \ make t0303-credential-external.sh Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12credentials: add "store" helperLibravatar Jeff King1-0/+9
This is like "cache", except that we actually put the credentials on disk. This can be terribly insecure, of course, but we do what we can to protect them by filesystem permissions, and we warn the user in the documentation. This is not unlike using .netrc to store entries, but it's a little more user-friendly. Instead of putting credentials in place ahead of time, we transparently store them after prompting the user for them once. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12Makefile: unix sockets may not available on some platformsLibravatar Johannes Sixt1-0/+5
Introduce a configuration option NO_UNIX_SOCKETS to exclude code that depends on Unix sockets and use it in MSVC and MinGW builds. Notice that unix-socket.h was missing from LIB_H before; fix that, too. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12Revert "reset: Make reset remove the sequencer state"Libravatar Jonathan Nieder2-53/+1
This reverts commit 95eb88d8ee588d89b4f06d2753ed4d16ab13b39f, which was a UI experiment that did not reflect how "git reset" actually gets used. The reversion also fixes a test, indicated in the patch. Encouraged-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: do not remove state until sequence is finishedLibravatar Jonathan Nieder1-3/+3
As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes the sequencer state just before applying the final patch. In the single-pick case, that was a good thing, since --abort and --continue work fine without access to such state and removing it provides a signal that git should not complain about the need to clobber it ("a cherry-pick or revert is already in progress") in sequences like the following: git cherry-pick foo git read-tree -m -u HEAD; # forget that; let's try a different one git cherry-pick bar After the recent patch "allow single-pick in the middle of cherry-pick sequence" we don't need that hack any more. In the new regime, a traditional "git cherry-pick <commit>" command never looks at .git/sequencer, so we do not need to cripple "git cherry-pick <commit>..<commit>" for it any more. So now you can run "git cherry-pick --abort" near the end of a multi-pick sequence and it will abort the entire sequence, instead of misbehaving and aborting just the final commit. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: allow single-pick in the middle of cherry-pick sequenceLibravatar Jonathan Nieder1-0/+12
After messing up a difficult conflict resolution in the middle of a cherry-pick sequence, it can be useful to be able to git checkout HEAD . && git cherry-pick that-one-commit to restart the conflict resolution. The current code however errors out saying that another cherry-pick is already in progress. Suggested-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: pass around rev-list args in already-parsed formLibravatar Jonathan Nieder1-0/+5
Since 7e2bfd3f (revert: allow cherry-picking more than one commit, 2010-07-02), the pick/revert machinery has kept track of the set of commits to be cherry-picked or reverted using commit_argc and commit_argv variables, storing the corresponding command-line parameters. Future callers as other commands are built in (am, rebase, sequencer) may find it easier to pass rev-list options to this machinery in already-parsed form. Teach cmd_cherry_pick and cmd_revert to parse the rev-list arguments in advance and pass the commit set to pick_revisions() as a rev_info structure. Original patch by Jonathan, tweaks and test from Ram. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Improved-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-12revert: allow cherry-pick --continue to commit before resumingLibravatar Jonathan Nieder1-3/+136
When "git cherry-pick ..bar" encounters conflicts, permit the operator to use cherry-pick --continue after resolving them as a shortcut for "git commit && git cherry-pick --continue" to record the resolution and carry on with the rest of the sequence. This improves the analogy with "git rebase" (in olden days --continue was the way to preserve authorship when a rebase encountered conflicts) and fits well with a general UI goal of making "git cmd --continue" save humans the trouble of deciding what to do next. Example: after encountering a conflict from running "git cherry-pick foo bar baz": CONFLICT (content): Merge conflict in main.c error: could not apply f78a8d98c... bar! hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' We edit main.c to resolve the conflict, mark it acceptable with "git add main.c", and can run "cherry-pick --continue" to resume the sequence. $ git cherry-pick --continue [editor opens to confirm commit message] [master 78c8a8c98] bar! 1 files changed, 1 insertions(+), 1 deletions(-) [master 87ca8798c] baz! 1 files changed, 1 insertions(+), 1 deletions(-) This is done for both codepaths to pick multiple commits and a single commit. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11credentials: add "cache" helperLibravatar Jeff King2-0/+239
If you access repositories over smart-http using http authentication, then it can be annoying to have git ask you for your password repeatedly. We cache credentials in memory, of course, but git is composed of many small programs. Having to input your password for each one can be frustrating. This patch introduces a credential helper that will cache passwords in memory for a short period of time. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11credential: make relevance of http path configurableLibravatar Jeff King2-1/+30
When parsing a URL into a credential struct, we carefully record each part of the URL, including the path on the remote host, and use the result as part of the credential context. This had two practical implications: 1. Credential helpers which store a credential for later access are likely to use the "path" portion as part of the storage key. That means that a request to https://example.com/foo.git would not use the same credential that was stored in an earlier request for: https://example.com/bar.git 2. The prompt shown to the user includes all relevant context, including the path. In most cases, however, users will have a single password per host. The behavior in (1) will be inconvenient, and the prompt in (2) will be overly long. This patch introduces a config option to toggle the relevance of http paths. When turned on, we use the path as before. When turned off, we drop the path component from the context: helpers don't see it, and it does not appear in the prompt. This is nothing you couldn't do with a clever credential helper at the start of your stack, like: [credential "http://"] helper = "!f() { grep -v ^path= ; }; f" helper = your_real_helper But doing this: [credential] useHttpPath = false is way easier and more readable. Furthermore, since most users will want the "off" behavior, that is the new default. Users who want it "on" can set the variable (either for all credentials, or just for a subset using credential.*.useHttpPath). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11credential: add credential.*.usernameLibravatar Jeff King2-0/+29
Credential helpers can help users avoid having to type their username and password over and over. However, some users may not want a helper for their password, or they may be running a helper which caches for a short time. In this case, it is convenient to provide the non-secret username portion of their credential via config. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11credential: apply helper configLibravatar Jeff King2-0/+54
The functionality for credential storage helpers is already there; we just need to give the users a way to turn it on. This patch provides a "credential.helper" configuration variable which allows the user to provide one or more helper strings. Rather than simply matching credential.helper, we will also compare URLs in subsection headings to the current context. This means you can apply configuration to a subset of credentials. For example: [credential "https://example.com"] helper = foo would match a request for "https://example.com/foo.git", but not one for "https://kernel.org/foo.git". This is overkill for the "helper" variable, since users are unlikely to want different helpers for different sites (and since helpers run arbitrary code, they could do the matching themselves anyway). However, future patches will add new config variables where this extra feature will be more useful. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11http: use credential API to get passwordsLibravatar Jeff King1-11/+27
This patch converts the http code to use the new credential API, both for http authentication as well as for getting certificate passwords. Most of the code change is simply variable naming (the passwords are now contained inside the credential struct) or deletion of obsolete code (the credential code handles URL parsing and prompting for us). The behavior should be the same, with one exception: the credential code will prompt with a description based on the credential components. Therefore, the old prompt of: Username for 'example.com': Password for 'example.com': now looks like: Username for 'https://example.com/repo.git': Password for 'https://user@example.com/repo.git': Note that we include more information in each line, specifically: 1. We now include the protocol. While more noisy, this is an important part of knowing what you are accessing (especially if you care about http vs https). 2. We include the username in the password prompt. This is not a big deal when you have just been prompted for it, but the username may also come from the remote's URL (and after future patches, from configuration or credential helpers). In that case, it's a nice reminder of the user for which you're giving the password. 3. We include the path component of the URL. In many cases, the user won't care about this and it's simply noise (i.e., they'll use the same credential for a whole site). However, that is part of a larger question, which is whether path components should be part of credential context, both for prompting and for lookup by storage helpers. That issue will be addressed as a whole in a future patch. Similarly, for unlocking certificates, we used to say: Certificate Password for 'example.com': and we now say: Password for 'cert:///path/to/certificate': Showing the path to the client certificate makes more sense, as that is what you are unlocking, not "example.com". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11introduce credentials APILibravatar Jeff King2-0/+228
There are a few places in git that need to get a username and password credential from the user; the most notable one is HTTP authentication for smart-http pushing. Right now the only choices for providing credentials are to put them plaintext into your ~/.netrc, or to have git prompt you (either on the terminal or via an askpass program). The former is not very secure, and the latter is not very convenient. Unfortunately, there is no "always best" solution for password management. The details will depend on the tradeoff you want between security and convenience, as well as how git can integrate with other security systems (e.g., many operating systems provide a keychain or password wallet for single sign-on). This patch provides an abstract notion of credentials as a data item, and provides three basic operations: - fill (i.e., acquire from external storage or from the user) - approve (mark a credential as "working" for further storage) - reject (mark a credential as "not working", so it can be removed from storage) These operations can be backed by external helper processes that interact with system- or user-specific secure storage. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11t5550: fix typoLibravatar Jeff King1-1/+1
This didn't have an impact, because it was just setting up an "expect" file that happened to be identical to the one in the test before it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11test-lib: add test_config_global variantLibravatar Jeff King1-0/+5
The point of test_config is to simultaneously set a config variable and register its cleanup handler, like: test_config core.foo bar However, it stupidly assumes that $1 contained the name of the variable, which means it won't work for: test_config --global core.foo bar We could try to parse the command-line ourselves and figure out which parts need to be fed to test_unconfig. But since this is likely the most common variant, it's much simpler and less error-prone to simply add a new function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11t3401: use test_commit in setupLibravatar Martin von Zweigbergk1-25/+10
Simplify t3401 by using test_commit in the setup. This lets us refer to commits using their tags and there is no longer a need to create the branch my-topic-branch-merge. Also, the branch master-merge points to the same commit as master (even before this change), so that branch does not need to be created either. While at it, replace "test ! -d" by "test_path_is_missing". Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11t3401: modernize styleLibravatar Martin von Zweigbergk1-34/+33
Put the opening quote starting each test on the same line as the test_expect_* invocation. Also make sure to use tabs for indentation. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11git-p4: test for absolute PWD problemLibravatar Pete Wyckoff1-0/+49
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-11git-p4: submit test for auto-creating clientPathLibravatar Pete Wyckoff1-0/+38
Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09Merge branch 'jc/pull-signed-tag'Libravatar Junio C Hamano63-186/+189
* jc/pull-signed-tag: commit-tree: teach -m/-F options to read logs from elsewhere commit-tree: update the command line parsing commit: teach --amend to carry forward extra headers merge: force edit and no-ff mode when merging a tag object commit: copy merged signed tags to headers of merge commit merge: record tag objects without peeling in MERGE_HEAD merge: make usage of commit->util more extensible fmt-merge-msg: Add contents of merged tag in the merge message fmt-merge-msg: package options into a structure fmt-merge-msg: avoid early returns refs DWIMmery: use the same rule for both "git fetch" and others fetch: allow "git fetch $there v1.0" to fetch a tag merge: notice local merging of tags and keep it unwrapped fetch: do not store peeled tag object names in FETCH_HEAD Split GPG interface into its own helper library Conflicts: builtin/fmt-merge-msg.c builtin/merge.c
2011-12-09Merge branch 'jc/request-pull-show-head-4'Libravatar Junio C Hamano1-0/+10
* jc/request-pull-show-head-4: request-pull: use the annotated tag contents fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error environment.c: Fix an sparse "symbol not declared" warning builtin/log.c: Fix an "Using plain integer as NULL pointer" warning fmt-merge-msg: use branch.$name.description request-pull: use the branch description request-pull: state what commit to expect request-pull: modernize style branch: teach --edit-description option format-patch: use branch description in cover letter branch: add read_branch_desc() helper function Conflicts: builtin/branch.c
2011-12-09Merge branch 'ab/pull-rebase-config'Libravatar Junio C Hamano1-2/+21
* ab/pull-rebase-config: pull: introduce a pull.rebase option to enable --rebase
2011-12-09t3040 (subprojects-basic): fix '&&' chaining, modernize styleLibravatar Ramkumar Ramachandra1-72/+72
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Fix instances of this. While at it, clean up the style to fit the prevailing style. This means: - Put the opening quote starting each test on the same line as the test_expect_* invocation. - Indent the file with tabs, not spaces. - Use test_expect_code() in preference to checking the exit status of various statements by hand. - Guard commands that prepare test input for individual tests in the same test_expect_success, so that their scope is clearer and errors at that stage can be caught. - Use <<-\EOF in preference to <<EOF to save readers the trouble of looking for variable interpolations. - Include "setup" in the titles of test assertions that prepare for later ones to make it more obvious which tests can be skipped. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09t1510 (worktree): fix '&&' chainingLibravatar Ramkumar Ramachandra1-3/+3
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. 'unset' returns non-zero status when the variable passed was already unset on some shells; we need to change these instances to 'sane_unset'. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-09t3030 (merge-recursive): use test_expect_codeLibravatar Ramkumar Ramachandra1-66/+6
Use test_expect_code in preference to repeatedly checking exit codes by hand. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08test: fix '&&' chainingLibravatar Ramkumar Ramachandra10-17/+17
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain by adding " &&" at the end of line to the commands that need them. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08t3200 (branch): fix '&&' chainingLibravatar Ramkumar Ramachandra1-2/+2
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Fix these breaks. The 'git branch --help' in the test may fail if git manual pages are not installed, but the point of the test is to make sure it does not create a bogus branch "--help", so run it under 'test_might_fail'. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08test: commit --amend should honor --no-editLibravatar Jonathan Nieder1-0/+40
A quick test to make sure git doesn't lose the functionality added by the recent patch "commit: honor --no-edit", plus another test to check the classical --edit use case (use with "-m"). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08t7501 (commit): modernize styleLibravatar Jonathan Nieder1-133/+127
Put the opening quote starting each test on the same line as the test_expect_* invocation. While at it: - guard commands that prepare test input for individual tests in the same test_expect_success, so their scope is clearer and errors at that stage can be caught; - use the compare_diff_patch helper function when comparing patches; - use single-quotes in preference to double-quotes and <<\EOF in preference to <<EOF, to save readers the trouble of looking for variable interpolations; - lift the setting of the $author variable used throughout the test script to the top of the test script; - include "setup" in the titles of test assertions that prepare for later ones to make it more obvious which tests can be skipped; - use test_must_fail instead of "if ...; then:; else false; fi", for clarity and to catch segfaults when they happen; - break up some pipelines into separate commands that read and write to ordinary files, and test the exit status at each stage; - chain commands with &&. Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain; - combine two initial tests that do not make as much sense alone. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-08test: remove a porcelain test that hard-codes commit namesLibravatar Jonathan Nieder1-20/+0
The rev-list output in this test depends on the details of test_tick's dummy dates and the choice of hash function. Worse, it depends on the order and nature of commits made in the earlier tests, so adding new tests or rearranging existing ones breaks it. It would be nice to check that "git commit" and commit-tree name objects consistently and that commit objects' text is as documented, but this particular test checks everything at once and hence is not a robust test for that. Remove it. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>