* git-branch -m interprets first argument differently when two are supplied
@ 2008-02-13 19:48 Brandon Casey
2008-02-14 7:37 ` Johannes Sixt
0 siblings, 1 reply; 6+ messages in thread
From: Brandon Casey @ 2008-02-13 19:48 UTC (permalink / raw)
To: Git Mailing List
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-branch -m interprets first argument differently when two are supplied
2008-02-13 19:48 git-branch -m interprets first argument differently when two are supplied Brandon Casey
@ 2008-02-14 7:37 ` Johannes Sixt
2008-02-14 16:30 ` Brandon Casey
0 siblings, 1 reply; 6+ messages in thread
From: Johannes Sixt @ 2008-02-14 7:37 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List, Junio C Hamano
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 <johannes.sixt@telecom.at>
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 <johannes.sixt@telecom.at>
---
Documentation/git-branch.txt | 4 ++--
builtin-branch.c | 9 ++++++---
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 7e8874a..56bea06 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -12,7 +12,7 @@ SYNOPSIS
[-v [--abbrev=<length> | --no-abbrev]]
[--contains <commit>]
'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
-'git-branch' (-m | -M) [<oldbranch>] <newbranch>
+'git-branch' (-m | -M) <oldbranch> <newbranch>
'git-branch' (-d | -D) [-r] <branchname>...
DESCRIPTION
@@ -136,7 +136,7 @@ OPTIONS
<newbranch>::
The new name for an existing branch. The same restrictions as for
- <branchname> applies.
+ <branchname> apply.
Examples
diff --git a/builtin-branch.c b/builtin-branch.c
index e414c88..14df594 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -17,7 +17,7 @@ static const char * const builtin_branch_usage[] = {
"git-branch [options] [-r | -a]",
"git-branch [options] [-l] [-f] <branchname> [<start-point>]",
"git-branch [options] [-r] (-d | -D) <branchname>",
- "git-branch [options] (-m | -M) [<oldbranch>] <newbranch>",
+ "git-branch [options] (-m | -M) <oldbranch> <newbranch>",
NULL
};
@@ -609,9 +609,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
return delete_branches(argc, argv, delete > 1, kinds);
else if (argc == 0)
print_ref_list(kinds, detached, verbose, abbrev, with_commit);
- else if (rename && (argc == 1))
+ else if (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);
- else if (rename && (argc == 2))
+ } else if (rename && (argc == 2))
rename_branch(argv[0], argv[1], rename > 1);
else if (argc <= 2)
create_branch(argv[0], (argc == 2) ? argv[1] : head,
--
1.5.4.1.104.g84d88
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: git-branch -m interprets first argument differently when two are supplied
2008-02-14 7:37 ` Johannes Sixt
@ 2008-02-14 16:30 ` Brandon Casey
2008-02-14 16:49 ` Johannes Schindelin
0 siblings, 1 reply; 6+ messages in thread
From: Brandon Casey @ 2008-02-14 16:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Junio C Hamano
Johannes Sixt wrote:
> 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.
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-branch -m interprets first argument differently when two are supplied
2008-02-14 16:30 ` Brandon Casey
@ 2008-02-14 16:49 ` Johannes Schindelin
2008-02-14 17:17 ` Brandon Casey
0 siblings, 1 reply; 6+ messages in thread
From: Johannes Schindelin @ 2008-02-14 16:49 UTC (permalink / raw)
To: Brandon Casey; +Cc: Johannes Sixt, Git Mailing List, Junio C Hamano
Hi,
On Thu, 14 Feb 2008, Brandon Casey wrote:
> Johannes Sixt wrote:
> > 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.
>
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-branch -m interprets first argument differently when two are supplied
2008-02-14 16:49 ` Johannes Schindelin
@ 2008-02-14 17:17 ` Brandon Casey
2008-02-14 17:50 ` Johannes Schindelin
0 siblings, 1 reply; 6+ messages in thread
From: Brandon Casey @ 2008-02-14 17:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Git Mailing List, Junio C Hamano
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 14 Feb 2008, Brandon Casey wrote:
>
>> Johannes Sixt wrote:
>>> 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.
>> 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.
Gee, thanks for the advice.
-brandon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git-branch -m interprets first argument differently when two are supplied
2008-02-14 17:17 ` Brandon Casey
@ 2008-02-14 17:50 ` Johannes Schindelin
0 siblings, 0 replies; 6+ messages in thread
From: Johannes Schindelin @ 2008-02-14 17:50 UTC (permalink / raw)
To: Brandon Casey; +Cc: Johannes Sixt, Git Mailing List, Junio C Hamano
Hi,
On Thu, 14 Feb 2008, Brandon Casey wrote:
> Johannes Schindelin wrote:
> >
> > On Thu, 14 Feb 2008, Brandon Casey wrote:
> >
> >> 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.
Yes, I had read it, but I had the impression that the rationale for the
current behaviour made a heck of a lot of sense.
> >Don't use it, if you don't know what you're doing.
>
> Gee, thanks for the advice.
You're welcome, as always.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-02-14 17:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-13 19:48 git-branch -m interprets first argument differently when two are supplied Brandon Casey
2008-02-14 7:37 ` Johannes Sixt
2008-02-14 16:30 ` Brandon Casey
2008-02-14 16:49 ` Johannes Schindelin
2008-02-14 17:17 ` Brandon Casey
2008-02-14 17:50 ` Johannes Schindelin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).