Teach @{upstream} syntax to strbuf_branchanme()
authorJunio C Hamano <gitster@pobox.com>
Wed, 20 Jan 2010 07:17:11 +0000 (23:17 -0800)
committerJunio C Hamano <gitster@pobox.com>
Wed, 20 Jan 2010 09:21:47 +0000 (01:21 -0800)
commitae0ba8e20a2fb57299381ba2daa7c6d1863320d0
treeffc564749098e05dc0ce4cabf265b05876a58d27
parent69add8e6d20989babdb128cf63decc10c418fcfa
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>
sha1_name.c
t/t1506-rev-parse-upstream.sh