kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Max Kirillov	ad2f7255b3	git-show: fix 'git show -s' to not add extra terminator after merge commit 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>	11 years ago
Jeff King	9892d5d454	interpret_branch_name: find all possible @-marks 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>	11 years ago
Jeff King	3f6eb30f1d	interpret_branch_name: avoid @{upstream} past colon 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>	11 years ago
Ramkumar Ramachandra	17bf4ff3cd	sha1_name: fix error message for @{u} 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>	12 years ago
Kacper Kornet	617cf93182	t1507: Test that branchname@{upstream} is interpreted as branch 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>	12 years ago
Zbigniew Jędrzejewski-Szmek	6472028893	i18n: mark @{upstream} error messages for translation Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>	13 years ago
Zbigniew Jędrzejewski-Szmek	17c82211ec	Be more specific if upstream branch is not tracked 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>	13 years ago
Zbigniew Jędrzejewski-Szmek	bb0dab5d61	Provide better message for barnhc_wiht_tpyo@{u} 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>	13 years ago
Zbigniew Jędrzejewski-Szmek	9884e67f9d	Provide branch name in error message when using @{u} 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>	13 years ago
Zbigniew Jędrzejewski-Szmek	1b4aee94aa	t1507: add tests to document @{upstream} behaviour 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>	13 years ago
Matthieu Moy	13931236b9	Change incorrect "remote branch" to "remote tracking branch" in C code (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>	15 years ago
Junio C Hamano	105e473397	Fix log -g this@{upstream} 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>	15 years ago
Johannes Sixt	eca9388f39	Make test numbers unique Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	ae0ba8e20a	Teach @{upstream} syntax to strbuf_branchanme() This teaches @{upstream} syntax to interpret_branch_name(), instead of dwim_ref() machinery. There are places in git UI that behaves differently when you give a local branch name and when you give an extended SHA-1 expression that evaluates to the commit object name at the tip of the branch. The intent is that the special syntax such as @{-1} can stand in as if the user spelled the name of the branch in such places. The name of the branch "frotz" to switch to ("git checkout frotz"), and the name of the branch "nitfol" to fork a new branch "frotz" from ("git checkout -b frotz nitfol"), are examples of such places. These places take only the name of the branch (e.g. "frotz"), and they are supposed to act differently to an equivalent refname (e.g. "refs/heads/frotz"), so hooking the @{upstream} and @{-N} syntax to dwim_ref() is insufficient when we want to deal with cases a local branch is forked from another local branch and use "forked@{upstream}" to name the forkee branch. The "upstream" syntax "forked@{u}" is to specify the ref that "forked" is configured to merge with, and most often the forkee is a remote tracking branch, not a local branch. We cannot simply return a local branch name, but that does not necessarily mean we have to returns the full refname (e.g. refs/remotes/origin/frotz, when returning origin/frotz is enough). This update calls shorten_unambiguous_ref() to do so. Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	69add8e6d2	t1506: more test for @{upstream} syntax This adds a few more tests that exercises @{upstream} syntax by commands that operate differently when they are given branch name as opposed to a refname (i.e. where "master" and "refs/heads/master" makes a difference). Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Johannes Schindelin	28fb84382b	Introduce <branch>@{upstream} notation A new notation '<branch>@{upstream}' refers to the branch <branch> is set to build on top of. Missing <branch> (i.e. '@{upstream}') defaults to the current branch. This allows you to run, for example, for l in list of local branches do git log --oneline --left-right $l...$l@{upstream} done to inspect each of the local branches you are interested in for the divergence from its upstream. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago

13 Commits (6634f05454662b62e1f34766d3684b99fb53ad66)