summaryrefslogtreecommitdiff
path: root/t/t1507-rev-parse-upstream.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-05-15git-show: fix 'git show -s' to not add extra terminator after merge commitLibravatar Max Kirillov1-1/+1
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 t4013-diff-various.sh 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 t7007-show.sh 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 <max@max630.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15interpret_branch_name: find all possible @-marksLibravatar Jeff King1-0/+21
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15interpret_branch_name: avoid @{upstream} past colonLibravatar Jeff King1-0/+16
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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-22sha1_name: fix error message for @{u}Libravatar Ramkumar Ramachandra1-10/+5
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 <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17t1507: Test that branchname@{upstream} is interpreted as branchLibravatar Kacper Kornet1-0/+4
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 <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15i18n: mark @{upstream} error messages for translationLibravatar Zbigniew Jędrzejewski-Szmek1-5/+5
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15Be more specific if upstream branch is not trackedLibravatar Zbigniew Jędrzejewski-Szmek1-3/+3
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 <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15Provide better message for barnhc_wiht_tpyo@{u}Libravatar Zbigniew Jędrzejewski-Szmek1-1/+1
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 <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15Provide branch name in error message when using @{u}Libravatar Zbigniew Jędrzejewski-Szmek1-2/+2
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 <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-15t1507: add tests to document @{upstream} behaviourLibravatar Zbigniew Jędrzejewski-Szmek1-3/+78
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 <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Change incorrect "remote branch" to "remote tracking branch" in C codeLibravatar Matthieu Moy1-1/+1
(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 <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-26Fix log -g this@{upstream}Libravatar Junio C Hamano1-0/+29
It showed the correct objects but walked a wrong reflog. Again, tests are from Jeff King. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-24Make test numbers uniqueLibravatar Johannes Sixt1-0/+110
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>