[PATCH] branch: add -u as a shortcut for --set-upstream

[PATCH] branch: add -u as a shortcut for --set-upstream

[Carlos Martín Nieto]

Add this shortcut just like git-push has it.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---

I've seen threads commenting how it's odd that this doesn't exist[0],
but nobody seems to have done anything about it yet.

This may need some updates to the shell completions, but I've no idea
how those work and I'd rather not change things randomly.

[0] see e.g. http://thread.gmane.org/gmane.comp.version-control.git/165794/focus=165856

 Documentation/git-branch.txt | 1 +
 builtin/branch.c             | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 47235be..447325f 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -167,6 +167,7 @@ start-point is either a local or remote-tracking branch.
 	Do not set up "upstream" configuration, even if the
 	branch.autosetupmerge configuration variable is true.
 
+-u::
 --set-upstream::
 	If specified branch does not exist yet or if `--force` has been
 	given, acts exactly like `--track`. Otherwise sets up configuration
diff --git a/builtin/branch.c b/builtin/branch.c
index 0e060f2..9f2bb6f 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -724,7 +724,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 		OPT__QUIET(&quiet, "suppress informational messages"),
 		OPT_SET_INT('t', "track",  &track, "set up tracking mode (see git-pull(1))",
 			BRANCH_TRACK_EXPLICIT),
-		OPT_SET_INT( 0, "set-upstream",  &track, "change upstream info",
+		OPT_SET_INT('u', "set-upstream",  &track, "change upstream info",
 			BRANCH_TRACK_OVERRIDE),
 		OPT__COLOR(&branch_use_color, "use colored output"),
 		OPT_SET_INT('r', "remotes",     &kinds, "act on remote-tracking branches",
-- 
1.7.11.1.104.ge7b44f1

Re: [PATCH] branch: add -u as a shortcut for --set-upstream

[Jonathan Nieder]

Hi Carlos,

Carlos Martín Nieto wrote:

> Add this shortcut just like git-push has it.
[...]
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -724,7 +724,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
>  		OPT__QUIET(&quiet, "suppress informational messages"),
>  		OPT_SET_INT('t', "track",  &track, "set up tracking mode (see git-pull(1))",
>  			BRANCH_TRACK_EXPLICIT),
> -		OPT_SET_INT( 0, "set-upstream",  &track, "change upstream info",
> +		OPT_SET_INT('u', "set-upstream",  &track, "change upstream info",
>  			BRANCH_TRACK_OVERRIDE),

I think this is a bad idea.  The --set-upstream option is confusing:

	$ git branch --set-upstream=foo
	error: option 'set-upstream' takes no value
	$ ???

-u to set the corresponding upstream branch at the same time as
creating a branch, analagous to "git push -u" might seem intuitive:

	# create foo branch, setting its upstream at the same time
	git branch -u foo origin/foo

But that is what --track does and is not what --set-upstream is for.

Unlike --track, I don't think --set-upstream is a common enough
operation to deserve a one-letter synonym.

Instead, I'd suggest the following changes:

 1) Add support for

	# change upstream info
	git branch --set-upstream=origin/foo foo

    for existing branches only.

 2) Introduce an --unset-upstream option which removes the
    "corresponding upstream branch" configuration for an existing
    branch.

 3) Warn on

	# acts just like --track
	git branch --set-upstream foo origin/foo

    for branches that do not exist yet.  Plan to make this a hard
    error in the future.

 4) Warn on

	# sets upstream for "foo" to the current branch
	git branch --set-upstream foo

    and plan to make it a hard error in the future.

 5) Warn on

	git branch --set-upstream origin/foo foo

  which is almost certainly a typo for

	git branch --set-upstream=origin/foo foo

 6) Perhaps, make -u a synonym for -t for consistency with "git push".

What do you think?
Jonathan

Re: [PATCH] branch: add -u as a shortcut for --set-upstream

[Carlos Martín Nieto]

