path: root/t/
AgeCommit message (Collapse)Author
2020-06-24fmt-merge-msg: stop treating `master` speciallyJohannes Schindelin
In the context of many projects renaming their primary branch names away from `master`, Git wants to stop treating the `master` branch specially. Let's start with `git fmt-merge-msg`. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-12-20t1507: inline full_name()Denton Liu
Before, we were running `test_must_fail full_name`. However, `test_must_fail` should only be used on git commands. Inline full_name() so that we can use test_must_fail on the git command directly. When full_name() was introduced in 28fb84382b (Introduce <branch>@{upstream} notation, 2009-09-10), the `git -C` option wasn't available yet (since it was introduced in 44e1e4d67d (git: run in a directory given with -C option, 2013-09-09)). As a result, the helper function removed the need to manually cd each time. However, since `git -C` is available now, we can just use that instead and inline full_name(). An alternate approach was taken where we taught full_name() to accept an optional `!` arg to trigger test_must_fail behavior. However, this added more unnecessary complexity than inlining so we inline instead. Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-12-20t1507: run commands within test_expect_successDenton Liu
The expected test style is to have all commands tested within a test_expect_success block. Move the generation of the 'expect' text into their corresponding blocks. While we're at it, insert a second `commit=$(git rev-parse HEAD)` into the next test case so that it's clear where $commit is coming from. The biggest advantage of doing this is that we now check the return code of `git rev-parse HEAD` so we can catch it in case it fails. This patch is best viewed with `--color-moved --ignore-all-space`. Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-12-20t1507: stop losing return codes of git commandsDenton Liu
The return code of git commands are lost when a command is in a non-assignment command substitution in favour of the surrounding command's. Rewrite instances of this so that git commands run on their own. In commit_subject(), use a `tformat` instead of `format` since, previously, we were testing the output of a command substitution which didn't care if there was a trailing newline since it was automatically stripped. Since we use test_cmp() now, the trailing newline matters so use `tformat` to always output it. Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-09-06t: use common $SQ variableDenton Liu
In many test scripts, there are bespoke definitions of the single quote that are some variation of this: SQ="'" Define a common $SQ variable in and replace all usages of these bespoke variables with the common one. This change was done by running `git grep =\"\'\" t/` and `git grep =\\\\\'` and manually changing the resulting definitions and corresponding usages. Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2018-08-20Merge branch 'ab/test-must-be-empty-for-master'Junio C Hamano
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-07-30tests: make use of the test_must_be_empty functionÆvar Arnfjörð Bjarmason
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2018-07-03t: use test_might_fail() instead of manipulating exit code manuallyEric Sunshine
These tests manually coerce the exit code of invoked commands to "success" when they don't care if the command succeeds or fails since failure of those commands should not cause the test to fail overall. In doing so, they intentionally break the &&-chain. Modernize by replacing manual exit code management with test_might_fail() and a normal &&-chain. Signed-off-by: Eric Sunshine <> Signed-off-by: Junio C Hamano <>
2018-03-26t1507: abstract away SHA-1-specific constantsbrian m. carlson
Adjust the test so that it uses a variable consisting of the current HEAD instead of a hard-coded hash. Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2018-02-27t1507-rev-parse-upstream: don't check the stderr of a shell functionSZEDER Gábor
Three tests in '' fail when the test script is run with '-x' tracing (and using a shell other than a Bash version supporting BASH_XTRACEFD). The reason for those failures is that the tests check the stderr of the function 'error_message', which includes the trace of commands executed in that function as well, throwing off the comparison with the expected output. Save stderr of 'git rev-parse' only instead of the whole function, so it remains free from tracing output. After this change t1507 passes with '-x', even when running with /bin/sh. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2017-03-27rev-parse: match @{upstream}, @{u} and @{push} case-insensitivelyÆvar Arnfjörð Bjarmason
Change the revision parsing logic to match @{upstream}, @{u} & @{push} case-insensitively. Before this change supplying anything except the lower-case forms emits an "unknown revision or path not in the working tree" error. This change makes upper-case & mixed-case versions equivalent to the lower-case versions. The use-case for this is being able to hold the shift key down while typing @{u} on certain keyboard layouts, which makes the sequence easier to type, and reduces cases where git throws an error at the user where it could do what he means instead. These suffixes now join various other suffixes & special syntax documented in gitrevisions(7) that matches case-insensitively. A table showing the status of the various forms documented there before & after this patch is shown below. The key for the table is: - CI = Case Insensitive - CIP = Case Insensitive Possible (without ambiguities) - AG = Accepts Garbage (.e.g. @{./.4.minutes./.}) Before this change: |----------------+-----+------+-----| | What? | CI? | CIP? | AG? | |----------------+-----+------+-----| | @{<date>} | Y | Y | Y | | @{upstream} | N | Y | N | | @{push} | N | Y | N | |----------------+-----+------+-----| After it: |----------------+-----+------+-----| | What? | CI? | CIP? | AG? | |----------------+-----+------+-----| | @{<date>} | Y | Y | Y | | @{upstream} | Y | Y | N | | @{push} | Y | Y | N | |----------------+-----+------+-----| The ^{<type>} suffix is not made case-insensitive, because other places that take <type> like "cat-file -t <type>" do want them case sensitively (after all we never declared that type names are case insensitive). Allowing case-insensitive typename only with this syntax will make the resulting Git as a whole inconsistent. This change was independently authored to scratch a longtime itch, but when I was about to submit it I discovered that a similar patch had been submitted unsuccessfully before by Conrad Irwin in August 2011 as "rev-parse: Allow @{U} as a synonym for @{u}" (<>). The tests for this patch are more exhaustive than in the 2011 submission. The starting point for them was to first change the code to only support upper-case versions of the existing words, seeing what broke, and amending the breaking tests to check upper case & mixed case as appropriate, and where not redundant to other similar tests. The implementation itself is equivalent. Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2015-05-21remote.c: report specific errors from branch_get_upstreamJeff King
When the previous commit introduced the branch_get_upstream helper, there was one call-site that could not be converted: the one in sha1_name.c, which gives detailed error messages for each possible failure. Let's teach the helper to optionally report these specific errors. This lets us convert another callsite, and means we can use the helper in other locations that want to give the same error messages. The logic and error messages come straight from sha1_name.c, with the exception that we start each error with a lowercase letter, as is our usual style (note that a few tests need updated as a result). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-05-15git-show: fix 'git show -s' to not add extra terminator after merge commitMax Kirillov
When git show -s is called for merge commit it prints extra newline after any merge commit. This differs from output for commits with one parent. Fix it by more thorough checking that diff output is disabled. The code in question exists since commit 3969cf7db1. The additional newline is really needed for cases when patch is requested, test contains cases which can demonstrate behavior when the condition is restricted further. Tests: Added merge commit to 'set up a bit of history' case in to cover the fix. Existing tests are updated to demonstrate the new behaviour. Earlier, the tests that used "git show -s --pretty=format:%s", even though "--pretty=format:%s" calls for item separator semantics and does not ask for the terminating newline after the last item, expected the output to end with such a newline. They were relying on the buggy behaviour. Use of "--format=%s", which is equivalent to "--pretty=tformat:%s" that asks for a terminating newline after each item, is a more realistic way to use the command. In the test 'merge log messages' the expected data is changed, because it was explicitly listing the extra newline. Also the msg.nologff and msg.nolognoff expected files are replaced by one msg.nolog, because they were diffing because of the bug, and now there should be no difference. Signed-off-by: Max Kirillov <> Signed-off-by: Junio C Hamano <>
2014-01-15interpret_branch_name: find all possible @-marksJeff King
When we parse a string like "foo@{upstream}", we look for the first "@"-sign, and check to see if it is an upstream mark. However, since branch names can contain an @, we may also see "@foo@{upstream}". In this case, we check only the first @, and ignore the second. As a result, we do not find the upstream. We can solve this by iterating through all @-marks in the string, and seeing if any is a legitimate upstream or empty-at mark. Another strategy would be to parse from the right-hand side of the string. However, that does not work for the "empty_at" case, which allows "@@{upstream}". We need to find the left-most one in this case (and we then recurse as "HEAD@{upstream}"). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-01-15interpret_branch_name: avoid @{upstream} past colonJeff King
get_sha1() cannot currently parse a valid object name like "HEAD:@{upstream}" (assuming that such an oddly named file exists in the HEAD commit). It takes two passes to parse the string: 1. It first considers the whole thing as a ref, which results in looking for the upstream of "HEAD:". 2. It finds the colon, parses "HEAD" as a tree-ish, and then finds the path "@{upstream}" in the tree. For a path that looks like a normal reflog (e.g., "HEAD:@{yesterday}"), the first pass is a no-op. We try to dwim_ref("HEAD:"), that returns zero refs, and we proceed with colon-parsing. For "HEAD:@{upstream}", though, the first pass ends up in interpret_upstream_mark, which tries to find the branch "HEAD:". When it sees that the branch does not exist, it actually dies rather than returning an error to the caller. As a result, we never make it to the second pass. One obvious way of fixing this would be to teach interpret_upstream_mark to simply report "no, this isn't an upstream" in such a case. However, that would make the error-reporting for legitimate upstream cases significantly worse. Something like "bogus@{upstream}" would simply report "unknown revision: bogus@{upstream}", while the current code diagnoses a wide variety of possible misconfigurations (no such branch, branch exists but does not have upstream, etc). However, we can take advantage of the fact that a branch name cannot contain a colon. Therefore even if we find an upstream mark, any prefix with a colon must mean that the upstream mark we found is actually a pathname, and should be disregarded completely. This patch implements that logic. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-05-22sha1_name: fix error message for @{u}Ramkumar Ramachandra
Currently, when no (valid) upstream is configured for a branch, you get an error like: $ git show @{u} error: No upstream configured for branch 'upstream-error' error: No upstream configured for branch 'upstream-error' fatal: ambiguous argument '@{u}': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' The "error: " line actually appears twice, and the rest of the error message is useless. In sha1_name.c:interpret_branch_name(), there is really no point in processing further if @{u} couldn't be resolved, and we might as well die() instead of returning an error(). After making this change, you get: $ git show @{u} fatal: No upstream configured for branch 'upstream-error' Also tweak a few tests in t1507 to expect this output. This only turns error() that may be called after we know we are dealing with an @{upstream} marker into die(), without touching silent error returns "return -1" from the function. Any caller that wants to handle an error condition itself will not be hurt by this change, unless they want to see the message from error() and then exit silently without giving its own message, which needs to be fixed anyway. Signed-off-by: Ramkumar Ramachandra <> Signed-off-by: Junio C Hamano <>
2013-03-17t1507: Test that branchname@{upstream} is interpreted as branchKacper Kornet
Syntax branchname@{upstream} should interpret its argument as a name of a branch. Add the test to check that it doesn't try to interpret it as a refname if the branch in question does not exist. Signed-off-by: Kacper Kornet <> Signed-off-by: Junio C Hamano <>
2012-04-15i18n: mark @{upstream} error messages for translationZbigniew Jędrzejewski-Szmek
Signed-off-by: Zbigniew Jędrzejewski-Szmek <> Signed-off-by: Junio C Hamano <>
2012-04-15Be more specific if upstream branch is not trackedZbigniew Jędrzejewski-Szmek
If the branch configured as upstream didn't have a local tracking branch, git said "Upstream branch not found". We can be more helpful, and separate the cases when upstream is not configured, and when it is configured, but the upstream branch is not tracked in a local branch. The following configuration leads to the second scenario: [remote "origin"] url = ... fetch = refs/heads/master [branch "master"] remote = origin merge = refs/heads/master 'git pull' will work on master, but master@{upstream} is not defined. Signed-off-by: Zbigniew Jędrzejewski-Szmek <> Signed-off-by: Junio C Hamano <>
2012-04-15Provide better message for barnhc_wiht_tpyo@{u}Zbigniew Jędrzejewski-Szmek
Instead of just saying that no upstream exists for such branch, which is true but not very helpful, check that there's no refs/heads/barnhc_wiht_tpyo and tell it to the user. Signed-off-by: Zbigniew Jędrzejewski-Szmek <> Signed-off-by: Junio C Hamano <>
2012-04-15Provide branch name in error message when using @{u}Zbigniew Jędrzejewski-Szmek
When using @{u} or @{upstream} it is common to omit the branch name, implying current branch. If the upstream is not configured, the error message was "No upstream branch found for ''". When resolving '@{u}', branch_get() is called, which almost always returns a description of a branch. This allows us to use a branch name in the error message, even if the user said something like '@{u}'. The only case when branch_get() returns NULL is when HEAD points to so something which is not a branch. Of course this also means that no upstream is configured, but it is better to directly say that HEAD does not point to a branch. Signed-off-by: Zbigniew Jędrzejewski-Szmek <> Signed-off-by: Junio C Hamano <>
2012-04-15t1507: add tests to document @{upstream} behaviourZbigniew Jędrzejewski-Szmek
In preparation for future changes, add tests which show error messages with @{upstream} in various conditions: - test branch@{u} with . as remote - check error message for branch@{u} on a branch with * no upstream, * on a branch with a configured upstream which doesn't have a remote-tracking branch - check error message for branch@{u} when branch 'branch' does not exist - check error message for @{u} without the branch name Right now the messages are very similar, but various cases can and will be distinguished. Note: test_i18ncmp is not used, because currently error output is not internationalized. test_cmp will be switched to test_i18ncmp in a later patch, when error messages are internationalized. Signed-off-by: Zbigniew Jędrzejewski-Szmek <> Signed-off-by: Junio C Hamano <>
2010-11-03Change incorrect "remote branch" to "remote tracking branch" in C codeMatthieu Moy
(Just like we did for documentation already) In the process, we change "non-remote branch" to "branch outside the refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch". The new formulation actually corresponds to how the code detects this case (i.e. prefixcmp(refname, "refs/remotes")). Also, we use 'remote-tracking branch' in generated merge messages (by merge an fmt-merge-msg). Signed-off-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2010-01-26Fix log -g this@{upstream}Junio C Hamano
It showed the correct objects but walked a wrong reflog. Again, tests are from Jeff King. Signed-off-by: Junio C Hamano <>
2010-01-24Make test numbers uniqueJohannes Sixt
Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>