Re: set-upstream for existing branch...?

Jay Soffian [off-list ref] writes:

On Thu, Feb 17, 2011 at 12:19 AM, Miles Bader [off-list ref] wrote:

quoted

Is there a convenient, intuitive, way to set (or change) @{upstream} for
the current branch, without doing anything else...?

$ git branch <current_branch> --set-upstream <new_upstream>

But note that this is deceptive: what's important is the relative
positions of <current_branch> and <new_upstream> on the command-line,
and they must be in that order. It doesn't (currently) matter where
you place the --set-upstream.

I've got it on my todo list to make --set-upstream take <new_upstream>
as its argument so that you can just say:

$ git branch --set-upstream <new_upstream>

Thanks, the latter sounds nice, but for now the former is good for an alias...

-miles

-- 
Dictionary, n.  A malevolent literary device for cramping the growth of
a language and making it hard and inelastic. This dictionary, however,
is a most useful work.

Hmm, on a related note, is there an obvious way to _show_ the current
branch's upstream...?

[I mean, which just prints out "origin/master" or whatever...]

Thanks,

-miles

-- 
Cat is power.  Cat is peace.

On Thu, Feb 17, 2011 at 2:24 AM, Miles Bader [off-list ref] wrote:

Hmm, on a related note, is there an obvious way to _show_ the current
branch's upstream...?

[I mean, which just prints out "origin/master" or whatever...]

git rev-parse --abbrev-ref @{u}

j.

Miles Bader venit, vidit, dixit 17.02.2011 08:24:

Hmm, on a related note, is there an obvious way to _show_ the current
branch's upstream...?

[I mean, which just prints out "origin/master" or whatever...]

Thanks,

-miles

git for-each-ref --format="%(upstream)" $(git symbolic-ref HEAD)

I can't come up with a better way of expanding @{u} without resolving
the resulting refname to a SHA1. You could do

git name-rev @{u}

or similar with "describe", but that's really backwards - it first
expands @{u} to a refname, then to a SHA1, and then tries to describe
that SHA1 by a refname...

BTW: Please don't change "--set-upstream" light-heartedly and isolated
from other stuff. We need more consistency wrt. subcommands vs. options
vs. options taking parameters. So an incompatible change should be part
of a bigger picture. This requires some research about our current
usage, pitfalls, and the best way forward (breaking as little as
possible and achieving as much as possible).

Michael

On Thu, Feb 17, 2011 at 9:23 AM, Michael J Gruber
[off-list ref] wrote:

Miles Bader venit, vidit, dixit 17.02.2011 08:24:

quoted

Hmm, on a related note, is there an obvious way to _show_ the current
branch's upstream...?

[I mean, which just prints out "origin/master" or whatever...]

Thanks,

-miles

git for-each-ref --format="%(upstream)" $(git symbolic-ref HEAD)

I can't come up with a better way of expanding @{u} without resolving
the resulting refname to a SHA1. You could do

what about

    git branch -vv

it will show all local branches with their upstream plus behind/ahead numbers

cheers,
daniel


-- 
typed with http://neo-layout.org
myFtPhp -- visit http://myftphp.sf.net -- v. 0.4.7 released!

knittl venit, vidit, dixit 17.02.2011 10:25:

On Thu, Feb 17, 2011 at 9:23 AM, Michael J Gruber
[off-list ref] wrote:

quoted

Miles Bader venit, vidit, dixit 17.02.2011 08:24:

quoted

Hmm, on a related note, is there an obvious way to _show_ the current
branch's upstream...?

[I mean, which just prints out "origin/master" or whatever...]

Thanks,

-miles

git for-each-ref --format="%(upstream)" $(git symbolic-ref HEAD)

I can't come up with a better way of expanding @{u} without resolving
the resulting refname to a SHA1. You could do

what about

    git branch -vv

it will show all local branches with their upstream plus behind/ahead numbers

That's a very nice and useful output, but my impression was that Miles
was more interested in one branch (the current one), and I think Jay
gave the most direct solution. While it does go through the
resolve-describe-circle (compared to for-each-ref) it should still be
efficient.

Michael