{"thread":{"id":"12078","subject":"git-branch -m interprets first argument differently when two are supplied","startedAt":"2008-02-13T19:48:10Z","lastAt":"2008-02-14T17:50:55Z","messageCount":6,"participants":["Brandon Casey","Johannes Sixt","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68672","messageId":"47B3497A.9050703@nrlssc.navy.mil","threadId":"12078","inReplyTo":null,"subject":"git-branch -m interprets first argument differently when two are supplied","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-02-13T19:48:10Z","receivedAt":"2008-02-13T19:48:10Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"\nIf 'git-branch -m' is supplied one argument, it changes the name of the\ncurrent branch to the name of the argument.\n\nIf two arguments are supplied, then the first argument is interpreted\nas the branch whose name is to be changed, and the second argument is\nthe name to change it to.\n\nThe first non-option argument is interpreted differently depending on\nwhether one argument or two arguments have been supplied.\n\n\tgit-branch -m [<oldbranch>] <newbranch>\n\nHas anyone considered whether this is inconsistent with how other\ncommands operate?\n\nFor example, these commands always interpret the first argument\nconsistently. If a second argument is supplied, it modifies the\nbase or the reference from which to run the command.\n\n\tgit-rebase <upstream> [<branch>]\n\tgit-cherry <upstream> [<head>] [<limit.]\n\tgit-tag <name> [<head>]\n\tgit-update-ref <ref> <newvalue> [<oldvalue>]\n\nor even\n\n\tgit-branch <branchname> [<start-point>]\n\nIt's hard to describe, but I have learned to think about the ordering\nof arguments (especially for rebase and cherry), by thinking about\nhow the single argument case would operate. For rebase, if only one\nargument is supplied, you know that the thing you are rebasing is\nthe current branch, that's the only way it makes sense.\n\nIf I am _not_ on the branch I want to rebase, it may be tempting to\nthink that rebase works like:\n\n\trebase <this> <on_to_this>\n\nSo if I am not on the branch, I think about how arguments would be\nsupplied if I _were_ on the branch I wanted to rebase. Then it is\nclear how to specify the branch I want to rebase, namely that <this>\nshould be the second argument.\n\nFor 'git-branch -m', this relationship is broken. So I can't think\n\"How would this operate if I were on the branch whose name I'd like\nto change\", and then append the name, since when two arguments are\nsupplied the new branch name is the _second_ argument.\n\nI guess maybe\n\n\tgit-branch -m <oldname> <newname>\n\nis supposed to work like\n\n\tmv <oldname> <newname>\n\nbut then the same could be said about the others too.\n\n\trebase <this> <on_top_of_this>\n\tcherry <whats_in_here> <but_not_in_here>\n\t...\n\nI'm not suggesting we change the 'branch -m' behavior, just pointing\nout that it seems inconsistent and broke my git intuition. Maybe\nsomeone can point out a thinko on my part.\n\n-brandon\n"},{"id":"68720","messageId":"47B3EFC4.1020808@viscovery.net","threadId":"12078","inReplyTo":"47B3497A.9050703@nrlssc.navy.mil","subject":"Re: git-branch -m interprets first argument differently when two are supplied","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-02-14T07:37:40Z","receivedAt":"2008-02-14T07:37:40Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Brandon Casey schrieb:\n> The first non-option argument is interpreted differently depending on\n> whether one argument or two arguments have been supplied.\n> \n> \tgit-branch -m [<oldbranch>] <newbranch>\n> \n> Has anyone considered whether this is inconsistent with how other\n> commands operate?\n\nFunny, I fell into this trap just yesterday and accidentally renamed\nmy master branch to something else. IMO git-branch -m should take two\narguments. Full stop.\n\nSomething like this.\n\n-- >8 --\nFrom: Johannes Sixt <johannes.sixt@telecom.at>\nSubject: [PATCH] git-branch: Deprecate -m with only one argument.\n\n\"git branch -m\" can be invoked with only one argument, in which case\nit renames the current branch to the new name. This is inconsistent since\nthe first argument is either a source or destination depending on whether\na second argument follows. Furthermore, it is surprising that a rename\ncommand that is given only one argument succeeds at all.\n\nLet's aim for removing this feature.\n\nSigned-off-by: Johannes Sixt <johannes.sixt@telecom.at>\n---\n Documentation/git-branch.txt |    4 ++--\n builtin-branch.c             |    9 ++++++---\n 2 files changed, 8 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt\nindex 7e8874a..56bea06 100644\n--- a/Documentation/git-branch.txt\n+++ b/Documentation/git-branch.txt\n@@ -12,7 +12,7 @@ SYNOPSIS\n \t   [-v [--abbrev=<length> | --no-abbrev]]\n \t   [--contains <commit>]\n 'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]\n-'git-branch' (-m | -M) [<oldbranch>] <newbranch>\n+'git-branch' (-m | -M) <oldbranch> <newbranch>\n 'git-branch' (-d | -D) [-r] <branchname>...\n\n DESCRIPTION\n@@ -136,7 +136,7 @@ OPTIONS\n\n <newbranch>::\n \tThe new name for an existing branch. The same restrictions as for\n-\t<branchname> applies.\n+\t<branchname> apply.\n\n\n Examples\ndiff --git a/builtin-branch.c b/builtin-branch.c\nindex e414c88..14df594 100644\n--- a/builtin-branch.c\n+++ b/builtin-branch.c\n@@ -17,7 +17,7 @@ static const char * const builtin_branch_usage[] = {\n \t\"git-branch [options] [-r | -a]\",\n \t\"git-branch [options] [-l] [-f] <branchname> [<start-point>]\",\n \t\"git-branch [options] [-r] (-d | -D) <branchname>\",\n-\t\"git-branch [options] (-m | -M) [<oldbranch>] <newbranch>\",\n+\t\"git-branch [options] (-m | -M) <oldbranch> <newbranch>\",\n \tNULL\n };\n\n@@ -609,9 +609,12 @@ int cmd_branch(int argc, const char **argv, const char *prefix)\n \t\treturn delete_branches(argc, argv, delete > 1, kinds);\n \telse if (argc == 0)\n \t\tprint_ref_list(kinds, detached, verbose, abbrev, with_commit);\n-\telse if (rename && (argc == 1))\n+\telse if (rename && (argc == 1)) {\n+\t\tfprintf(stderr, \"'git branch -m' with only one parameter is deprecated.\\n\"\n+\t\t\t\"Will continue, assuming that you meant\\n\"\n+\t\t\t\"    git branch -m %s %s\\n\", head, argv[0]);\n \t\trename_branch(head, argv[0], rename > 1);\n-\telse if (rename && (argc == 2))\n+\t} else if (rename && (argc == 2))\n \t\trename_branch(argv[0], argv[1], rename > 1);\n \telse if (argc <= 2)\n \t\tcreate_branch(argv[0], (argc == 2) ? argv[1] : head,\n-- \n1.5.4.1.104.g84d88\n"},{"id":"68741","messageId":"47B46C8E.5030905@nrlssc.navy.mil","threadId":"12078","inReplyTo":"47B3EFC4.1020808@viscovery.net","subject":"Re: git-branch -m interprets first argument differently when two are supplied","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-02-14T16:30:06Z","receivedAt":"2008-02-14T16:30:06Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Johannes Sixt wrote:\n> Brandon Casey schrieb:\n>> The first non-option argument is interpreted differently depending on\n>> whether one argument or two arguments have been supplied.\n>>\n>> \tgit-branch -m [<oldbranch>] <newbranch>\n>>\n>> Has anyone considered whether this is inconsistent with how other\n>> commands operate?\n> \n> Funny, I fell into this trap just yesterday and accidentally renamed\n> my master branch to something else. IMO git-branch -m should take two\n> arguments. Full stop.\n\nActually, I think the single argument case is unambiguous and I would\nrather not give it up.\n\nIt's the two argument case that both expects its arguments in a different\norder than other commands _and_ is dangerous in the case of -M.\n\nI was thinking that -M should print a message describing what it is going\nto do, and prompt the user for confirmation. A new option could be added\nto suppress this behavior like -q. Or we could reuse -f, but see below.\n\nWhile I'm looking at git-branch, I think the capital forms are unnecessary.\nWe have a -f (force) option, so I think it makes more sense to deprecate\nthe captital forms(not remove them), and interpret -f along with -m or -d to\nprovide the same functionality. Again, with the behavior described above\nfor confirmation with something like -q.\n\nOh, and I wouldn't mind switching the arguments around after we have the\nconfirmation implemented. :)\n\n-brandon\n"},{"id":"68745","messageId":"alpine.LSU.1.00.0802141648120.30505@racer.site","threadId":"12078","inReplyTo":"47B46C8E.5030905@nrlssc.navy.mil","subject":"Re: git-branch -m interprets first argument differently when two are supplied","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-14T16:49:11Z","receivedAt":"2008-02-14T16:49:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Feb 2008, Brandon Casey wrote:\n\n> Johannes Sixt wrote:\n> > Brandon Casey schrieb:\n> >> The first non-option argument is interpreted differently depending on\n> >> whether one argument or two arguments have been supplied.\n> >>\n> >> \tgit-branch -m [<oldbranch>] <newbranch>\n> >>\n> >> Has anyone considered whether this is inconsistent with how other\n> >> commands operate?\n> > \n> > Funny, I fell into this trap just yesterday and accidentally renamed\n> > my master branch to something else. IMO git-branch -m should take two\n> > arguments. Full stop.\n> \n> Actually, I think the single argument case is unambiguous and I would\n> rather not give it up.\n> \n> It's the two argument case that both expects its arguments in a \n> different order than other commands _and_ is dangerous in the case of \n> -M.\n\nThe order was specifically requested, as \"mv\" also has that order.\n\nAnd \"-M\" is always dangerous.  Don't use it, if you don't know what you're \ndoing.\n\nAFAIR -M is even _marked_ as a dangerous command.\n\nCiao,\nDscho\n"},{"id":"68752","messageId":"47B477B8.5030209@nrlssc.navy.mil","threadId":"12078","inReplyTo":"alpine.LSU.1.00.0802141648120.30505@racer.site","subject":"Re: git-branch -m interprets first argument differently when two are supplied","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-02-14T17:17:44Z","receivedAt":"2008-02-14T17:17:44Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 14 Feb 2008, Brandon Casey wrote:\n> \n>> Johannes Sixt wrote:\n>>> Brandon Casey schrieb:\n>>>> The first non-option argument is interpreted differently depending on\n>>>> whether one argument or two arguments have been supplied.\n>>>>\n>>>> \tgit-branch -m [<oldbranch>] <newbranch>\n>>>>\n>>>> Has anyone considered whether this is inconsistent with how other\n>>>> commands operate?\n>>> Funny, I fell into this trap just yesterday and accidentally renamed\n>>> my master branch to something else. IMO git-branch -m should take two\n>>> arguments. Full stop.\n>> Actually, I think the single argument case is unambiguous and I would\n>> rather not give it up.\n>>\n>> It's the two argument case that both expects its arguments in a \n>> different order than other commands _and_ is dangerous in the case of \n>> -M.\n> \n> The order was specifically requested, as \"mv\" also has that order.\n\nDid you even read the original message? You point this out like it hasn't\nalready been mentioned.\n\nThe _point_ is that the order is _different_ than the order that other _git_\ncommands use. I give more weight to the relationship with other git commands\nthan to the relationship between the '-M' option and the 'mv' command. A\nsubcommand named 'mv' could have been used if a strong relationship was\nsupposed to be implied, something like 'git-branch mv <src> <dst>'. I'm not\nsure the single argument case would have retained its intuitiveness in this case.\n\n> And \"-M\" is always dangerous.\n\n>Don't use it, if you don't know what you're\n> doing.\n\nGee, thanks for the advice.\n\n-brandon\n"},{"id":"68756","messageId":"alpine.LSU.1.00.0802141720100.30505@racer.site","threadId":"12078","inReplyTo":"47B477B8.5030209@nrlssc.navy.mil","subject":"Re: git-branch -m interprets first argument differently when two are supplied","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-14T17:50:55Z","receivedAt":"2008-02-14T17:50:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Feb 2008, Brandon Casey wrote:\n\n> Johannes Schindelin wrote:\n> > \n> > On Thu, 14 Feb 2008, Brandon Casey wrote:\n> > \n> >> It's the two argument case that both expects its arguments in a \n> >> different order than other commands _and_ is dangerous in the case of \n> >> -M.\n> > \n> > The order was specifically requested, as \"mv\" also has that order.\n> \n> Did you even read the original message? You point this out like it \n> hasn't already been mentioned.\n\nYes, I had read it, but I had the impression that the rationale for the \ncurrent behaviour made a heck of a lot of sense.\n\n> >Don't use it, if you don't know what you're doing.\n> \n> Gee, thanks for the advice.\n\nYou're welcome, as always.\n\nCiao,\nDscho\n"}]}