threads / patch / 33202

patchrev-parse: Clarify documentation of @{upstream} syntax

Subject: [PATCH] rev-parse: Clarify documentation of @{upstream} syntax

## tl;dr

3 messages between Mar 16, 2013 and Mar 17, 2013. Diffs are folded; open one to read it.

replies: 2people: 2as markdown or json

Kacper Kornet· Mar 16, 2013, 18:51 UTC · lore

git-rev-parse interprets string in string@{upstream} as a name of a branch not a ref. For example refs/heads/master@{upstream} looks for an upstream branch that is merged by git-pull to ref refs/heads/refs/heads/master not to refs/heads/master. However the documentation could misled a user to believe that the string is interpreted as ref.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
---
 Documentation/revisions.txt | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Show changes to Documentation/revisions.txt +4 −4

diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 678d175..314e25d 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -88,10 +88,10 @@ some output processing may assume ref names in UTF-8.
   The construct '@\{-<n>\}' means the <n>th branch checked out
   before the current one.
 
-'<refname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
-  The suffix '@\{upstream\}' to a ref (short form '<refname>@\{u\}') refers to
-  the branch the ref is set to build on top of.  A missing ref defaults
-  to the current branch.
+'<branchname>@\{upstream\}', e.g. 'master@\{upstream\}', '@\{u\}'::
+  The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')
+  refers to the branch that the branch specified by branchname is set to build on
+  top of.  A missing branchname defaults to the current one.
 
 '<rev>{caret}', e.g. 'HEAD{caret}, v1.5.1{caret}0'::
   A suffix '{caret}' to a revision parameter means the first parent of

-- 
1.8.2

Eric Sunshine· Mar 17, 2013, 04:31 UTC · re: Kacper Kornet · lore

Re: [PATCH] rev-parse: Clarify documentation of @{upstream} syntax

On Sat, Mar 16, 2013 at 2:51 PM, Kacper Kornet <draenog@pld-linux.org> wrote:

Show 5 quoted lines

> git-rev-parse interprets string in string@{upstream} as a name of
> a branch not a ref. For example refs/heads/master@{upstream} looks
> for an upstream branch that is merged by git-pull to ref
> refs/heads/refs/heads/master not to refs/heads/master. However the
> documentation could misled a user to believe that the string is

s/misled/mislead/

> interpreted as ref.

Kacper Kornet· Mar 17, 2013, 22:17 UTC · re: Kacper Kornet · lore

[PATCH] 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>
---

Maybe I'm too cautious adding this test. But just in case here it is.

 t/t1507-rev-parse-upstream.sh | 4 ++++
 1 file changed, 4 insertions(+)

Show changes to t/t1507-rev-parse-upstream.sh +4 −0

diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index d6e5761..b27a720 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -54,6 +54,10 @@ test_expect_success 'my-side@{upstream} resolves to correct full name' '
 	test refs/remotes/origin/side = "$(full_name my-side@{u})"
 '
 
+test_expect_success 'refs/heads/my-side@{upstream} does not resolve to my-side{upstream}' '
+	test_must_fail full_name refs/heads/my-side@{upstream}
+'
+
 test_expect_success 'my-side@{u} resolves to correct commit' '
 	git checkout side &&
 	test_commit 5 &&

-- 
1.8.2