If 'git-branch -m' is supplied one argument, it changes the name of the
current branch to the name of the argument.
If two arguments are supplied, then the first argument is interpreted
as the branch whose name is to be changed, and the second argument is
the name to change it to.
The first non-option argument is interpreted differently depending on
whether one argument or two arguments have been supplied.
git-branch -m [<oldbranch>] <newbranch>
Has anyone considered whether this is inconsistent with how other
commands operate?
For example, these commands always interpret the first argument
consistently. If a second argument is supplied, it modifies the
base or the reference from which to run the command.
git-rebase <upstream> [<branch>]
git-cherry <upstream> [<head>] [<limit.]
git-tag <name> [<head>]
git-update-ref <ref> <newvalue> [<oldvalue>]
or even
git-branch <branchname> [<start-point>]
It's hard to describe, but I have learned to think about the ordering
of arguments (especially for rebase and cherry), by thinking about
how the single argument case would operate. For rebase, if only one
argument is supplied, you know that the thing you are rebasing is
the current branch, that's the only way it makes sense.
If I am _not_ on the branch I want to rebase, it may be tempting to
think that rebase works like:
rebase <this> <on_to_this>
So if I am not on the branch, I think about how arguments would be
supplied if I _were_ on the branch I wanted to rebase. Then it is
clear how to specify the branch I want to rebase, namely that <this>
should be the second argument.
For 'git-branch -m', this relationship is broken. So I can't think
"How would this operate if I were on the branch whose name I'd like
to change", and then append the name, since when two arguments are
supplied the new branch name is the _second_ argument.
I guess maybe
git-branch -m <oldname> <newname>
is supposed to work like
mv <oldname> <newname>
but then the same could be said about the others too.
rebase <this> <on_top_of_this>
cherry <whats_in_here> <but_not_in_here>
...
I'm not suggesting we change the 'branch -m' behavior, just pointing
out that it seems inconsistent and broke my git intuition. Maybe
someone can point out a thinko on my part.
-brandon
From: Johannes Sixt <hidden> Date: 2016-06-15 22:44:13
Brandon Casey schrieb:
The first non-option argument is interpreted differently depending on
whether one argument or two arguments have been supplied.
git-branch -m [<oldbranch>] <newbranch>
Has anyone considered whether this is inconsistent with how other
commands operate?
Funny, I fell into this trap just yesterday and accidentally renamed
my master branch to something else. IMO git-branch -m should take two
arguments. Full stop.
Something like this.
-- >8 --
From: Johannes Sixt <redacted>
Subject: [PATCH] git-branch: Deprecate -m with only one argument.
"git branch -m" can be invoked with only one argument, in which case
it renames the current branch to the new name. This is inconsistent since
the first argument is either a source or destination depending on whether
a second argument follows. Furthermore, it is surprising that a rename
command that is given only one argument succeeds at all.
Let's aim for removing this feature.
Signed-off-by: Johannes Sixt <redacted>
---
Documentation/git-branch.txt | 4 ++--
builtin-branch.c | 9 ++++++---
2 files changed, 8 insertions(+), 5 deletions(-)
@@ -136,7 +136,7 @@ OPTIONS <newbranch>:: The new name for an existing branch. The same restrictions as for- <branchname> applies.+ <branchname> apply. Examples
@@ -609,9 +609,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)returndelete_branches(argc,argv,delete>1,kinds);elseif(argc==0)print_ref_list(kinds,detached,verbose,abbrev,with_commit);-elseif(rename&&(argc==1))+elseif(rename&&(argc==1)){+fprintf(stderr,"'git branch -m' with only one parameter is deprecated.\n"+"Will continue, assuming that you meant\n"+" git branch -m %s %s\n",head,argv[0]);rename_branch(head,argv[0],rename>1);-elseif(rename&&(argc==2))+}elseif(rename&&(argc==2))rename_branch(argv[0],argv[1],rename>1);elseif(argc<=2)create_branch(argv[0],(argc==2)?argv[1]:head,
The first non-option argument is interpreted differently depending on
whether one argument or two arguments have been supplied.
git-branch -m [<oldbranch>] <newbranch>
Has anyone considered whether this is inconsistent with how other
commands operate?
Funny, I fell into this trap just yesterday and accidentally renamed
my master branch to something else. IMO git-branch -m should take two
arguments. Full stop.
Actually, I think the single argument case is unambiguous and I would
rather not give it up.
It's the two argument case that both expects its arguments in a different
order than other commands _and_ is dangerous in the case of -M.
I was thinking that -M should print a message describing what it is going
to do, and prompt the user for confirmation. A new option could be added
to suppress this behavior like -q. Or we could reuse -f, but see below.
While I'm looking at git-branch, I think the capital forms are unnecessary.
We have a -f (force) option, so I think it makes more sense to deprecate
the captital forms(not remove them), and interpret -f along with -m or -d to
provide the same functionality. Again, with the behavior described above
for confirmation with something like -q.
Oh, and I wouldn't mind switching the arguments around after we have the
confirmation implemented. :)
-brandon
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:13
Hi,
On Thu, 14 Feb 2008, Brandon Casey wrote:
Johannes Sixt wrote:
quoted
Brandon Casey schrieb:
quoted
The first non-option argument is interpreted differently depending on
whether one argument or two arguments have been supplied.
git-branch -m [<oldbranch>] <newbranch>
Has anyone considered whether this is inconsistent with how other
commands operate?
Funny, I fell into this trap just yesterday and accidentally renamed
my master branch to something else. IMO git-branch -m should take two
arguments. Full stop.
Actually, I think the single argument case is unambiguous and I would
rather not give it up.
It's the two argument case that both expects its arguments in a
different order than other commands _and_ is dangerous in the case of
-M.
The order was specifically requested, as "mv" also has that order.
And "-M" is always dangerous. Don't use it, if you don't know what you're
doing.
AFAIR -M is even _marked_ as a dangerous command.
Ciao,
Dscho
The first non-option argument is interpreted differently depending on
whether one argument or two arguments have been supplied.
git-branch -m [<oldbranch>] <newbranch>
Has anyone considered whether this is inconsistent with how other
commands operate?
Funny, I fell into this trap just yesterday and accidentally renamed
my master branch to something else. IMO git-branch -m should take two
arguments. Full stop.
Actually, I think the single argument case is unambiguous and I would
rather not give it up.
It's the two argument case that both expects its arguments in a
different order than other commands _and_ is dangerous in the case of
-M.
The order was specifically requested, as "mv" also has that order.
Did you even read the original message? You point this out like it hasn't
already been mentioned.
The _point_ is that the order is _different_ than the order that other _git_
commands use. I give more weight to the relationship with other git commands
than to the relationship between the '-M' option and the 'mv' command. A
subcommand named 'mv' could have been used if a strong relationship was
supposed to be implied, something like 'git-branch mv <src> <dst>'. I'm not
sure the single argument case would have retained its intuitiveness in this case.
And "-M" is always dangerous.
Don't use it, if you don't know what you're
doing.