{"thread":{"id":"49751","subject":"[RFC PATCH] checkout: add synonym of -b","startedAt":"2018-11-03T19:18:31Z","lastAt":"2018-11-05T00:41:55Z","messageCount":2,"participants":["Mikkel Kjeldsen","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"362376","messageId":"20181103191825.15674-1-commonquail@gmail.com","threadId":"49751","inReplyTo":null,"subject":"[RFC PATCH] checkout: add synonym of -b","fromName":"Mikkel Kjeldsen","fromEmail":"commonquail@gmail.com","sentAt":"2018-11-03T19:18:24Z","receivedAt":"2018-11-03T19:18:31Z","isPatch":true,"sender":{"key":"commonquail@gmail.com","avatar":null},"body":"Add --new-branch as a long-form synonym of -b. I occasionally encounter\nsome confusion in new users having interpreted \"checkout -b\" to mean\n\"checkout branch\", or internalized it as \"the way to create a new\nbranch\" rather than merely a convenience for \"branch && checkout\". I\nthink an explicit long-form can help alleviate that.\n\nSigned-off-by: Mikkel Kjeldsen <commonquail@gmail.com>\n---\n\nNotes:\n    This makes the synopsis and description lines look a little clumsy (and\n    I think incorrect...?) so if this proposal is accepted perhaps those\n    parts are better left out. It is meant more for training and\n    documentation than regular usage, anyway.\n    \n    I thought I had seen something like \"--create-branch\" in use by another\n    command and had intended to use that but I can no longer find that and\n    so went with \"--new-branch\" named after the option's argument.\n    \n    There does not seem to be a practice for testing short- versus long-form\n    arguments so I did not include one, but I'd be happy to.\n\n Documentation/git-checkout.txt | 5 +++--\n builtin/checkout.c             | 2 +-\n t/t9902-completion.sh          | 1 +\n 3 files changed, 5 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt\nindex 801de2f764..7651d8b83d 100644\n--- a/Documentation/git-checkout.txt\n+++ b/Documentation/git-checkout.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n 'git checkout' [-q] [-f] [-m] [<branch>]\n 'git checkout' [-q] [-f] [-m] --detach [<branch>]\n 'git checkout' [-q] [-f] [-m] [--detach] <commit>\n-'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]\n+'git checkout' [-q] [-f] [-m] [[(-b|--new-branch)|-B|--orphan] <new_branch>] [<start_point>]\n 'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...\n 'git checkout' [<tree-ish>] [--] <pathspec>...\n 'git checkout' (-p|--patch) [<tree-ish>] [--] [<paths>...]\n@@ -52,7 +52,7 @@ You could omit <branch>, in which case the command degenerates to\n rather expensive side-effects to show only the tracking information,\n if exists, for the current branch.\n \n-'git checkout' -b|-B <new_branch> [<start point>]::\n+'git checkout' (-b|--new-branch)|-B <new_branch> [<start point>]::\n \n \tSpecifying `-b` causes a new branch to be created as if\n \tlinkgit:git-branch[1] were called and then checked out.  In\n@@ -154,6 +154,7 @@ on your side branch as `theirs` (i.e. \"one contributor's work on top\n of it\").\n \n -b <new_branch>::\n+--new-branch=<new_branch>::\n \tCreate a new branch named <new_branch> and start it at\n \t<start_point>; see linkgit:git-branch[1] for details.\n \ndiff --git a/builtin/checkout.c b/builtin/checkout.c\nindex acdafc6e4c..4a27d94a86 100644\n--- a/builtin/checkout.c\n+++ b/builtin/checkout.c\n@@ -1232,7 +1232,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \tint dwim_remotes_matched = 0;\n \tstruct option options[] = {\n \t\tOPT__QUIET(&opts.quiet, N_(\"suppress progress reporting\")),\n-\t\tOPT_STRING('b', NULL, &opts.new_branch, N_(\"branch\"),\n+\t\tOPT_STRING('b', \"new-branch\", &opts.new_branch, N_(\"branch\"),\n \t\t\t   N_(\"create and checkout a new branch\")),\n \t\tOPT_STRING('B', NULL, &opts.new_branch_force, N_(\"branch\"),\n \t\t\t   N_(\"create/reset and checkout a branch\")),\ndiff --git a/t/t9902-completion.sh b/t/t9902-completion.sh\nindex 175f83d704..00614fdcc5 100755\n--- a/t/t9902-completion.sh\n+++ b/t/t9902-completion.sh\n@@ -1428,6 +1428,7 @@ test_expect_success 'double dash \"git checkout\"' '\n \t--ours Z\n \t--theirs Z\n \t--merge Z\n+\t--new-branch=Z\n \t--conflict=Z\n \t--patch Z\n \t--ignore-skip-worktree-bits Z\n\nbase-commit: d582ea202b626dcc6c3b01e1e11a296d9badd730\n-- \n2.19.1\n\n"},{"id":"362433","messageId":"xmqq1s80mk36.fsf@gitster-ct.c.googlers.com","threadId":"49751","inReplyTo":"20181103191825.15674-1-commonquail@gmail.com","subject":"Re: [RFC PATCH] checkout: add synonym of -b","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-11-05T00:41:49Z","receivedAt":"2018-11-05T00:41:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mikkel Kjeldsen <commonquail@gmail.com> writes:\n\n> Add --new-branch as a long-form synonym of -b. I occasionally encounter\n> some confusion in new users having interpreted \"checkout -b\" to mean\n> \"checkout branch\", or internalized it as \"the way to create a new\n> branch\" rather than merely a convenience for \"branch && checkout\". I\n> think an explicit long-form can help alleviate that.\n>\n> Signed-off-by: Mikkel Kjeldsen <commonquail@gmail.com>\n> ---\n>\n> Notes:\n>     This makes the synopsis and description lines look a little clumsy (and\n>     I think incorrect...?) so if this proposal is accepted perhaps those\n>     parts are better left out. It is meant more for training and\n>     documentation than regular usage, anyway.\n\nSounds like even you (who wrote this patch) expect the long form\noption to be impractical for regular usage and everybody would end\nup using the -b form?\n\nI am borderline \"Meh\" on this change, slightly on the negative side,\nprimarily because we'd need to worry about what to do with \"-B\" if\nwe did this to \"-b\", and I do not think it is worth even spending\nbrain cycles to worry about it (e.g. should it be\n--force-new-branch?  should --new-branch used together with --force\na better-looking alternative?  if we were to add --force, how should\nit interact with other existing options the command support? etc.)\n\nBut let's hear what others think.\n\nThanks.\n"}]}