* 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).