On Fri, 2012-07-06 at 10:32 -0500, Jonathan Nieder wrote:
> Hi Carlos,
> 
> Carlos Martín Nieto wrote:
> 
> > Add this shortcut just like git-push has it.
> [...]
> > --- a/builtin/branch.c
> > +++ b/builtin/branch.c
> > @@ -724,7 +724,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> >  		OPT__QUIET(&quiet, "suppress informational messages"),
> >  		OPT_SET_INT('t', "track",  &track, "set up tracking mode (see git-pull(1))",
> >  			BRANCH_TRACK_EXPLICIT),
> > -		OPT_SET_INT( 0, "set-upstream",  &track, "change upstream info",
> > +		OPT_SET_INT('u', "set-upstream",  &track, "change upstream info",
> >  			BRANCH_TRACK_OVERRIDE),
> 
> I think this is a bad idea.  The --set-upstream option is confusing:
> 
> 	$ git branch --set-upstream=foo
> 	error: option 'set-upstream' takes no value
> 	$ ???

It is confusing, see the other thread (about making --set-upstream
behave more sanely) for the second part of this. I wanted to add a hack
so

    git branch --set-upstream foo

would set the current branch to track foo.

> 
> -u to set the corresponding upstream branch at the same time as
> creating a branch, analagous to "git push -u" might seem intuitive:
> 
> 	# create foo branch, setting its upstream at the same time
> 	git branch -u foo origin/foo
> 
> But that is what --track does and is not what --set-upstream is for.

Right, it's for altering the configuration after the branch has already
been created. I wasn't thinking about creating the branch. That usage of
--set-upstream seems unintuitive to me, but changing the upstream for a
branch that already exists is quite intuitive and what push -u does.

> 
> Unlike --track, I don't think --set-upstream is a common enough
> operation to deserve a one-letter synonym.

I find myself using it surprisingly often, though it's certainly still
not in the top-10.

> 
> Instead, I'd suggest the following changes:
> 
>  1) Add support for
> 
> 	# change upstream info
> 	git branch --set-upstream=origin/foo foo
> 
>     for existing branches only.

I submitted the patch I mentioned above which changes --set-upstream to
something closer to what the user probably expects, which behaves mostly
like this, except that you'd have to omit the '=' as it still expected
the branch as an argument to the command. Not the cleanest wrt how
options should take arguments, but it got the job done without much code
churn.

However, Junio doesn't like that it changes existing behaviour which is
even consistent (as long as you know that --set-upstream is a flag,
rather than an option with an argument) and some people might depend on
it behaving like it does with a single argument. He'd accept a
--set-upstream-to that behaves just like you describe. This could do
with having a short alias, as the name is quite long-winded. Another
reason for adding -u is that it would add confusion if --set-upstream
has the short alias -u in push, but it means something else in branch,
even though they have the same option (though it would be
--set-upstream-to here, but we'll end up deprecating --set-upstream, so
it works out in the long run).

> 
>  2) Introduce an --unset-upstream option which removes the
>     "corresponding upstream branch" configuration for an existing
>     branch.

This is a good idea. I'll add it to the patch series.

> 
>  3) Warn on
> 
> 	# acts just like --track
> 	git branch --set-upstream foo origin/foo
> 
>     for branches that do not exist yet.  Plan to make this a hard
>     error in the future.
> 
>  4) Warn on
> 
> 	# sets upstream for "foo" to the current branch
> 	git branch --set-upstream foo
> 
>     and plan to make it a hard error in the future.
> 
>  5) Warn on
> 
> 	git branch --set-upstream origin/foo foo
> 
>   which is almost certainly a typo for
> 
> 	git branch --set-upstream=origin/foo foo

This is roughly what Junio suggested. His proposal was to also show how
to undo the --set-upstream if it was invoked the wrong way.

> 
>  6) Perhaps, make -u a synonym for -t for consistency with "git push".

I don't really see -u and -t being consistent with push -u. The push
might create a branch, but that would be in another repository. I look
at it as modifying the upstream information for an existing branch in
the local repository, and -t does not do that, --set-upstream(-to) does
that. It can also create a new local branch, but that's another bug in
the interface.

   cmn