{"thread":{"id":"21136","subject":"[PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","startedAt":"2009-10-05T20:46:23Z","lastAt":"2009-10-26T22:28:51Z","messageCount":91,"participants":["Jay Soffian","Sverre Rabbelier","Johannes Schindelin","Jeff King","Thomas Rast","Matthieu Moy","Mikael Magnusson","Junio C Hamano","Eugene Sajine","Björn Steinbrink","Johannes Sixt","Daniel Barkalow","Jakub Narebski","Nanako Shiraishi","Alex Riesen","Avery Pennarun","Erik Faye-Lund","Michael J Gruber","David Roundy","Uri Okrent"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"124275","messageId":"1254775583-49452-1-git-send-email-jaysoffian@gmail.com","threadId":"21136","inReplyTo":null,"subject":"[PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-10-05T20:46:23Z","receivedAt":"2009-10-05T20:46:23Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"A user who has just cloned a remote repository and wishes to then work on a\nbranch other than master may not realize they first need to create the local\nbranch. e.g.:\n\n$ git clone git://git.kernel.org/pub/scm/git/git.git\n$ cd git\n$ git checkout next\nerror: pathspec 'next' did not match any file(s) known to git.\n\nThis commit teaches git to make a suggestion to the user:\n\n$ git clone git://git.kernel.org/pub/scm/git/git.git\n$ cd git\n$ git checkout next\nerror: pathspec 'next' did not match any file(s) known to git.\nTo create a local branch from the same named remote branch, use\n git checkout -b next origin/next\n\nMotivated by http://article.gmane.org/gmane.comp.version-control.git/129528\n\nSigned-off-by: Jay Soffian \n---\n builtin-checkout.c | 43 +++++++++++++++++++++++++++++++++++++++++--\n 1 files changed, 41 insertions(+), 2 deletions(-)\n\nI dunno, this seems like a lot of code just to make a suggestion to the\nuser. Is it worth it?\n\nAlso, I initially was going to use for_each_remote_ref and compare every\nremote ref name to see if it tail matched what the user gave us, but it was\neasier to use for_each_remote and build up the remote ref name and then check\nfor its existence. Not sure if either approach is preferable.\n\nThoughts/comments?\n\ndiff --git a/builtin-checkout.c b/builtin-checkout.c\nindex d050c37..7f2e215 100644\n--- a/builtin-checkout.c\n+++ b/builtin-checkout.c\n@@ -145,6 +145,38 @@ static void fill_mm(const unsigned char *sha1, mmfile_t *mm)\n \tmm->size = size;\n }\n \n+struct suggest_new_branch_name_data {\n+\tconst char *name, *found;\n+\tint matches;\n+};\n+\n+static int suggest_new_branch_name_compare(struct remote *remote, void *priv)\n+{\n+\tstruct suggest_new_branch_name_data *data = priv;\n+\tunsigned char sha1[20];\n+\tstruct strbuf buf = STRBUF_INIT;\n+\tstrbuf_addf(&buf, \"refs/remotes/%s/%s\", remote->name, data->name);\n+\tif (resolve_ref(buf.buf, sha1, 1, NULL)) {\n+\t\tdata->matches++;\n+\t\tif (data->found)\n+\t\t\tstrbuf_release(&buf);\n+\t\telse\n+\t\t\tdata->found = strbuf_detach(&buf, NULL);\n+\t}\n+\treturn 0;\n+}\n+\n+static void suggest_new_branch_name(const char *name)\n+{\n+\tstruct suggest_new_branch_name_data data;\n+\tdata.name = name;\n+\tdata.found = NULL;\n+\tdata.matches = 0;\n+\tfor_each_remote(suggest_new_branch_name_compare, &data);\n+\tif (data.matches == 1)\n+\t\tfprintf(stderr, \"To create a local branch from the same named remote branch, use\\n git checkout -b %s %s\\n\", name, prettify_refname(data.found));\n+}\n+\n static int checkout_merged(int pos, struct checkout *state)\n {\n \tstruct cache_entry *ce = active_cache[pos];\n@@ -231,8 +263,13 @@ static int checkout_paths(struct tree *source_tree, const char **pathspec,\n \t\tmatch_pathspec(pathspec, ce->name, ce_namelen(ce), 0, ps_matched);\n \t}\n \n-\tif (report_path_error(ps_matched, pathspec, 0))\n+\tif (report_path_error(ps_matched, pathspec, 0)) {\n+\t\tfor (pos = 0; pathspec[pos]; pos++)\n+\t\t\t;\n+\t\tif (pos == 1)\n+\t\t\tsuggest_new_branch_name(pathspec[0]);\n \t\treturn 1;\n+\t}\n \n \t/* Any unmerged paths? */\n \tfor (pos = 0; pos < active_nr; pos++) {\n@@ -675,8 +712,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\t\targ = \"@{-1}\";\n \n \t\tif (get_sha1(arg, rev)) {\n-\t\t\tif (has_dash_dash) /* case (1) */\n+\t\t\tif (has_dash_dash) { /* case (1) */\n+\t\t\t\tsuggest_new_branch_name(arg);\n \t\t\t\tdie(\"invalid reference: %s\", arg);\n+\t\t\t}\n \t\t\tgoto no_reference; /* case (3 -> 2) */\n \t\t}\n \n-- \n1.6.4.2\n"},{"id":"124276","messageId":"fabb9a1e0910051403o6f26a2abn1c3e5d28b12c8838@mail.gmail.com","threadId":"21136","inReplyTo":"1254775583-49452-1-git-send-email-jaysoffian@gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-10-05T21:03:13Z","receivedAt":"2009-10-05T21:03:13Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Oct 5, 2009 at 22:46, Jay Soffian wrote:\n> To create a local branch from the same named remote branch, use\n>  git checkout -b next origin/next\n\nSince Dscho added the most useful \"-t\" option to git checkout, why not\nsuggest that?\n\n$ git checkout -t origin/next # instant win\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"124280","messageId":"alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"1254775583-49452-1-git-send-email-jaysoffian@gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-05T21:17:09Z","receivedAt":"2009-10-05T21:17:09Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Oct 2009, Jay Soffian wrote:\n\n> A user who has just cloned a remote repository and wishes to then work on a\n> branch other than master may not realize they first need to create the local\n> branch. e.g.:\n> \n> $ git clone git://git.kernel.org/pub/scm/git/git.git\n> $ cd git\n> $ git checkout next\n> error: pathspec 'next' did not match any file(s) known to git.\n> \n> This commit teaches git to make a suggestion to the user:\n> \n> $ git clone git://git.kernel.org/pub/scm/git/git.git\n> $ cd git\n> $ git checkout next\n> error: pathspec 'next' did not match any file(s) known to git.\n> To create a local branch from the same named remote branch, use\n> git checkout -b next origin/next\n> \n> Motivated by http://article.gmane.org/gmane.comp.version-control.git/129528\n\nActually, we should really think long and hard why we should not \nautomatically check out the local branch \"next\" in that case. I mean, \nreally long and hard, and making sure to take user-friendliness into \naccount at least as much as simplicity of implementation.\n\nCiao,\nDscho\n"},{"id":"124284","messageId":"fabb9a1e0910051426n7f4f8602l8fad733ac3ba82b3@mail.gmail.com","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-10-05T21:26:39Z","receivedAt":"2009-10-05T21:26:39Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Oct 5, 2009 at 23:17, Johannes Schindelin\n wrote:\n> Actually, we should really think long and hard why we should not\n> automatically check out the local branch \"next\" in that case.  I mean,\n> really long and hard, and making sure to take user-friendliness into\n> account at least as much as simplicity of implementation.\n\nIf git was a little more interactive I'd say prompt the user, problem solved?\n\n$ git checkout next\nNo such branch 'next', do you want to check out a local branch for\n'origin/next' instead? [Y/n]\n\n@jay: you assume that if there is more than one matching remote the\nuser is experienced (as they have multiple remotes) enough to know\nwhat to do?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"124285","messageId":"76718490910051457l2b12bae6w148ed3b7716bf5fe@mail.gmail.com","threadId":"21136","inReplyTo":"fabb9a1e0910051426n7f4f8602l8fad733ac3ba82b3@mail.gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-10-05T21:57:19Z","receivedAt":"2009-10-05T21:57:19Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Oct 5, 2009 at 5:26 PM, Sverre Rabbelier wrote:\n> @jay: you assume that if there is more than one matching remote the\n> user is experienced (as they have multiple remotes) enough to know\n> what to do?\n\nThat and it was just an RFC patch, so I just decided to ignore that\ncase initially.\n\nj.\n"},{"id":"124287","messageId":"76718490910051500m32878c7dgcc86489933cb2309@mail.gmail.com","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-10-05T22:00:05Z","receivedAt":"2009-10-05T22:00:05Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Oct 5, 2009 at 5:17 PM, Johannes Schindelin\n wrote:\n> Actually, we should really think long and hard why we should not\n> automatically check out the local branch \"next\" in that case.  I mean,\n> really long and hard, and making sure to take user-friendliness into\n> account at least as much as simplicity of implementation.\n\nSure, why not? Are you asking for a patch, or just soliciting conversation?\n\nj.\n"},{"id":"124288","messageId":"alpine.DEB.1.00.0910060044070.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"76718490910051500m32878c7dgcc86489933cb2309@mail.gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-05T22:45:10Z","receivedAt":"2009-10-05T22:45:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Oct 2009, Jay Soffian wrote:\n\n> On Mon, Oct 5, 2009 at 5:17 PM, Johannes Schindelin\n> wrote:\n> > Actually, we should really think long and hard why we should not\n> > automatically check out the local branch \"next\" in that case.  I mean,\n> > really long and hard, and making sure to take user-friendliness into\n> > account at least as much as simplicity of implementation.\n> \n> Sure, why not? Are you asking for a patch, or just soliciting \n> conversation?\n\nI am asking for thoughtful arguments for and against my (shyly implied) \nproposal.\n\nCiao,\nDscho\n"},{"id":"124290","messageId":"20091005225240.GA29335@coredump.intra.peff.net","threadId":"21136","inReplyTo":"1254775583-49452-1-git-send-email-jaysoffian@gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-05T22:52:40Z","receivedAt":"2009-10-05T22:52:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 05, 2009 at 04:46:23PM -0400, Jay Soffian wrote:\n\n> +static int suggest_new_branch_name_compare(struct remote *remote, void *priv)\n> +{\n> +\tstruct suggest_new_branch_name_data *data = priv;\n> +\tunsigned char sha1[20];\n> +\tstruct strbuf buf = STRBUF_INIT;\n> +\tstrbuf_addf(&buf, \"refs/remotes/%s/%s\", remote->name, data->name);\n> +\tif (resolve_ref(buf.buf, sha1, 1, NULL)) {\n> +\t\tdata->matches++;\n> +\t\tif (data->found)\n> +\t\t\tstrbuf_release(&buf);\n> +\t\telse\n> +\t\t\tdata->found = strbuf_detach(&buf, NULL);\n> +\t}\n> +\treturn 0;\n> +}\n\nThis assumes that remote X always has its tracking branches in\nrefs/remotes/X/*. But that is really dependent on how the fetch refspec\nis set up. True, it will be like that for remotes set up by \"git remote\"\nor \"git clone\", but it isn't universal (and we have tried not to make\nthat assumption elsewhere, like when finding upstream branches to merge\nfrom). Doing it right would mean interpreting the refspecs in\nremote.*.fetch.\n\nBut this is not necessarily about actual remotes, I don't think. It is\nreally about the names of refs we have, and that you could reference,\nbut that are not actual tracking branches. It's just that refs/remotes\nis the obvious hierarchy there.\n\nBut I wonder if what you should do instead is to iterate through each\nref, removing refs/heads/* and refs/tags/* (which are uninteresting, as\nthey are already part of the normal ref lookup), and then suffix-match.\nSo looking for \"next\" would find \"refs/remotes/origin/next\", or even\n\"refs/foobar/next\" if you had some \"foobar\" hierarchy.\n\nIt would also match \"foo\" to \"refs/remotes/origin/jk/foo\". I'm not sure\nif that is a feature or a bug, though.\n\n\nAside from that, I can't think of anything wrong with the idea.\nPersonally I find it more chatty than I would want, because I know what\nI'm doing. So I would suggest adding an advice.suggestBranchName config\noption to voluntarily suppress it.\n\n-Peff\n"},{"id":"124289","messageId":"20091005225611.GB29335@coredump.intra.peff.net","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-05T22:56:12Z","receivedAt":"2009-10-05T22:56:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 05, 2009 at 11:17:09PM +0200, Johannes Schindelin wrote:\n\n> > $ git clone git://git.kernel.org/pub/scm/git/git.git\n> > $ cd git\n> > $ git checkout next\n> > error: pathspec 'next' did not match any file(s) known to git.\n> > To create a local branch from the same named remote branch, use\n> > git checkout -b next origin/next\n> > \n> > Motivated by http://article.gmane.org/gmane.comp.version-control.git/129528\n> \n> Actually, we should really think long and hard why we should not \n> automatically check out the local branch \"next\" in that case. I mean, \n> really long and hard, and making sure to take user-friendliness into \n> account at least as much as simplicity of implementation.\n\nSome devil's advocate questions:\n\n 1. How do we find \"origin/next\" given \"next\"? What are the exact\n lookup rules? Do they cover every case? Do they avoid surprising\n the user?\n\n 2. What do we do if our lookup is ambiguous (e.g., \"origin/next\" and\n \"foobar/next\" both exist)?\n\n 3. If our lookup does have ambiguities or corner cases, is it better\n to simply be suggesting to the user, rather than proceeding with an\n action?\n\n-Peff\n"},{"id":"124297","messageId":"200910060932.24377.trast@student.ethz.ch","threadId":"21136","inReplyTo":"20091005225611.GB29335@coredump.intra.peff.net","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-06T07:32:22Z","receivedAt":"2009-10-06T07:32:22Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King wrote:\n> On Mon, Oct 05, 2009 at 11:17:09PM +0200, Johannes Schindelin wrote:\n> \n> > > $ git checkout next\n> > > error: pathspec 'next' did not match any file(s) known to git.\n> > \n> > Actually, we should really think long and hard why we should not \n> > automatically check out the local branch \"next\" in that case. I mean, \n> > really long and hard, and making sure to take user-friendliness into \n> > account at least as much as simplicity of implementation.\n> \n> Some devil's advocate questions:\n> \n> 1. How do we find \"origin/next\" given \"next\"? What are the exact\n> lookup rules? Do they cover every case? Do they avoid surprising\n> the user?\n> \n> 2. What do we do if our lookup is ambiguous (e.g., \"origin/next\" and\n> \"foobar/next\" both exist)?\n> \n> 3. If our lookup does have ambiguities or corner cases, is it better\n> to simply be suggesting to the user, rather than proceeding with an\n> action?\n\nIf I may add another:\n\n4. Are there any (scripted?) use-cases where git-checkout should fail\n because it was given an invalid branch name?\n\nThe following gives a hint, though they could of course be fixed and\nthe ^0 case doesn't really count:\n\n $ git grep 'git checkout .*||' -- \"*.sh\"\n git-bisect.sh: git checkout \"$start_head\" -- || exit\n git-rebase--interactive.sh: output git checkout $first_parent 2> /dev/null ||\n git-rebase--interactive.sh: output git checkout \"$1\" ||\n git-rebase.sh:git checkout -q \"$onto^0\" || die \"could not detach HEAD\"\n t/t2007-checkout-symlink.sh:git checkout -f master || exit\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"124300","messageId":"alpine.DEB.1.00.0910061111410.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"20091005225611.GB29335@coredump.intra.peff.net","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-06T09:12:51Z","receivedAt":"2009-10-06T09:12:51Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Oct 2009, Jeff King wrote:\n\n> On Mon, Oct 05, 2009 at 11:17:09PM +0200, Johannes Schindelin wrote:\n> \n> > > $ git clone git://git.kernel.org/pub/scm/git/git.git\n> > > $ cd git\n> > > $ git checkout next\n> > > error: pathspec 'next' did not match any file(s) known to git.\n> > > To create a local branch from the same named remote branch, use\n> > > git checkout -b next origin/next\n> > > \n> > > Motivated by http://article.gmane.org/gmane.comp.version-control.git/129528\n> > \n> > Actually, we should really think long and hard why we should not \n> > automatically check out the local branch \"next\" in that case. I mean, \n> > really long and hard, and making sure to take user-friendliness into \n> > account at least as much as simplicity of implementation.\n> \n> Some devil's advocate questions:\n> \n> 1. How do we find \"origin/next\" given \"next\"? What are the exact\n> lookup rules? Do they cover every case? Do they avoid surprising\n> the user?\n\nI am sure your strategy would be the same as mine: enumerate all remote \nbranches, strip the remote nickname, and compare. If there are \nambiguities, tell the user and stop.\n\n> 2. What do we do if our lookup is ambiguous (e.g., \"origin/next\" and\n> \"foobar/next\" both exist)?\n\nSee above.\n\n> \n> 3. If our lookup does have ambiguities or corner cases, is it better\n> to simply be suggesting to the user, rather than proceeding with an\n> action?\n\nSee above.\n\nCiao,\nDscho\n"},{"id":"124301","messageId":"alpine.DEB.1.00.0910061112570.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"200910060932.24377.trast@student.ethz.ch","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-06T09:16:58Z","receivedAt":"2009-10-06T09:16:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Oct 2009, Thomas Rast wrote:\n\n> Jeff King wrote:\n> > On Mon, Oct 05, 2009 at 11:17:09PM +0200, Johannes Schindelin wrote:\n> > \n> > > > $ git checkout next\n> > > > error: pathspec 'next' did not match any file(s) known to git.\n> > > \n> > > Actually, we should really think long and hard why we should not \n> > > automatically check out the local branch \"next\" in that case. I mean, \n> > > really long and hard, and making sure to take user-friendliness into \n> > > account at least as much as simplicity of implementation.\n> > \n> > Some devil's advocate questions:\n> > \n> > 1. How do we find \"origin/next\" given \"next\"? What are the exact\n> > lookup rules? Do they cover every case? Do they avoid surprising\n> > the user?\n> > \n> > 2. What do we do if our lookup is ambiguous (e.g., \"origin/next\" and\n> > \"foobar/next\" both exist)?\n> > \n> > 3. If our lookup does have ambiguities or corner cases, is it better\n> > to simply be suggesting to the user, rather than proceeding with an\n> > action?\n> \n> If I may add another:\n> \n> 4. Are there any (scripted?) use-cases where git-checkout should fail\n> because it was given an invalid branch name?\n> \n> The following gives a hint, though they could of course be fixed and\n> the ^0 case doesn't really count:\n> \n> $ git grep 'git checkout .*||' -- \"*.sh\"\n> git-bisect.sh: git checkout \"$start_head\" -- || exit\n> git-rebase--interactive.sh: output git checkout $first_parent 2> /dev/null ||\n> git-rebase--interactive.sh: output git checkout \"$1\" ||\n> git-rebase.sh:git checkout -q \"$onto^0\" || die \"could not detach HEAD\"\n> t/t2007-checkout-symlink.sh:git checkout -f master || exit\n\nActually, in said cases (with exception of the test case, which should be \nfine, however, having no remote branches), I would expect the user to be \ngrateful if the DWIMery would happen.\n\nI have to clarify something here: I am not proposing to include a patch \nthat does that DWIMery. We need to discuss the downsides and upsides \nuntil we can be pretty certain that it does more good than harm.\n\nUnfortunately, this list does not seem to be very inviting to pure users, \nwho I hoped would chime in on this issue.\n\nCiao,\nDscho\n"},{"id":"124302","messageId":"vpqiqesna6x.fsf@bauges.imag.fr","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910061111410.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2009-10-06T09:28:06Z","receivedAt":"2009-10-06T09:28:06Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 5 Oct 2009, Jeff King wrote:\n>\n>> Some devil's advocate questions:\n>> \n>> 1. How do we find \"origin/next\" given \"next\"? What are the exact\n>> lookup rules? Do they cover every case? Do they avoid surprising\n>> the user?\n>\n> I am sure your strategy would be the same as mine: enumerate all remote \n> branches, strip the remote nickname, and compare. If there are \n> ambiguities, tell the user and stop.\n>\n>> 2. What do we do if our lookup is ambiguous (e.g., \"origin/next\" and\n>> \"foobar/next\" both exist)?\n>\n> See above.\n\nOne problem with this approach is that if users get used to the\nbehavior, the command will have great probability to end up in a\nuser's script, then the script will \"work\" as long as there is no\nambiguity, and cease to work afterwards. And for the user of the\nscript, this will sound like \"WTF, it was working yesterday and it's\nbroken now\".\n\nSo, the good thing with being strict, even if giving advice in case of\nfailure, is that it teaches the user the reliable way to do.\n\nAll that said, I'm not sure how serious this is, but we're in a\n\"devil's advocate\" session, so I'm still allowed to speak ;-).\n\n\nThe other fear I have is to create confusion. Today, it's quite clear\nthat \"next\" is not the same as \"origin/next\". With some DWIMery on top\nof this, a naive user may think they are more or less the same, and\nthen not understand what \"git fetch\" does and why it's not the same as\n\"git pull\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"124303","messageId":"237967ef0910060241q671baafav93fe6402a4c510c5@mail.gmail.com","threadId":"21136","inReplyTo":"vpqiqesna6x.fsf@bauges.imag.fr","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Mikael Magnusson","fromEmail":"mikachu@gmail.com","sentAt":"2009-10-06T09:41:07Z","receivedAt":"2009-10-06T09:41:07Z","isPatch":true,"sender":{"key":"mikachu@gmail.com","avatar":null},"body":"2009/10/6 Matthieu Moy :\n> Johannes Schindelin writes:\n>\n>> Hi,\n>>\n>> On Mon, 5 Oct 2009, Jeff King wrote:\n>>\n>>> Some devil's advocate questions:\n>>>\n>>> 1. How do we find \"origin/next\" given \"next\"? What are the exact\n>>> lookup rules? Do they cover every case? Do they avoid surprising\n>>> the user?\n>>\n>> I am sure your strategy would be the same as mine: enumerate all remote\n>> branches, strip the remote nickname, and compare. If there are\n>> ambiguities, tell the user and stop.\n>>\n>>> 2. What do we do if our lookup is ambiguous (e.g., \"origin/next\" and\n>>> \"foobar/next\" both exist)?\n>>\n>> See above.\n>\n> One problem with this approach is that if users get used to the\n> behavior, the command will have great probability to end up in a\n> user's script, then the script will \"work\" as long as there is no\n> ambiguity, and cease to work afterwards. And for the user of the\n> script, this will sound like \"WTF, it was working yesterday and it's\n> broken now\".\n>\n> So, the good thing with being strict, even if giving advice in case of\n> failure, is that it teaches the user the reliable way to do.\n\nI can imagine this happening:\n% git clone git://git.git git\n% git checkout next\ndo you want to checkout origin/next? y\n# a few days later\n% git fetch\n% git checkout next\n[freenode] /join #git\n[#git] i did git checkout next but my files are still the same?\n\n-- \nMikael Magnusson\n"},{"id":"124306","messageId":"alpine.DEB.1.00.0910061151420.4686@intel-tinevez-2-302","threadId":"21136","inReplyTo":"237967ef0910060241q671baafav93fe6402a4c510c5@mail.gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-06T10:04:54Z","receivedAt":"2009-10-06T10:04:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Oct 2009, Mikael Magnusson wrote:\n\n> I can imagine this happening:\n> % git clone git://git.git git\n> % git checkout next\n> do you want to checkout origin/next? y\n> # a few days later\n> % git fetch\n> % git checkout next\n> [freenode] /join #git\n> [#git] i did git checkout next but my files are still the same?\n\nI imagined more something like this:\n\n$ git clone git://git.git git\n$ git checkout next\nAutomatically checking out local branch 'next' tracking 'origin/next'.\nPlease update it with 'git pull'.\n\nCiao,\nDscho\n"},{"id":"124310","messageId":"7vvdis21qk.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910061112570.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-06T11:36:19Z","receivedAt":"2009-10-06T11:36:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> 4. Are there any (scripted?) use-cases where git-checkout should fail\n>> because it was given an invalid branch name?\n>> \n>> The following gives a hint, though they could of course be fixed and\n>> the ^0 case doesn't really count:\n>> \n>> $ git grep 'git checkout .*||' -- \"*.sh\"\n>> git-bisect.sh: git checkout \"$start_head\" -- || exit\n>> git-rebase--interactive.sh: output git checkout $first_parent 2> /dev/null ||\n>> git-rebase--interactive.sh: output git checkout \"$1\" ||\n>> git-rebase.sh:git checkout -q \"$onto^0\" || die \"could not detach HEAD\"\n>> t/t2007-checkout-symlink.sh:git checkout -f master || exit\n>\n> Actually, in said cases (with exception of the test case, which should be \n> fine, however, having no remote branches), I would expect the user to be \n> grateful if the DWIMery would happen.\n\nDid you check the context before making that assertion?\n\n - The one in git-bisect switches to (or detaches at) what was earlier\n written in BISECT_START, which is either a branch name or a commit\n object name, so the user definitely does not want DWIMery if it could\n check out something else --- I do not think DWIMery hurts as long as\n the user does not delete the original branch while bisecting, though.\n\n - The first one in \"rebase -i\" is always fed a commit object name;\n DWIMery is not needed (and it would not hurt).\n\n - The second one in \"rebase -i\" is about switching to the branch being\n rebased, and it has an explicit check to see if \"$1\" is a branch name;\n DWIMery is not needed (and it would not hurt because of the check\n before it).\n\n - The one in \"rebase\" proper, as Thomas pointed out, is an explicit\n request to detach, so DWIMery won't happen.\n\nThe first three cases that could trigger DWIMery fall into \"DWIMery does\nnot hurt because it happens to be a no-op in the way it is used\" category,\nnot \"In this case, the users would actively appreciate DWIMery\". IOW,\nthis does not look particularly a good argument to support DWIMery to me.\n\nAbout the second one in \"rebase -i\", and also the corresponding one in\n\"rebase\", which is:\n\n\ttest -z \"$switch_to\" || git checkout \"$switch_to\"\n\nIf the command did DWIM, you would fork a local branch from the remote and\nimmediately rebase it. Any good git tutorial teaches not to rebase work\nby others, and keeping the result of such a rebase on a local branch goes\ndirectly against it [*1*]; the script needs to be updated to protect\nitself from DWIMery if we were to change \"checkout\" in these cases.\n\n\n[Footnote]\n\n*1* It is quite useful to temporarily rebase others work, e.g. in order to\ncompare what got changed in the newer version of series, so I wouldn't\nobject if the user did\n\n git checkout origin/topic\n git rebase $(git merge-base origin/topic@{1} origin/topic)\n git show-branch origin/topic@{1} HEAD\n\nbut notice that it all happens on detached HEAD, not to be kept.\n"},{"id":"124313","messageId":"alpine.DEB.1.00.0910061359560.4686@intel-tinevez-2-302","threadId":"21136","inReplyTo":"7vvdis21qk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-06T12:02:41Z","receivedAt":"2009-10-06T12:02:41Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Oct 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> 4. Are there any (scripted?) use-cases where git-checkout should fail\n> >> because it was given an invalid branch name?\n> >> \n> >> The following gives a hint, though they could of course be fixed and\n> >> the ^0 case doesn't really count:\n> >> \n> >> $ git grep 'git checkout .*||' -- \"*.sh\"\n> >> git-bisect.sh: git checkout \"$start_head\" -- || exit\n> >> git-rebase--interactive.sh: output git checkout $first_parent 2> /dev/null ||\n> >> git-rebase--interactive.sh: output git checkout \"$1\" ||\n> >> git-rebase.sh:git checkout -q \"$onto^0\" || die \"could not detach HEAD\"\n> >> t/t2007-checkout-symlink.sh:git checkout -f master || exit\n> >\n> > Actually, in said cases (with exception of the test case, which should be \n> > fine, however, having no remote branches), I would expect the user to be \n> > grateful if the DWIMery would happen.\n> \n> Did you check the context before making that assertion?\n\nNo, but I checked the _names_ of the scripts.\n\nIn case of bisect, if I know upstream is good, I might indeed say \"git \nbisect good next\", even if I haven't checked myself earlier.\n\nIn case of \"rebase\", about the same happens: if I say \"git rebase next\", \nand there is no \"next\", but an \"origin/next\", and no other remote branch \n\"*/next\", it is pretty clear what I mean, too.\n\nIn any case, it seems pretty clear to me that this DWIMery, while I am \npretty certain would be useful for actual users without commits in \ngit.git, will not make it into git.git.\n\nSo I'll stop wasting my time with this discussion.\n\nCiao,\nDscho\n"},{"id":"124318","messageId":"76c5b8580910060943k6172e3a5waee2f92c403e5cc3@mail.gmail.com","threadId":"21136","inReplyTo":"0016e68fd0123a175304754694b4@google.com","subject":"Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Eugene Sajine","fromEmail":"euguess@gmail.com","sentAt":"2009-10-06T16:43:28Z","receivedAt":"2009-10-06T16:43:28Z","isPatch":true,"sender":{"key":"euguess@gmail.com","avatar":null},"body":"It seams that my first email was eaten by the server for some\nreason... Sorry, if it will be a dupe.\n\nOn Tue, Oct 6, 2009 at 12:18 PM,   wrote:\n Hi,\n\n If i may have a word:\n\n> On Oct 6, 2009 5:41am, Mikael Magnusson wrote:\n>> I can imagine this happening:\n>>\n>> % git clone git://git.git git\n>>\n>> % git checkout next\n>>\n>> do you want to checkout origin/next? y\n>>\n>> # a few days later\n>>\n>> % git fetch\n>>\n>> % git checkout next\n>>\n>> [freenode] /join #git\n>>\n>> [#git] i did git checkout next but my files are still the same?\n>>\n\n\n I'm a new user of git and I don't think i will ever have a commit in\n git.git, because I'm not a programmer (I'm QA). I was reading this topic as\n carefully as i could and I think that this makes a lot of sense to address\n this issue. As i understand when somebody fetches from remote repo in order\n to be able to start working on the code from this remote repo you should\n create tracking branch for one of the branches from remote and only then you\n should do your changes or perform merges.\n in case if you didn't do that and you try to checkout you will end up having\n detached HEAD which is quite scary;) for non-experienced user and as i see\n might lead to some unnecessary questions in this list or on IRC channel...\n As for the solution i would choose the \"simplest thing that will work\" - so\n i think that we just have to notify user about his suicide attempt to\n checkout nonlocal branch and offer him a correct syntax to go with.\n Something like below should work:\n\n % git clone git://git.git git\n % git checkout next\n You're attempting to checkout to non-local branch. This will lead to your\n HEAD being detached (our team is on its way!).\n Do you want to check out local branch 'next' tracking 'origin/next' instead?\n y/n\n\n if yes, then:\n Created branch \"next\" tracking \"origin/next\"\n You can update it with 'git pull'.\n\n If no - abort or continue with checkout to nonlocal branch? ('m not sure if\n detaching HEAD can provide some benefits if done on purpose)\n\n I hope I'm not missing anything...\n\n Thanks,\n Eugene\n"},{"id":"124321","messageId":"7viqesz3mk.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910061359560.4686@intel-tinevez-2-302","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-06T20:09:07Z","receivedAt":"2009-10-06T20:09:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So I'll stop wasting my time with this discussion.\n\nI do not think it was a waste of time; earlier you said that you were not\nproposing to include a patch that does that DWIMery, and we need to\ndiscuss the downsides and upsides until we can figure out if it does more\ngood than harm.\n\nAnd I think we reasonably established that this does more harm than good,\nso I am Ok if you want to stop here.\n"},{"id":"124322","messageId":"7vzl84xnx0.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"76c5b8580910060943k6172e3a5waee2f92c403e5cc3@mail.gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-06T20:33:47Z","receivedAt":"2009-10-06T20:33:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eugene Sajine writes:\n\n> As for the solution i would choose the \"simplest thing that will work\" - so\n> i think that we just have to notify user about his suicide attempt to\n> checkout nonlocal branch and offer him a correct syntax to go with.\n\nWe already do that, without going interactive, for warning unintended\ndetachment:\n\n $ git checkout origin/next\n Note: moving to 'origin/next' which isn't a local branch\n If you want to create a new branch from this checkout, you may do so\n (now or later) by using -b with the checkout command again. Example:\n git checkout -b \n ...\n\nAs to Mikael's scenario:\n\n>>> I can imagine this happening:\n>>> % git clone git://git.git git\n>>> % git checkout next\n>>> do you want to checkout origin/next? y\n>>> # a few days later\n>>> % git fetch\n>>> % git checkout next\n>>> [freenode] /join #git\n>>> [#git] i did git checkout next but my files are still the same?\n\nNo amount of sugarcoating the checkout syntax changes the fact that in the\nuser's repository there _are_ two distinct refs, origin/next and next, and\nthe \"fetch few days later\" updates only the former but never the latter.\nIt can only be fixed by injecting a bit of clue to the user, in a way\nDscho suggested in the thread.\n"},{"id":"124678","messageId":"alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"0016e68fd0123a175304754694b4@google.com","subject":"Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-12T07:49:50Z","receivedAt":"2009-10-12T07:49:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Oct 2009, Euguess@gmail.com wrote:\n\n> I'ma new user of git and I don't think i will ever have a commit in \n> git.git, because I'm not a programmer (I'm QA).\n\nWelcome!\n\nLet me take this opportunity to express my deep sadness that your first \ninput to this list was brushed off so carelessly.\n\nI sincerely hope that you give us another chance, and that you let us \nbenefit from your fresh and unbiased view of the usability issues in Git \n(some of us use Git for so long, they think that Git has no usability \nissues anymore).\n\n> I was reading this topic as carefully as i could and I think that this \n> makes a lot of sense to address this issue. As i understand when \n> somebody fetches from remote repo in order to be able to start working \n> on the code from this remote repo you should create tracking branch for \n> one of the branches from remote and only then you should do your changes \n> or perform merges.\n>\n> in case if you didn't do that and you try to checkout you will end up \n> having detached HEAD which is quite scary;) for non-experienced user and \n> as i see might lead to some unnecessary questions in this list or on IRC \n> channel...\n\nRight. We see that type of confusion in #git everyday, and blaming the \nuser would be a violation of http://c2.com/cgi/wiki?BlameTheRightThing\n\n> As for the solution i would choose the \"simplest thing that will work\" - \n> so i think that we just have to notify user about his suicide attempt to \n> checkout nonlocal branch and offer him a correct syntax to go with.\n>\n> Something like below should work:\n> \n> % git clone git://git.git git\n> % git checkout next\n> You're attempting to checkout to non-local branch. This will lead to your HEAD\n> being detached (our team is on its way!).\n> Do you want to check out local branch 'next' tracking 'origin/next' instead?\n> y/n\n> \n> if yes, then:\n> Created branch \"next\" tracking \"origin/next\"\n> You can update it with 'git pull'.\n> \n> If no - abort or continue with checkout to nonlocal branch? ('m not sure if\n> detaching HEAD can provide some benefits if done on purpose)\n> \n> I hope I'm not missing anything...\n\nNo, I think that is something perfectly fine to expect in a software whose \nUI complexity is unfortunately pretty much in disagreement with its \ninternal complexity.\n\nOne thing one might add for the technically inclined folks (i.e. those who \nneed to implement, and to see that Git is in dear need of some \nuser-friendliness first): \"git checkout\" is a porcelain (i.e. a program \nmeant for end-user consumption), and as such should not have a problem to \nreact to isatty(0) (i.e. \"is the input coming directly from the \nconsole?\").\n\nSo yes, even if I was on the verge of giving up on this thread, I have \nbeen encouraged enough to get this uphill battle going again, and to try \nto overturn some stubborn resistance.\n\nCiao,\nDscho\n"},{"id":"124733","messageId":"20091012183658.GA17857@atjola.homenet","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de","subject":"Re: Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-10-12T18:36:58Z","receivedAt":"2009-10-12T18:36:58Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.10.12 09:49:50 +0200, Johannes Schindelin wrote:\n> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:\n> > I'ma new user of git and I don't think i will ever have a commit in \n> > git.git, because I'm not a programmer (I'm QA).\n[...]\n> > As for the solution i would choose the \"simplest thing that will work\" - \n> > so i think that we just have to notify user about his suicide attempt to \n> > checkout nonlocal branch and offer him a correct syntax to go with.\n> >\n> > Something like below should work:\n> > \n> > % git clone git://git.git git\n> > % git checkout next\n> > You're attempting to checkout to non-local branch. This will lead to your HEAD\n> > being detached (our team is on its way!).\n> > Do you want to check out local branch 'next' tracking 'origin/next' instead?\n> > y/n\n> > \n> > if yes, then:\n> > Created branch \"next\" tracking \"origin/next\"\n> > You can update it with 'git pull'.\n> > \n> > If no - abort or continue with checkout to nonlocal branch? ('m not sure if\n> > detaching HEAD can provide some benefits if done on purpose)\n> > \n> > I hope I'm not missing anything...\n> \n> No, I think that is something perfectly fine to expect in a software whose \n> UI complexity is unfortunately pretty much in disagreement with its \n> internal complexity.\n> \n> One thing one might add for the technically inclined folks (i.e. those who \n> need to implement, and to see that Git is in dear need of some \n> user-friendliness first): \"git checkout\" is a porcelain (i.e. a program \n> meant for end-user consumption), and as such should not have a problem to \n> react to isatty(0) (i.e. \"is the input coming directly from the \n> console?\").\n\nSo I didn't mean to chime in, but anyway... A few days ago, uau on #git\nsaid that he thinks that \"git clone\" shouldn't create any branch heads\nat all. Instead, git should learn to do something like \"svn up\", when\nthe user checked out a remote tracking branch. That was specifically\nmeant for users that _don't_ commit, like, say, QA guys ;-)\n\nI didn't quite agree on the idea (feel free to tell me that I just blank\nout UI problems :-p), but anyway, I felt like coming up with some hack\nthat achieves said functionality. The result was inspired by \"git\ncheckout -\" and looks at HEAD's reflog to figure out whether the user\nhas checked out a remote tracking branch the last time he used checkout\nto switch branches. I dared to call it \"git-up\" in my $HOME/bin ;-)\n\n#!/bin/bash\nMODE=${1:---merge}\n\nRTB=$(git rev-parse --symbolic-full-name $(git reflog | grep 'checkout: moving from .* to' | head -1 | sed -e 's/.* to //'))\n\nif [ ${RTB:0:13} != \"refs/remotes/\" ]\nthen\n\techo \"You're not on a remote tracking branch\"\n\texit 1\nfi\n\nSRTB=${RTB#refs/remotes/}\nREMOTE=${SRTB%/*}\ngit fetch $REMOTE\ngit reset $MODE $RTB\n\n\nIt's obviously basically just \"git reset\" on crack, happily dropping\nlocal commits. A \"real\" implementation would likely have to have more\nchecks to ensure that the user is using it in an expected way (like\nchecking that refs/remotes/whatever..HEAD is empty). And it could be\nmade to work with regular branch heads as well then, as a \"fast-forward\nonly\" way of updating (think \"git merge --ff-only\", but in a less\nillogical way, as \"--ff-only\" actually means \"don't create a merge\",\nwhich is kinda weird, at least to me).\n\nAs I said, I don't really agree on the idea of not creating any branch\nheads on \"clone\", but maybe it's because I'm not a \"don't commit, just\nwatch\" person. And the theoretical \"git up\" command might be handy for\nguys that just want to follow things, and thus don't really need branch\nheads. At the moment, I don't have any intentions to improve the hack\n(also due to lack of time), but if it seems worthwhile to anyone, feel\nfree to pick it up.\n\nBjörn, -ENOPATCH ;-)\n"},{"id":"124762","messageId":"200910122340.13366.trast@student.ethz.ch","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-12T21:40:11Z","receivedAt":"2009-10-12T21:40:11Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Johannes Schindelin wrote:\n> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:\n> > in case if you didn't do that and you try to checkout you will end up \n> > having detached HEAD which is quite scary;) for non-experienced user and \n> > as i see might lead to some unnecessary questions in this list or on IRC \n> > channel...\n[...]\n> One thing one might add for the technically inclined folks (i.e. those who \n> need to implement, and to see that Git is in dear need of some \n> user-friendliness first): \"git checkout\" is a porcelain (i.e. a program \n> meant for end-user consumption), and as such should not have a problem to \n> react to isatty(0) (i.e. \"is the input coming directly from the \n> console?\").\n\nSadly git-checkout seems to be stuck between being declared a\nporcelain, but at the same time being an extremely important command\nfor scripts all over. (There are probably others in the same place:\nreset comes to mind.)\n\nYour idea is also a backwards incompatible change, so we can just as\nwell implement the original suggestion and force scripts (or us) to\nuse some other means when they want to detach. Say, why not just\ninvent an option along the lines of\n\n git checkout {-d|--detach} $ref\n\nto make it explicit. We have to resort to more arcane means to\n*reliably* detach anyway, like 'git checkout master^0'. Then in some\nfuture release, git-checkout will start making DWIM branches if the -d\nis not given.\n\nAnd while we're there, --attach would be a nice complement to force\nrefs/heads/foo to attach.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"124771","messageId":"7vr5t89qiw.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"200910122340.13366.trast@student.ethz.ch","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-12T22:49:27Z","receivedAt":"2009-10-12T22:49:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Your idea is also a backwards incompatible change, so we can just as\n> well implement the original suggestion and force scripts (or us) to\n> use some other means when they want to detach. Say, why not just\n> invent an option along the lines of\n>\n> git checkout {-d|--detach} $ref\n>\n> to make it explicit.\n\nOr can't you go the other way, say\n\n\tgit checkout -t $remote_tracking\n\nto create a local branch forking from the named remote tracking branch?\n"},{"id":"124812","messageId":"200910130836.57011.trast@student.ethz.ch","threadId":"21136","inReplyTo":"7vr5t89qiw.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-13T06:36:53Z","receivedAt":"2009-10-13T06:36:53Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> Thomas Rast writes:\n> \n> > Your idea is also a backwards incompatible change, so we can just as\n> > well implement the original suggestion and force scripts (or us) to\n> > use some other means when they want to detach. Say, why not just\n> > invent an option along the lines of\n> >\n> > git checkout {-d|--detach} $ref\n> >\n> > to make it explicit.\n> \n> Or can't you go the other way, say\n> \n> \tgit checkout -t $remote_tracking\n> \n> to create a local branch forking from the named remote tracking branch?\n\nSure, but we already have that and we still failed to fix the users,\nso FWIW, I think Dscho's right and we should try fixing the UI next.\n\n[I've also seen several users shoot themselves with detached HEADs to\nthe point where I explain the concept before even mentioning\ncheckout.]\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"124819","messageId":"7vljjf226t.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"200910130836.57011.trast@student.ethz.ch","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T07:16:58Z","receivedAt":"2009-10-13T07:16:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n>> Or can't you go the other way, say\n>> \n>> \tgit checkout -t $remote_tracking\n>> \n>> to create a local branch forking from the named remote tracking branch?\n>\n> Sure, but we already have that and we still failed to fix the users,\n> so FWIW, I think Dscho's right and we should try fixing the UI next.\n\nWhat it means is that -t was a broken attempt to help the users at the UI\nlevel, and I can surely see that.\n\nSo we need the set of new rules, say, for 1.7.0 release. A strawman?\n\nAssume that these are the only refs that exist:\n\n refs/remotes/origin/{master,next,nitfol}\n refs/remotes/xyzzy/{frotz,nitfol}\n refs/heads/master\n refs/tags/v1.0.0\n\n#0. These will stay as is:\n\n $ git checkout mine ;# switches to the branch\n $ git checkout $any_committish^0 ;# detaches\n\n#1. These used to detach, but will create a local branch\n\n $ git checkout origin/next ;# as if with -t\n $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)\n\n#2. These are allowed only when unambiguous and there is no local branch yet.\n\n $ git checkout next ;# ok\n $ git checkout frotz ;# ok (origin is not special)\n $ git checkout nitfol ;# not ok (ambiguous and origin is not special)\n\n#3. These used to detach, but what should we do?\n\n $ git checkout v1.0.0 ;# detach, or refuse???\n $ git checkout origin/master ;# detach, or refuse???\n\nI can buy 0, 1, and 2, and I think it is a minor inconvenience if we\nstarted refusing to detach in case #3, as people who want to detach can\nalways suffix ^0 or ~0 to make it a general committish.\n\nDid I cover all cases?\n"},{"id":"124830","messageId":"7v7huzznqy.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"7vljjf226t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T08:44:53Z","receivedAt":"2009-10-13T08:44:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> So we need the set of new rules, say, for 1.7.0 release. A strawman?\n>\n> Assume that these are the only refs that exist:\n>\n> refs/remotes/origin/{master,next,nitfol}\n> refs/remotes/xyzzy/{frotz,nitfol}\n> refs/heads/master\n\nSorry, I had this as refs/heads/{master,mine} in my initial draft but\nremoved the 'mine' branch by mistake; the first item in #0 does not make\nsense without it.\n\n> refs/tags/v1.0.0\n>\n> #0. These will stay as is:\n>\n> $ git checkout mine ;# switches to the branch\n> $ git checkout $any_committish^0 ;# detaches\n>\n> #1. These used to detach, but will create a local branch\n>\n> $ git checkout origin/next ;# as if with -t\n> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)\n>\n> #2. These are allowed only when unambiguous and there is no local branch yet.\n>\n> $ git checkout next ;# ok\n> $ git checkout frotz ;# ok (origin is not special)\n> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)\n>\n> #3. These used to detach, but what should we do?\n>\n> $ git checkout v1.0.0 ;# detach, or refuse???\n> $ git checkout origin/master ;# detach, or refuse???\n>\n> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we\n> started refusing to detach in case #3, as people who want to detach can\n> always suffix ^0 or ~0 to make it a general committish.\n>\n> Did I cover all cases?\n"},{"id":"124831","messageId":"200910131051.47117.trast@student.ethz.ch","threadId":"21136","inReplyTo":"7vljjf226t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-13T08:51:45Z","receivedAt":"2009-10-13T08:51:45Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> \n> What it means is that -t was a broken attempt to help the users at the UI\n> level, and I can surely see that.\n> \n> So we need the set of new rules, say, for 1.7.0 release. A strawman?\n\nI feel somewhat uneasy commenting on this because I have a history of\nwriting just-barely-workable UIs. That being said:\n\n> Assume that these are the only refs that exist:\n> \n> refs/remotes/origin/{master,next,nitfol}\n> refs/remotes/xyzzy/{frotz,nitfol}\n> refs/heads/master\n> refs/tags/v1.0.0\n> \n> #0. These will stay as is:\n> \n> $ git checkout mine ;# switches to the branch\n> $ git checkout $any_committish^0 ;# detaches\n> \n> #1. These used to detach, but will create a local branch\n> \n> $ git checkout origin/next ;# as if with -t\n> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)\n\nAgreed, though I'm still in favour of a cleaner syntax for explicit\ndetaching. (Cleaner in the sense that ^0 is documented as having a\ncompletely different purpose and only works by accident.)\n\n> #2. These are allowed only when unambiguous and there is no local branch yet.\n> \n> $ git checkout next ;# ok\n> $ git checkout frotz ;# ok (origin is not special)\n> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)\n\nI'm weakly leaning towards refusing all three, as the user should be\nrequired to explicitly say a remote branch should be involved.\n\n(Weakly because there's also a certain DWIM advantage to 'git checkout\nsometopic'...)\n\n> #3. These used to detach, but what should we do?\n> \n> $ git checkout v1.0.0 ;# detach, or refuse???\n\nRefuse, on the grounds that the main goal here is not detaching unless\nspecifically told to. (Having a branch called v1.0.0 is worse, as it\nwould just cause a lot of confusion and/or a refusal at the next\ncheckout.)\n\n> $ git checkout origin/master ;# detach, or refuse???\n\nThis seems to be the trickiest of them. Maybe check out 'master', to\nmake the process repeatable. Imagine, in your setting,\n\n git checkout origin/next ;# creates 'next' as with -t\n git checkout - ;# back\n git checkout origin/next ;# should go to 'next' again\n\nThen again, that would trade the confusion of detaching for the\nconfusion of not checking out the exact commit that the user\nspecified. Worse, 'next' could conceivably be tracking (as per\nbranch.next.merge) some entirely different branch, making the \"Your\nbranch is behind...\" message misleading.\n\n> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we\n> started refusing to detach in case #3, as people who want to detach can\n> always suffix ^0 or ~0 to make it a general committish.\n> \n> Did I cover all cases?\n\nSome that come to mind:\n\n#3a. Other refs apart from tags that currently detach:\n\n git fetch origin master ;# or even sillier, 'git fetch . master'\n git checkout FETCH_HEAD ;# used to detach; refuse?\n\n#3b. Full specifiers that currently detach:\n\n git checkout refs/heads/master ;# could eventually attach\n git checkout heads/master ;# same\n\n#0a. Should probably detach if the previous checkout was detached:\n\n git checkout - ;# detach if previous was detached?\n git checkout @{-1} ;# same\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"124832","messageId":"7vy6nfwssk.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"200910131051.47117.trast@student.ethz.ch","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T09:24:11Z","receivedAt":"2009-10-13T09:24:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n>> #0. These will stay as is:\n>> \n>> $ git checkout mine ;# switches to the branch\n>> $ git checkout $any_committish^0 ;# detaches\n>> \n>> #1. These used to detach, but will create a local branch\n>> \n>> $ git checkout origin/next ;# as if with -t\n>> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)\n>\n> Agreed, though I'm still in favour of a cleaner syntax for explicit\n> detaching. (Cleaner in the sense that ^0 is documented as having a\n> completely different purpose and only works by accident.)\n\nOh, ^0 was just one way to make sure a committish is not a refname. If\nyou have an abbreviated hexadecimal commit object name, that would also\ndetach, which should fall into category #0. Sorry for the omission.\n\n>> #2. These are allowed only when unambiguous and there is no local branch yet.\n>> \n>> $ git checkout next ;# ok\n>> $ git checkout frotz ;# ok (origin is not special)\n>> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)\n>\n> I'm weakly leaning towards refusing all three, as the user should be\n> required to explicitly say a remote branch should be involved.\n>\n> (Weakly because there's also a certain DWIM advantage to 'git checkout\n> sometopic'...)\n\nI thought this was the primary point of what Dscho has been advocating.\n\n>> #3. These used to detach, but what should we do?\n>> \n>> $ git checkout v1.0.0 ;# detach, or refuse???\n>\n> Refuse, on the grounds that the main goal here is not detaching unless\n> specifically told to. (Having a branch called v1.0.0 is worse, as it\n> would just cause a lot of confusion and/or a refusal at the next\n> checkout.)\n>\n>> $ git checkout origin/master ;# detach, or refuse???\n>\n> This seems to be the trickiest of them. Maybe check out 'master', to\n> make the process repeatable. Imagine, in your setting,\n>\n> git checkout origin/next ;# creates 'next' as with -t\n> git checkout - ;# back\n> git checkout origin/next ;# should go to 'next' again\n>\n> Then again, that would trade the confusion of detaching for the\n> confusion of not checking out the exact commit that the user\n> specified. Worse, 'next' could conceivably be tracking (as per\n> branch.next.merge) some entirely different branch, making the \"Your\n> branch is behind...\" message misleading.\n\nAs I said already in the thread, I think that is a misguided attempt to\nhalf-hide the fact that there are origin/next (tracking branch) and next\n(a fork of it), that are two separate entities. It is misguided because\nthe user needs to understand and take advantage of the distinction to do\nanything; in other words, it is not even an unnecessary complexity.\n\nSo I am very doubtful about the benefit of checking out 'master' when\nthe user explicitly tells us to check out 'origin/master', only because\nthe former forked from the latter.\n\n> Some that come to mind:\n>\n> #3a. Other refs apart from tags that currently detach:\n>\n> git fetch origin master ;# or even sillier, 'git fetch . master'\n> git checkout FETCH_HEAD ;# used to detach; refuse?\n\n> #3b. Full specifiers that currently detach:\n>\n> git checkout refs/heads/master ;# could eventually attach\n> git checkout heads/master ;# same\n\nI'd throw both of these into category #3.\n\nAnything that is valid \"ref\" (i.e. what dwim_ref() groks) that is not\na remote tracking branch (which creates a corresponding local branch)\ncan refuse to avoid unintended detachment by newbies.\n\n> #0a. Should probably detach if the previous checkout was detached:\n>\n> git checkout - ;# detach if previous was detached?\n> git checkout @{-1} ;# same\n\nPerhaps.\n\nSo to recap, \"git checkout $token\" would:\n\n * If dwim_ref() groks $token, and\n\n - if it resolves to refs/heads/*, that is checking out a local branch;\n\n - if it resolves to refs/remotes/*, and if there is no corresponding\n local branch, create one forked from there, as if -t was given;\n\n - everything else we used to detach, but we refuse in 1.7.0, to make it\n harder for newbies to detach.\n\n * If check_ref_format() is happy with $token, get_sha1() does not grok\n $token, and there is only one ref of the form refs/remotes/$o/$token\n then we pretend as if -t $o/$token was given and create a local branch\n $token forked from it.\n\n * Otherwise, we always detach.\n\nNote that \"checkout -\" and \"checkout @{-4}\" are part of dwim_ref() family.\n"},{"id":"124833","messageId":"4AD44911.6070902@viscovery.net","threadId":"21136","inReplyTo":"7vljjf226t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-10-13T09:32:01Z","receivedAt":"2009-10-13T09:32:01Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> #1. These used to detach, but will create a local branch\n> \n> $ git checkout origin/next ;# as if with -t\n> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)\n\nIf I did 'git checkout origin/next' last week, I will already have a\nbranch next. What should happen if I do it again today?\n\nI think that it should DWIM: If last week's next fast-fowards to this\nweek's origin/next (*and* next is the branch that tracks origin/next),\nthen the fast foward should happen. Otherwise 'git checkout origin/next'\nshould fail.\n\nThis way, if I built on last week's next, I will be notified; but if I\nonly want to browse history, then I won't be impeded by the existence of next.\n\n-- Hannes\n"},{"id":"124864","messageId":"alpine.LNX.2.00.0910131358000.32515@iabervon.org","threadId":"21136","inReplyTo":"7vljjf226t.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-13T18:39:51Z","receivedAt":"2009-10-13T18:39:51Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 13 Oct 2009, Junio C Hamano wrote:\n\n> Thomas Rast writes:\n> \n> >> Or can't you go the other way, say\n> >> \n> >> \tgit checkout -t $remote_tracking\n> >> \n> >> to create a local branch forking from the named remote tracking branch?\n> >\n> > Sure, but we already have that and we still failed to fix the users,\n> > so FWIW, I think Dscho's right and we should try fixing the UI next.\n> \n> What it means is that -t was a broken attempt to help the users at the UI\n> level, and I can surely see that.\n> \n> So we need the set of new rules, say, for 1.7.0 release. A strawman?\n> \n> Assume that these are the only refs that exist:\n> \n> refs/remotes/origin/{master,next,nitfol}\n> refs/remotes/xyzzy/{frotz,nitfol}\n> refs/heads/master\n> refs/tags/v1.0.0\n> \n> #0. These will stay as is:\n> \n> $ git checkout mine ;# switches to the branch\n> $ git checkout $any_committish^0 ;# detaches\n> \n> #1. These used to detach, but will create a local branch\n> \n> $ git checkout origin/next ;# as if with -t\n> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)\n>\n> #2. These are allowed only when unambiguous and there is no local branch yet.\n> \n> $ git checkout next ;# ok\n> $ git checkout frotz ;# ok (origin is not special)\n> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)\n> \n> #3. These used to detach, but what should we do?\n> \n> $ git checkout v1.0.0 ;# detach, or refuse???\n> $ git checkout origin/master ;# detach, or refuse???\n> \n> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we\n> started refusing to detach in case #3, as people who want to detach can\n> always suffix ^0 or ~0 to make it a general committish.\n\nI suspect that a very common pattern for people who follow trees for \ntesting and such or who only develop in topic branches is:\n\n$ git clone ...\n$ git checkout origin/next\n$ git fetch origin\n$ git checkout origin/next\n\nFor people who use topic branches extensively:\n\n$ git fetch origin\n$ git checkout origin/next\n(test, find issues, maybe make changes)\n$ git checkout -b topic\n$ git commit\n(send changes)\n\nSome people (IIRC, including Linus):\n\n$ git checkout origin/next\n(work)\n$ git commit\n$ git checkout -b topic\n\nIn all of these cases, the user will get a misleading \"next\" local branch; \nin Linus's case, this branch ends up with commits from a topic branch.\n\nFor that matter, even the intended user would have problems with your \nsuggestion:\n\n$ git clone ...\n\n$ git checkout origin/next\n(do some next stuff)\n$ git checkout origin/master\n(do some master stuff)\n$ git checkout origin/next\n\nOn the second cycle, either git refuses or does something actively \nconfusing to this user, and the user has to learn the difference between \nlocal branches and remote branches on the *second* cycle. IMHO, it's much \nbetter to make users learn things at the point when they don't think they \nknow how to use the system, rather than when they think they understand it \nand are just trying to get things done.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"124892","messageId":"7vljjfuibr.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"alpine.LNX.2.00.0910131358000.32515@iabervon.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T20:53:12Z","receivedAt":"2009-10-13T20:53:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> I suspect that a very common pattern for people who follow trees for \n> testing and such or who only develop in topic branches is:\n> ...\n> << many issues with this kind of DWIM omitted >>\n> ...\n> On the second cycle, either git refuses or does something actively \n> confusing to this user, and the user has to learn the difference between \n> local branches and remote branches on the *second* cycle. IMHO, it's much \n> better to make users learn things at the point when they don't think they \n> know how to use the system, rather than when they think they understand it \n> and are just trying to get things done.\n\nYeah, and I think J6t pointed out the same issue.\n\nI think it tells us something, after some of \"the most trusted Git\ncontributors\" thought \"really long and hard, and making sure to take\nuser-friendliness into account at least as much as simplicity of\nimplementation\", they are getting to the same conclusion that this\nparticular DWIMery is a misguided attempt to be helpful without really\nhelping but rather hurting the users.\n\nI will stop trying to come up with a strawman for other people's itch that\nI do not agree to begin with, at least for now. I will still look at\nconcrete and workable proposals from other people, though.\n"},{"id":"124897","messageId":"alpine.DEB.1.00.0910132302380.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"7vy6nfwssk.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-13T21:20:28Z","receivedAt":"2009-10-13T21:20:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Oct 2009, Junio C Hamano wrote:\n\n> Thomas Rast writes:\n> \n> [this was probably quoted from Junio, Dscho doesn't have time to go back \n> and check, but then, this was not specified in the quoted mail]\n>\n> >> #2. These are allowed only when unambiguous and there is no local branch yet.\n> >> \n> >> $ git checkout next ;# ok\n> >> $ git checkout frotz ;# ok (origin is not special)\n> >> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)\n> >\n> > I'm weakly leaning towards refusing all three, as the user should be\n> > required to explicitly say a remote branch should be involved.\n> >\n> > (Weakly because there's also a certain DWIM advantage to 'git checkout\n> > sometopic'...)\n> \n> I thought this was the primary point of what Dscho has been advocating.\n\nTo be honest, I was not advocating anything except being more open to \nusers' problems, because we _did_ grow a large user base, way beyond the \nLinux developers (whom we can always harrass and tell to RTFM).\n\nJust to re-add my well-known stance: consistency is a good thing. So if \nthings are ambiguous, we can be consistent in saying so and refusing to \nDWIM. And if things are _not_ ambiguous, we can be consistent in just \nDWIMming what the user most probably meant.\n\nIf the user just typed random things in the hope that it works, we cannot \ndo anything about it anyway.\n\nSo in my opinion, we should DWIM \"git checkout $X\" to mean \"git checkout \n-b $X refs/remotes/$REMOTE/$X\" when there is no ref $X, refs/heads/$X and \nno other refs/remotes/$OTHER/$X.\n\nLikewise \"git checkout $REMOTE/$X\".\n\nBut, in my opinion, if there is refs/heads/$X and refs/remotes/origin/$X, \nand the user says \"git checkout origin/$X\", we should tell the user that \nthere are the options to checkout $X and origin/$X^0 (the latter only if \nthe user really intended to detach her HEAD), but not try to DWIM \nanything.\n\nIMHO it is obvious that Hannes' suggestion to fast-forward $X and check it \nout in said scenario has some benefits in certain situations, but dramatic \ndownsides in others.\n\nBut I need to drive some very important point home in this thread: 1.7.0 \nwas announced to break some old-time habits in favor of a better \nuser-interface. We _need_ to use this opportunity fully.\n\nEven if that means that a few fingers have to be retrained. Because \nretraining a few for the benefit of an easier time with the many others \nis Just Worth It.\n\nOr in other words: logic clearly dictates that the needs of the many \noutweigh the needs of the few.\n\nCiao,\nDscho\n\nP.S.: In case certain persons, ahem, think that I am applying the \"Many \nOutweigh Few\" principle to the time involved in top-posting and \n\"forgetting\" to cut quoted text to what is actually addressed: yes, you \ncould not be more correct. And I no longer believe that this goes without \nsaying.\n"},{"id":"124899","messageId":"alpine.LNX.2.00.0910131654270.32515@iabervon.org","threadId":"21136","inReplyTo":"7vljjfuibr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-10-13T21:31:46Z","receivedAt":"2009-10-13T21:31:46Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 13 Oct 2009, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > I suspect that a very common pattern for people who follow trees for \n> > testing and such or who only develop in topic branches is:\n> > ...\n> > << many issues with this kind of DWIM omitted >>\n> > ...\n> > On the second cycle, either git refuses or does something actively \n> > confusing to this user, and the user has to learn the difference between \n> > local branches and remote branches on the *second* cycle. IMHO, it's much \n> > better to make users learn things at the point when they don't think they \n> > know how to use the system, rather than when they think they understand it \n> > and are just trying to get things done.\n> \n> Yeah, and I think J6t pointed out the same issue.\n> \n> I think it tells us something, after some of \"the most trusted Git\n> contributors\" thought \"really long and hard, and making sure to take\n> user-friendliness into account at least as much as simplicity of\n> implementation\", they are getting to the same conclusion that this\n> particular DWIMery is a misguided attempt to be helpful without really\n> helping but rather hurting the users.\n> \n> I will stop trying to come up with a strawman for other people's itch that\n> I do not agree to begin with, at least for now. I will still look at\n> concrete and workable proposals from other people, though.\n\nI personally think that the real issue is that our \"detached HEAD\" message \nis still too scary, and what we really want is to issue the scary message \nwhen using \"git commit\" to move a detached HEAD from what was checked out \nto a new commit. So:\n\n$ git checkout origin/next\n(friendly message telling you you're browsing history)\n$ git commit\n(scary message telling you you're not on any branch)\n$ git commit\n(one line message like usual, except \"detached HEAD\" instead of branch \nname)\n\nThis still makes sure that you get the scary message before you could lose \ntrack of your work, but only gives it to you at the point where there's a \ncommit that's in your HEAD and nowhere else.\n\nThe other thing that I think would be nice is:\n\n$ git checkout origin/next\n$ git fetch origin\n$ git checkout !! (probably not a good syntax)\n\nThat is, expand \"!!\" to the string used to detach HEAD, and expand it \nagain now. (Of course, something would have to be done if you did \"git \ncheckout HEAD^1\" before, or \"git checkout !!^1\".) This is related in that \nI think the scary message should happen when \"git commit\" sees this stored \nstring and clears it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"124906","messageId":"20091013215751.GA12603@coredump.intra.peff.net","threadId":"21136","inReplyTo":"alpine.LNX.2.00.0910131654270.32515@iabervon.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-13T21:57:52Z","receivedAt":"2009-10-13T21:57:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 13, 2009 at 05:31:46PM -0400, Daniel Barkalow wrote:\n\n> I personally think that the real issue is that our \"detached HEAD\" message \n> is still too scary, and what we really want is to issue the scary message \n> when using \"git commit\" to move a detached HEAD from what was checked out \n> to a new commit. So:\n\nThis has been discussed before (I happen to agree with you, but you\nprobably want to address other comments in the thread):\n\n http://thread.gmane.org/gmane.comp.version-control.git/38201/focus=38213\n\n-Peff\n"},{"id":"124905","messageId":"7vaazvt0pk.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910132302380.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T21:59:03Z","receivedAt":"2009-10-13T21:59:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> So in my opinion, we should DWIM \"git checkout $X\" to mean \"git checkout \n> -b $X refs/remotes/$REMOTE/$X\" when there is no ref $X, refs/heads/$X and \n> no other refs/remotes/$OTHER/$X.\n>\n> Likewise \"git checkout $REMOTE/$X\".\n>\n> But, in my opinion, if there is refs/heads/$X and refs/remotes/origin/$X, \n> and the user says \"git checkout origin/$X\", we should tell the user that \n> there are the options to checkout $X and origin/$X^0 (the latter only if \n> the user really intended to detach her HEAD), but not try to DWIM \n> anything.\n\nI am somewhat unhappy with that kind of inconsistent DWIMery.\n\nNaively I would agree that it would be nice if \"git checkout origin/next\"\n(or \"next\" when no other remotes/*/next exists) were DWIMmed as \"git\ncheckout -t -b next origin/next\". But the way we _define_ that particular\nDWIMmery and the way it appears to an uninitiated would be different.\n\nWe define this DWIMmery as s|^(.*)/([^/]*)$|-t -b $2 $1/$2|; iow, when the\nuser types \"origin/next\" and other coniditions hold, we pretend as if the\nuser typed \"-b next origin/next\". But it would give an incorrect\nimpression to an end user \"Ah, when my upstream project has next branch, I\ncan check it out with origin/next (or next).\" But when the user wants to\nwork further on 'next' by running \"git checkout origin/next\" the next day,\nwe say \"Uh oh, that is ambiguous and we won't DWIM,\" which is technically\nand implementation wise correct, but breaks the misconception the user\nformed with your earlier DWIMmery. I suspect that the user will be better\noff if we do not give a wrong impression in the first place. If any\nDWIMmery gave a conception different from the following four points, that\nDWIMmery is actively hurting the users:\n\n * You clone and get copies of where the other end has its branches;\n\n * You do all your work on your local branches;\n\n * You may incorporate what the other end further did by merging from the\n tracking branch from it;\n\n * You update the other end by pushing what you did on your local branches.\n\nNow, the conclusion of the above embodied in the _current_ UI is:\n\n * To start your branch to build on what the other end did, you fork your\n local branch at the commit the other end left off, and make sure it builds\n on that tracking branch, with\n\n git checkout -t -b next origin/next\n\n * Since \"-t -b $2 $1/$2\" often appears as a pattern, you can say \"-t $1/$2\"\n and we DWIM as if you said \"-t -b $2 $1/$2\".\n\nI do not think loosening the DWIMmery so that \"$1/$2\" is DWIMmed to the\nabove would help users. If the current DWIM is not helping the users\nunderstand the first four points and instead encouraging an incorrect\npicture of how the world works, the new DWIMmery would be just as bad, if\nnot worse.\n\n> IMHO it is obvious that Hannes' suggestion to fast-forward $X and check it \n> out in said scenario has some benefits in certain situations, but dramatic \n> downsides in others.\n\nYes.\n\n> But I need to drive some very important point home in this thread: 1.7.0 \n> was announced to break some old-time habits in favor of a better \n> user-interface. We _need_ to use this opportunity fully.\n>\n> Even if that means that a few fingers have to be retrained. Because \n> retraining a few for the benefit of an easier time with the many others \n> is Just Worth It.\n\nAbsolutely. My point is that this particular DWIMmery would _NOT_ be a\nbetter user interface. Not for 1.7.0, not for any other release. It\nwould not help the users to form a clear world model git offers and that\nactively hurts them.\n"},{"id":"124907","messageId":"20091013220640.GB12603@coredump.intra.peff.net","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910132302380.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-13T22:06:40Z","receivedAt":"2009-10-13T22:06:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 13, 2009 at 11:20:28PM +0200, Johannes Schindelin wrote:\n\n> So in my opinion, we should DWIM \"git checkout $X\" to mean \"git checkout \n> -b $X refs/remotes/$REMOTE/$X\" when there is no ref $X, refs/heads/$X and \n> no other refs/remotes/$OTHER/$X.\n\nThe similar suggestion that is less magical is to say something like\n\"there is no $X; maybe you meant $REMOTE/$X?\". Is there a reason not to\nphase in the behavior, to make sure it is not doing unexpected things?\nIn other words:\n\n 1. In v1.6.6, find all error-correcting candidates and print them as\n a suggestion (similar to what we do with \"git foo\").\n\n 2. Then, if we all agree that it seems to be producing sane results,\n the next step is to turn the unambiguous cases into a DWIM (and\n leave the ambiguous ones with the \"did you mean?\" message).\n\nBecause right now I think there are a lot of hypothetical \"maybe it\nwould be less convenient or more confusing in this instance\", but we\ndon't have any data on how often those instances occur, or how actual\nusers might react. So doing step (1) would be a way of collecting some\nof that data (will users say \"stupid git, if you knew what I wanted, why\ndidn't you just do it?\" or \"stupid git, your suggestion is just\nconfusing me!\").\n\n-Peff\n"},{"id":"124909","messageId":"20091013223821.GA15814@atjola.homenet","threadId":"21136","inReplyTo":"alpine.LNX.2.00.0910131654270.32515@iabervon.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-10-13T22:38:21Z","receivedAt":"2009-10-13T22:38:21Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.10.13 17:31:46 -0400, Daniel Barkalow wrote:\n> The other thing that I think would be nice is:\n> \n> $ git checkout origin/next\n> $ git fetch origin\n> $ git checkout !! (probably not a good syntax)\n> \n> That is, expand \"!!\" to the string used to detach HEAD, and expand it \n> again now. (Of course, something would have to be done if you did \"git \n> checkout HEAD^1\" before, or \"git checkout !!^1\".) This is related in that \n> I think the scary message should happen when \"git commit\" sees this stored \n> string and clears it.\n\nThat sounds somewhat like the \"git up\" hack I've shown here:\nhttp://article.gmane.org/gmane.comp.version-control.git/130050\n\nIn #git, Dscho even suggested that \"git pull\" could do that kind of\nDWIMmery while on a detached HEAD that waas reached by checking out a remote\ntracking branch. I'm undecided about that, because real merges/rebases\ncould make it easier to lose work, as opposed to the \"fast-forward only\"\nbehaviour I had in mind for that \"git up\" thing. Though of course, the\n\"git pull\" DWIMmery for a detached HEAD could simply refuse to do\nanything but a fast-forward.\n\nOverall, I'm starting to think that improving the \"work with a detached\nHEAD\" area might be more worthwhile than adding DWIMmery that tries to\ncompletely avoid a detached HEAD.\n\nThis could include DWIMmery like the \"git up\"/\"git pull\" stuff, and\nimproved security checks, like checking that leaving a detached HEAD\ndoesn't \"lose\" any commits to the reflog. So checkout could do\nsomething like \"git rev-list HEAD --not --all\" (or does --all include\nHEAD?) and complain if there's something to be \"lost\".\n\nBjörn\n"},{"id":"124911","messageId":"7vhbu2syi6.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"20091013215751.GA12603@coredump.intra.peff.net","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-13T22:46:41Z","receivedAt":"2009-10-13T22:46:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Oct 13, 2009 at 05:31:46PM -0400, Daniel Barkalow wrote:\n>\n>> I personally think that the real issue is that our \"detached HEAD\" message \n>> is still too scary, and what we really want is to issue the scary message \n>> when using \"git commit\" to move a detached HEAD from what was checked out \n>> to a new commit. So:\n>\n> This has been discussed before (I happen to agree with you, but you\n> probably want to address other comments in the thread):\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/38201/focus=38213\n\nI just re-read the discussion again (thanks for a useful pointers). I\nmostly agree with everything said in the thread and obviously agree with\nits conclusion, but one thing I noticed that everybody (who _was_ a git\nexpert) in the thread was assuming bothered me somewhat.\n\nIn this sequence:\n\n 1$ git checkout $commit_name_that_is_not_a_local_branch\n 2$ git commit; hack; hack; hack;...\n 3$ git checkout $branch_name\n\nStep #1 is where the HEAD is detached. It is correct to argue that\ndetached HEAD is a different state and we should inform unsuspecting\nusers, which we do.\n\nStep #2 is where a commit that is not connected to any ref is made.\n\nStep #3 is where the state built in the detached HEAD \"branch\" vanishes\ninto lost-found.\n\nThe experts argued that #3 is where it is dangerous, and while it is\ntechnically correct, an unsuspecting non-expert would not even _know_ that\nnothing dangerous is happening while in step #2.\n\nIf the commit name used in step #1 were \"v1.0.0\", and if the user while in\nstep #2 ran \"gitk v1.0.0\" (or \"git log v1.0.0\"), he will be confused by\nnot seeing the recent commits. The distinction between \"detached HEAD\"\nand being on a branch needs to be understood to appreciate this (and taken\nadvantage of, when running e.g. \"git show-branch v1.0.0 HEAD\").\n\nWay before step #3, such a user, even though technically not in any danger\nyet, would be confused and panic: \"I wanted to fix something in the 1.0.0\nrelease, but where did my fix go?\"\n\nThe current message in step #1 reads like this:\n\n $ git checkout origin/next\n Note: moving to 'origin/next' which isn't a local branch\n If you want to create a new branch from this checkout, you may do so\n (now or later) by using -b with the checkout command again. Example:\n git checkout -b \n HEAD is now at 9ecb2a7... Merge branch 'maint'\n\nAnd perhaps for people who do not understand the second point in the\nfour-point list [*1*] I showed earlier in the thread, \"If you want to\ncreate a new branch\" may not be descriptive enough, as a sight-seer and an\noccasional typofixer, the user does not know what branch is good for to\nbegin with, and would not be able to tell if s/he even \"wants to create\"\none. Perhaps it would help more if we reworded three lines after \"Note:\"\nwith something like:\n\n To keep the history of commits you will build from now on in a branch,\n you may want to do \"git checkout -b \" now.\n\nand customize the \"in a branch\" and part if the checkout\nwas given a remote tracking branch and the corresponding local branch does\nnot yet exist, e.g. in the above example:\n\n To keep the history of commits you will build from now on in 'next'\n branch, you may want to do \"git checkout -b next\" now.\n\n\n[Footnote]\n\n*1* The world model in which a git user works is:\n\n * You clone and get copies of where the other end has its branches;\n\n * You do all your work on your local branches;\n\n * You may incorporate what the other end further did by merging from the\n tracking branch from it;\n\n * You update the other end by pushing what you did on your local branches.\n\nI do not think you can nor should hide them from the user [*2*].\n\n*2* We had to repeat \"don't hide but teach\" many times until it finally\nsank in for another essential thing in the git world model. I hope we do\nnot have to do the same repeating for the above four points. Luckily we\ndo not have to repeat \"don't hide but teach\" about the index anymore these\ndays.\n"},{"id":"124912","messageId":"alpine.DEB.1.00.0910140108110.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"7vhbu2syi6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-13T23:16:45Z","receivedAt":"2009-10-13T23:16:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Oct 2009, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > On Tue, Oct 13, 2009 at 05:31:46PM -0400, Daniel Barkalow wrote:\n> >\n> >> I personally think that the real issue is that our \"detached HEAD\" message \n> >> is still too scary, and what we really want is to issue the scary message \n> >> when using \"git commit\" to move a detached HEAD from what was checked out \n> >> to a new commit.\n> >\n> > This has been discussed before (I happen to agree with you, but you\n> > probably want to address other comments in the thread):\n> >\n> > http://thread.gmane.org/gmane.comp.version-control.git/38201/focus=38213\n> \n> I just re-read the discussion again (thanks for a useful pointers). I\n> mostly agree with everything said in the thread and obviously agree with\n> its conclusion, but one thing I noticed that everybody (who _was_ a git\n> expert) in the thread was assuming bothered me somewhat.\n\nWe can of course continue to this public wanking session in our nice \nlittle circle here on git@vger, fully aware that real users will not dare \nto interrupt us.\n\nIn the alternative, we can go out into the world (you know, that thing \nbehind the computer screen?) and ask somebody who has _not_ been exposed \nto Git for _4 years_ (like most of you!) just how hard it is to work with \nGit.\n\nLet me tell you this from my experience: the least likely answer is \"the \nmessages are too scary\". Invariably, the answer I get is \"it is totally \nunintuitive\". Often followed by \"I tell Git to do something \nstraight-forward, and it refuses to do it.\"\n\nMaybe we should just admit that we are no user interface designers, so one \ncannot expect miracles from us in that respect. And first and foremost, \nwe should not pretend to ourselves that we are good at user interfaces, \nbecause we have a track record of sucking in that area. Big time.\n\nCiao,\nDscho\n\nP.S.: As somebody mentioned already, it is time to fix the tools, not our \nusers.\n"},{"id":"124913","messageId":"alpine.DEB.1.00.0910140117280.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"20091013220640.GB12603@coredump.intra.peff.net","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-13T23:22:26Z","receivedAt":"2009-10-13T23:22:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 13 Oct 2009, Jeff King wrote:\n\n> On Tue, Oct 13, 2009 at 11:20:28PM +0200, Johannes Schindelin wrote:\n> \n> > So in my opinion, we should DWIM \"git checkout $X\" to mean \"git checkout \n> > -b $X refs/remotes/$REMOTE/$X\" when there is no ref $X, refs/heads/$X and \n> > no other refs/remotes/$OTHER/$X.\n> \n> The similar suggestion that is less magical is to say something like\n> \"there is no $X; maybe you meant $REMOTE/$X?\".\n\nAt some point, trying to educate the user is not helpful but annoying. If \nGit already knows what I want, why does it not do it already? _That_ is \nthe question I already hear in my ears.\n\n> Is there a reason not to phase in the behavior, to make sure it is not \n> doing unexpected things?\n\nSure, I have nothing against that. But just insisting on the current \nbehavior, or on some behavior that is not helpful at all, well, is not \nreally clever.\n\nNote that I am fully aware that my \"git checkout -t origin/master\" DWIMery \nbackfired quite badly. So I am in the same boat.\n\n> In other words:\n> \n> 1. In v1.6.6, find all error-correcting candidates and print them as\n> a suggestion (similar to what we do with \"git foo\").\n> \n> 2. Then, if we all agree that it seems to be producing sane results,\n> the next step is to turn the unambiguous cases into a DWIM (and\n> leave the ambiguous ones with the \"did you mean?\" message).\n> \n> Because right now I think there are a lot of hypothetical \"maybe it\n> would be less convenient or more confusing in this instance\", but we\n> don't have any data on how often those instances occur, or how actual\n> users might react.\n\nOh, I do not want to spam the list with user experiences. But I do have \nnot only a faint idea how users react. Thankyouverymuch.\n\n> So doing step (1) would be a way of collecting some of that data (will \n> users say \"stupid git, if you knew what I wanted, why didn't you just do \n> it?\" or \"stupid git, your suggestion is just confusing me!\").\n\nI disagree. It is not about collecting data. We will not get any \nfeedback from the affected people. You know that, I know that.\n\nThe step (1) would help in the way that it is a smoother transition.\n\nCiao,\nDscho\n"},{"id":"124916","messageId":"76718490910131805o42e8321ama85b90b7e901dc7d@mail.gmail.com","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910140117280.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-10-14T01:05:54Z","receivedAt":"2009-10-14T01:05:54Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Oct 13, 2009 at 7:22 PM, Johannes Schindelin\n wrote:\n> At some point, trying to educate the user is not helpful but annoying.  If\n> Git already knows what I want, why does it not do it already?  _That_ is\n> the question I already hear in my ears.\n\nModify checkout so that the first commit while detached automatically\ncreates a branch. Perhaps the name is derived from the branch point,\nor the user is prompted for a name.\n\nThis doesn't help with the original problem, which was that a user\nattempted to checkout refs/remotes/origin/ by just saying 'git\ncheckout ' which I happen to think should work. A lot of what I\nkeep hearing in this thread seems to be in the vein of the perfect\nbeing the enemy of the good.\n\nThat rambled a bit. Sorry.\n\nj.\n"},{"id":"124921","messageId":"7vfx9modqf.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"76718490910131805o42e8321ama85b90b7e901dc7d@mail.gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-14T03:28:56Z","receivedAt":"2009-10-14T03:28:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> This doesn't help with the original problem, which was that a user\n> attempted to checkout refs/remotes/origin/ by just saying 'git\n> checkout ' which I happen to think should work. A lot of what I\n> keep hearing in this thread seems to be in the vein of the perfect\n> being the enemy of the good.\n\nI do not think there is \"perfect\" nor \"good\" anywhere in this. It is just\nthe proposals were either not well thought out, were not presented well,\nor were misunderstood, or a bit of all.\n\nWhen you do not have local \"frotz\" branch, and do have cloned/fetched from\nthe origin that has \"frotz\" branch, I am actually Ok with this\n\n $ git checkout frotz [--]\n\nto do an equivalent of:\n\n $ git checkout -t -b frotz origin/frotz\n\nI do not have problem with this _particular_ DWIMmery. It will not break\npeople's expectations, other than \"asking to check out non-existing ref\nshould fail\". That expectation might be logical, but I do not think it is\nuseful.\n\nAnother reason I won't have problem with this one is that perhaps after\ncreating a few more commits, the next day when the user does the same\n\n $ git checkout frotz\n\nwhat will be shown is the _local_ frotz branch. Nowhere in this sequence\nthere is any room to mistake that you somehow checked out a branch owned\nby somebody else (namely, origin). You started by auto-creating your\nlocal branch, worked on it, and checked it out again the next day. In\nother words, this is really about a shorthand to create a new local branch\ncalled \"frotz\" when the commit that the branch should start from is\nclearly unambiguous.\n\nI have trouble with yours, on the other hand, which is to make\n\n $ git checkout origin/frotz\n $ git checkout v1.5.5\n\ninto\n\n $ git checkout -b frotz-47 origin/frotz\n $ git checkout -b v1.5.5-47 v1.5.5\n\n(replace -47 with whatever random string you would come up with to make it\nunique), as it _will_ break people's expectations, and the expected\nbehaviour to detach without polluting the local branch namespace for\nthe purpose of sightseeing happens to be a useful one.\n\nI also have issues with turning\n\n $ git checkout origin/frotz\n\ninto\n\n $ git checkout -b frotz origin/frotz\n\nonly when frotz does not exist locally. This will cause the \"next day\"\nproblem, and also by naming the remote tracking branch, gives a wrong\nimpression that this is about a remote branch. It should not be.\n\nPerhaps without touching the \"detached\" case at all, if we limit the scope\nof the change that comes out of this discussion to only one case, it might\nresult in a good trouble-free enhancement [*1*].\n\nThe new rule would be:\n\n \"git checkout $name\", when all of the following holds:\n\n - $name is a good name for a local branch (i.e. check-ref-format is\n happy);\n\n - No local branch of that name exists;\n\n - There is exactly one remote $remote that has $name branch; and\n\n - $name itself is not a good commit name (i.e. get_sha1() barfs)\n\n is a request to create a local branch $name, and the branch tracks the\n remote tracking branch found in the third condition [*2*].\n\nThe important point here is that this exception is _not_ about remote\ntracking branch but is about a rule to allow omitting -b to create and\ncheckout a local branch when the user's intent is clear that (1) he wants\nto create a new one named $name, and (2) he wants to create it starting at\nthe commit $remote/$name.\n\nSuch a change feels quite safe and I wouldn't be opposed to it.\n\nWe _could_ discuss extending the $name in the above rule to other kinds\n(tags and even arbitrary committish that may not even have a direct ref\npointing at it), but I think they are much more problematic.\n\n[Footnote]\n\n*1* Yes, I know I won't try to come with a strawman.\n\n*2* The fourth condition is to avoid taking \"origin/frotz\" when \"origin\"\nremote has \"frotz\" branch _and_ \"other\" remote has \"origin/frotz\" branch.\n\nThe remote chosen by the third condition would be \"other\" (because\n\"origin\" remote only has \"frotz\", and not \"origin/frotz\", the name is\nunique in the sense of the third condition). The fourth condition\nprevents this from happening, and forbids an explicit request to detach\nHEAD at one point (i.e. \"origin/frotz\") from triggering.\n"},{"id":"124924","messageId":"20091014043150.GB28795@coredump.intra.peff.net","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910140117280.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-14T04:31:50Z","receivedAt":"2009-10-14T04:31:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 14, 2009 at 01:22:26AM +0200, Johannes Schindelin wrote:\n\n> At some point, trying to educate the user is not helpful but annoying. If \n> Git already knows what I want, why does it not do it already? _That_ is \n> the question I already hear in my ears.\n\nI am not entirely convinced that the suggested behaviors will result in\nthat user response, or a different one (like \"why does git keep giving\nme bad advice?\"). Which is why I suggested data collection.\n\n> > So doing step (1) would be a way of collecting some of that data (will \n> > users say \"stupid git, if you knew what I wanted, why didn't you just do \n> > it?\" or \"stupid git, your suggestion is just confusing me!\").\n> \n> I disagree. It is not about collecting data. We will not get any \n> feedback from the affected people. You know that, I know that.\n\nI don't agree. You are already talking about users complaining about\ngit's interface. Isn't that feedback? How do you hear those complaints\nnow?\n\nI don't think they will come on the list and talk about it, but if we\nrelease a version of git that has differing behavior and give it some\ntime to be used in the wild, we _will_ get feedback in the form of\nblogs, complaints on other lists, word-of-mouth, etc.\n\nNow maybe that is not a good idea in this instance, because that sort of\nfeedback may take several versions to appear, and we are talking about a\npotential timetable of v1.7.0, which is probalby only two versions away.\n\n-Peff\n"},{"id":"124958","messageId":"200910141133.11386.trast@student.ethz.ch","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910140108110.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-14T09:33:09Z","receivedAt":"2009-10-14T09:33:09Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Johannes Schindelin wrote:\n> \n> Let me tell you this from my experience: the least likely answer is \"the \n> messages are too scary\". Invariably, the answer I get is \"it is totally \n> unintuitive\". Often followed by \"I tell Git to do something \n> straight-forward, and it refuses to do it.\"\n\n\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"124960","messageId":"200910141156.55536.trast@student.ethz.ch","threadId":"21136","inReplyTo":"200910131051.47117.trast@student.ethz.ch","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-14T09:56:54Z","receivedAt":"2009-10-14T09:56:54Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Thomas Rast wrote:\n> Junio C Hamano wrote:\n> > \n> > #1. These used to detach, but will create a local branch\n> > \n> > $ git checkout origin/next ;# as if with -t\n> > $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)\n> \n> Agreed, though I'm still in favour of a cleaner syntax for explicit\n> detaching. (Cleaner in the sense that ^0 is documented as having a\n> completely different purpose and only works by accident.)\n\nNot sure if it's too late in the thread, but after sleeping over it\nand re-reading (and the other developments in the thread) I'm not\nhappy with my earlier opinion any more. I think the DWIM part of it\nis a bad idea because of this:\n\n> > $ git checkout origin/master ;# detach, or refuse???\n> \n> This seems to be the trickiest of them. Maybe check out 'master', to\n> make the process repeatable. Imagine, in your setting,\n> \n> git checkout origin/next ;# creates 'next' as with -t\n> git checkout - ;# back\n> git checkout origin/next ;# should go to 'next' again\n> \n> Then again, that would trade the confusion of detaching for the\n> confusion of not checking out the exact commit that the user\n> specified. Worse, 'next' could conceivably be tracking (as per\n> branch.next.merge) some entirely different branch, making the \"Your\n> branch is behind...\" message misleading.\n\nSo I think we're now mixing up two different goals in this thread:\na) Stopping the users from hurting themselves by inadvertent detaching\nb) Helping the users by DWIMming local branches for them\n\nI'm all for (a), but (b) is much harder.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"124968","messageId":"m3k4yyfe1z.fsf@localhost.localdomain","threadId":"21136","inReplyTo":"200910141156.55536.trast@student.ethz.ch","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-10-14T10:46:01Z","receivedAt":"2009-10-14T10:46:01Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Thomas Rast writes:\n\n> So I think we're now mixing up two different goals in this thread:\n> a) Stopping the users from hurting themselves by inadvertent detaching\n> b) Helping the users by DWIMming local branches for them\n> \n> I'm all for (a), but (b) is much harder.\n\nPerhaps (b) should be protected by branch.autocreatelocal (similar to\nbranch.autosetupmerge and branch.autosetuprebase).\n\nAlso we should always print a message if we DWIM creating or checking\nout local branch equivalent to remote-tracking branch.\n\n\nAlso, why interactive checkout (checkout --interactive?) idea was\nabandoned?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"124970","messageId":"76718490910140549l4a6b4f60je64d1b71a1a33d1d@mail.gmail.com","threadId":"21136","inReplyTo":"7vfx9modqf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-10-14T12:49:53Z","receivedAt":"2009-10-14T12:49:53Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Oct 13, 2009 at 11:28 PM, Junio C Hamano wrote:\n> When you do not have local \"frotz\" branch, and do have cloned/fetched from\n> the origin that has \"frotz\" branch, I am actually Ok with this\n>\n>    $ git checkout frotz [--]\n>\n> to do an equivalent of:\n>\n>    $ git checkout -t -b frotz origin/frotz\n>\n> I do not have problem with this _particular_ DWIMmery.  It will not break\n> people's expectations, other than \"asking to check out non-existing ref\n> should fail\".  That expectation might be logical, but I do not think it is\n> useful.\n>\n> Another reason I won't have problem with this one is that perhaps after\n> creating a few more commits, the next day when the user does the same\n>\n>    $ git checkout frotz\n>\n> what will be shown is the _local_ frotz branch.  Nowhere in this sequence\n> there is any room to mistake that you somehow checked out a branch owned\n> by somebody else (namely, origin).  You started by auto-creating your\n> local branch, worked on it, and checked it out again the next day.  In\n> other words, this is really about a shorthand to create a new local branch\n> called \"frotz\" when the commit that the branch should start from is\n> clearly unambiguous.\n\nOkay, this is good, and I can work up a patch if no one beats me to the punch.\n\n> I have trouble with yours, on the other hand, which is to make\n>\n>    $ git checkout origin/frotz\n>    $ git checkout v1.5.5\n>\n> into\n>\n>    $ git checkout -b frotz-47 origin/frotz\n>    $ git checkout -b v1.5.5-47 v1.5.5\n\nI suggested no such thing, at least, I don't think I did. What I said was:\n\n---snip---\nModify checkout so that the first commit while detached automatically\ncreates a branch. Perhaps the name is derived from the branch point,\nor the user is prompted for a name.\n---snip---\n\nSo we'd only automatically create a new branch at commit time. But\nnever mind that, it was just a suggestion and I don't like it.\n\nWhat if instead we do something like this:\n\n$ git checkout v1.5.5\nNote: moving to 'v1.5.5' which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b \nHEAD is now at 1d2375d... GIT 1.5.5\n$ [edit foo.c]\n$ git add foo.c\n$ git commit -m \"edited some file\"\nCannot commit to v1.5.5. Please use git commit -b to specify\nthe name of a new branch to commit to, or use git commit --detach to\nforce a detached commit.\n\nSo we modify git to, by default, no longer allow creating a commit\nwhile detached or on a branch that cannot be committed to.\n\nj.\n"},{"id":"125010","messageId":"7veip5db7p.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"76718490910140549l4a6b4f60je64d1b71a1a33d1d@mail.gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-14T19:31:06Z","receivedAt":"2009-10-14T19:31:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jay Soffian writes:\n\n> What if instead we do something like this:\n>\n> $ git checkout v1.5.5\n> Note: moving to 'v1.5.5' which isn't a local branch\n> If you want to create a new branch from this checkout, you may do so\n> (now or later) by using -b with the checkout command again. Example:\n> git checkout -b \n> HEAD is now at 1d2375d... GIT 1.5.5\n> $ [edit foo.c]\n> $ git add foo.c\n> $ git commit -m \"edited some file\"\n> Cannot commit to v1.5.5. Please use git commit -b to specify\n> the name of a new branch to commit to, or use git commit --detach to\n> force a detached commit.\n>\n> So we modify git to, by default, no longer allow creating a commit\n> while detached or on a branch that cannot be committed to.\n\nI'd probably object to such a change if there is no easy way to turn it\noff per session (that means \"expert mode\" configuration variable, or a\ncommand line option per \"git commit\" invocation, are not a viable escape\nhatch), as I do it all the time, while reworking on an existing series.\nE.g.\n\n $ git checkout $(git merge-base master topic)\n $ work on redoing topic\n - cherry-picking parts from topic~$n\n - editing\n - committing\n $ git show-branch HEAD topic\n $ git branch -f topic\n\nis a very common sequence of how I personally work, at day-job and also\nwhile maintaining git itself.\n\nI probably would not mind such a change if I can say \"I am detaching now\nin order to build on a non-branch. Do not bother me with unwarranted and\nmisguided helpfulness until I am done\" once upfront when I perform the\nfirst checkout.\n"},{"id":"125163","messageId":"alpine.DEB.1.00.0910161346560.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"200910141133.11386.trast@student.ethz.ch","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-16T11:48:39Z","receivedAt":"2009-10-16T11:48:39Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Oct 2009, Thomas Rast wrote:\n\n> [On the other hand, some users appear unwilling to learn something new \n> because they \"just want to version control this\" or \"just need to make a \n> commit to this project\".]\n\nFrankly, if the choice is between \"I just want to make a commit to this \nproject\" and \"Then I'll not use version control at all\", I'd rather choose \nthe former.\n\nWhich is exactly what I did the other day, having to write a non-trivial \nscript to allow the user to do what he wants to do.\n\nCiao,\nDscho\n"},{"id":"125164","messageId":"200910161407.14832.trast@student.ethz.ch","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910161346560.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-16T12:07:13Z","receivedAt":"2009-10-16T12:07:13Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Wed, 14 Oct 2009, Thomas Rast wrote:\n> \n> > [On the other hand, some users appear unwilling to learn something new \n> > because they \"just want to version control this\" or \"just need to make a \n> > commit to this project\".]\n> \n> Frankly, if the choice is between \"I just want to make a commit to this \n> project\" and \"Then I'll not use version control at all\", I'd rather choose \n> the former.\n\nUsing your automatic gearbox analogy, I should point out that people\nstill spend significant amounts of time and money on learning how to\ndrive, despite the fact that learning the internals of the engine is\nno longer required.\n\nYet for some reason, the same people want computers to read their\nminds instead of learning how to operate (the more involved parts of)\nit.\n\n(Yeah, call me arrogant...)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"125267","messageId":"7vzl7pyvzl.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T07:58:06Z","receivedAt":"2009-10-18T07:58:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Actually, we should really think long and hard why we should not \n> automatically check out the local branch \"next\" in that case.\n\nWhile people were thinking long and hard, I've spent some quality time\nhaving fun with these patches, and realized that if we limit the scope of\nthe change to make sure that we only change the behaviour of a case where\nwe refused to do anything, this is not even something we need to think\nlong nor hard after all.\n\nAt least from the maintainer's point of view, that is.\n\nI on the other hand do agree that we need to think long and hard when it\ncomes to the matter of explaining this to the users, though. I couldn't\ncome up with a good (re-)ordering of the documentation to fit this new\n\"short-cut\" into the manpage.\n\nA three-patch series will follow shortly.\n"},{"id":"125268","messageId":"7veip1xhbk.fsf_-_@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"7vzl7pyvzl.fsf@alter.siamese.dyndns.org","subject":"[PATCH 1/3] check_filename(): make verify_filename() callable without dying","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T08:00:15Z","receivedAt":"2009-10-18T08:00:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Make it possible to invole the logic of verify_filename() to make sure the\npathname arguments are unambiguous without actually dying. The caller may\nwant to do something different.\n\nSigned-off-by: Junio C Hamano \n---\n cache.h | 1 +\n setup.c | 38 ++++++++++++++++++++------------------\n 2 files changed, 21 insertions(+), 18 deletions(-)\n\ndiff --git a/cache.h b/cache.h\nindex 96840c7..71a731d 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -396,6 +396,7 @@ extern const char *setup_git_directory_gently(int *);\n extern const char *setup_git_directory(void);\n extern const char *prefix_path(const char *prefix, int len, const char *path);\n extern const char *prefix_filename(const char *prefix, int len, const char *path);\n+extern int check_filename(const char *prefix, const char *name);\n extern void verify_filename(const char *prefix, const char *name);\n extern void verify_non_filename(const char *prefix, const char *name);\n \ndiff --git a/setup.c b/setup.c\nindex 029371e..f67250b 100644\n--- a/setup.c\n+++ b/setup.c\n@@ -61,6 +61,19 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)\n \treturn path;\n }\n \n+int check_filename(const char *prefix, const char *arg)\n+{\n+\tconst char *name;\n+\tstruct stat st;\n+\n+\tname = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;\n+\tif (!lstat(name, &st))\n+\t\treturn 1; /* file exists */\n+\tif (errno == ENOENT || errno == ENOTDIR)\n+\t\treturn 0; /* file does not exist */\n+\tdie_errno(\"failed to stat '%s'\", arg);\n+}\n+\n /*\n * Verify a filename that we got as an argument for a pathspec\n * entry. Note that a filename that begins with \"-\" never verifies\n@@ -70,18 +83,12 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)\n */\n void verify_filename(const char *prefix, const char *arg)\n {\n-\tconst char *name;\n-\tstruct stat st;\n-\n \tif (*arg == '-')\n \t\tdie(\"bad flag '%s' used after filename\", arg);\n-\tname = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;\n-\tif (!lstat(name, &st))\n+\tif (check_filename(prefix, arg))\n \t\treturn;\n-\tif (errno == ENOENT)\n-\t\tdie(\"ambiguous argument '%s': unknown revision or path not in the working tree.\\n\"\n-\t\t \"Use '--' to separate paths from revisions\", arg);\n-\tdie_errno(\"failed to stat '%s'\", arg);\n+\tdie(\"ambiguous argument '%s': unknown revision or path not in the working tree.\\n\"\n+\t \"Use '--' to separate paths from revisions\", arg);\n }\n \n /*\n@@ -91,19 +98,14 @@ void verify_filename(const char *prefix, const char *arg)\n */\n void verify_non_filename(const char *prefix, const char *arg)\n {\n-\tconst char *name;\n-\tstruct stat st;\n-\n \tif (!is_inside_work_tree() || is_inside_git_dir())\n \t\treturn;\n \tif (*arg == '-')\n \t\treturn; /* flag */\n-\tname = prefix ? prefix_filename(prefix, strlen(prefix), arg) : arg;\n-\tif (!lstat(name, &st))\n-\t\tdie(\"ambiguous argument '%s': both revision and filename\\n\"\n-\t\t \"Use '--' to separate filenames from revisions\", arg);\n-\tif (errno != ENOENT && errno != ENOTDIR)\n-\t\tdie_errno(\"failed to stat '%s'\", arg);\n+\tif (!check_filename(prefix, arg))\n+\t\treturn;\n+\tdie(\"ambiguous argument '%s': both revision and filename\\n\"\n+\t \"Use '--' to separate filenames from revisions\", arg);\n }\n \n const char **get_pathspec(const char *prefix, const char **pathspec)\n-- \n1.6.5.1.95.g09fbd\n"},{"id":"125269","messageId":"7vaazpxha4.fsf_-_@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"7vzl7pyvzl.fsf@alter.siamese.dyndns.org","subject":"[PATCH 2/3] DWIM \"git checkout frotz\" to \"git checkout -b frotz origin/frotz\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T08:01:07Z","receivedAt":"2009-10-18T08:01:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When 'frotz' is not a valid object name nor a tracked filename,\nwe used to complain and failed this command. When there is only\none remote that has 'frotz' as one of its tracking branches, we can\nDWIM it as a request to create a local branch 'frotz' forking from\nthe matching remote tracking branch.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-checkout.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++--\n 1 files changed, 57 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-checkout.c b/builtin-checkout.c\nindex d050c37..fb7e68a 100644\n--- a/builtin-checkout.c\n+++ b/builtin-checkout.c\n@@ -572,6 +572,40 @@ static int interactive_checkout(const char *revision, const char **pathspec,\n \treturn run_add_interactive(revision, \"--patch=checkout\", pathspec);\n }\n \n+struct tracking_name_data {\n+\tconst char *name;\n+\tchar *remote;\n+\tint unique;\n+};\n+\n+static int check_tracking_name(const char *refname, const unsigned char *sha1,\n+\t\t\t int flags, void *cb_data)\n+{\n+\tstruct tracking_name_data *cb = cb_data;\n+\tconst char *slash;\n+\n+\tif (prefixcmp(refname, \"refs/remotes/\"))\n+\t\treturn 0;\n+\tslash = strchr(refname + 13, '/');\n+\tif (!slash || strcmp(slash + 1, cb->name))\n+\t\treturn 0;\n+\tif (cb->remote) {\n+\t\tcb->unique = 0;\n+\t\treturn 0;\n+\t}\n+\tcb->remote = xstrdup(refname);\n+\treturn 0;\n+}\n+\n+static const char *unique_tracking_name(const char *name)\n+{\n+\tstruct tracking_name_data cb_data = { name, NULL, 1 };\n+\tfor_each_ref(check_tracking_name, &cb_data);\n+\tif (cb_data.unique)\n+\t\treturn cb_data.remote;\n+\tfree(cb_data.remote);\n+\treturn NULL;\n+}\n \n int cmd_checkout(int argc, const char **argv, const char *prefix)\n {\n@@ -630,8 +664,6 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\topts.new_branch = argv0 + 1;\n \t}\n \n-\tif (opts.track == BRANCH_TRACK_UNSPECIFIED)\n-\t\topts.track = git_branch_track;\n \tif (conflict_style) {\n \t\topts.merge = 1; /* implied */\n \t\tgit_xmerge_config(\"merge.conflictstyle\", conflict_style, NULL);\n@@ -655,6 +687,11 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t * With no paths, if is a commit, that is to\n \t * switch to the branch or detach HEAD at it.\n \t *\n+\t * With no paths, if is _not_ a commit, no -t nor -b\n+\t * was given, and there is a tracking branch whose name is\n+\t * in one and only one remote, then this is a short-hand\n+\t * to fork local from that remote tracking branch.\n+\t *\n \t * Otherwise shall not be ambiguous.\n \t * - If it's *only* a reference, treat it like case (1).\n \t * - If it's only a path, treat it like case (2).\n@@ -677,7 +714,20 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tif (get_sha1(arg, rev)) {\n \t\t\tif (has_dash_dash) /* case (1) */\n \t\t\t\tdie(\"invalid reference: %s\", arg);\n-\t\t\tgoto no_reference; /* case (3 -> 2) */\n+\t\t\tif (!patch_mode &&\n+\t\t\t opts.track == BRANCH_TRACK_UNSPECIFIED &&\n+\t\t\t !opts.new_branch &&\n+\t\t\t !check_filename(NULL, arg) &&\n+\t\t\t argc == 1) {\n+\t\t\t\tconst char *remote = unique_tracking_name(arg);\n+\t\t\t\tif (!remote || get_sha1(remote, rev))\n+\t\t\t\t\tgoto no_reference;\n+\t\t\t\topts.new_branch = arg;\n+\t\t\t\targ = remote;\n+\t\t\t\t/* DWIMmed to create local branch */\n+\t\t\t}\n+\t\t\telse\n+\t\t\t\tgoto no_reference;\n \t\t}\n \n \t\t/* we can't end up being in (2) anymore, eat the argument */\n@@ -715,6 +765,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t}\n \n no_reference:\n+\n+\tif (opts.track == BRANCH_TRACK_UNSPECIFIED)\n+\t\topts.track = git_branch_track;\n+\n \tif (argc) {\n \t\tconst char **pathspec = get_pathspec(prefix, argv);\n \n-- \n1.6.5.1.95.g09fbd\n"},{"id":"125270","messageId":"7v63adxh9a.fsf_-_@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"7vzl7pyvzl.fsf@alter.siamese.dyndns.org","subject":"[PATCH 3/3] git checkout --nodwim","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T08:01:37Z","receivedAt":"2009-10-18T08:01:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Porcelains may want to make sure their calls to \"git checkout\" will\nreliably fail regardless of the presense of random remote tracking\nbranches by the new DWIMmery introduced.\n\nLuckily all existing in-tree callers have extra checks to make sure they\nfeed local branch name when they want to switch, or they explicitly ask\nto detach HEAD at the given commit, so there is no need to add this option\nfor them.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-checkout.c | 4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-checkout.c b/builtin-checkout.c\nindex fb7e68a..6ec9b83 100644\n--- a/builtin-checkout.c\n+++ b/builtin-checkout.c\n@@ -616,6 +616,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \tstruct tree *source_tree = NULL;\n \tchar *conflict_style = NULL;\n \tint patch_mode = 0;\n+\tint dwim_new_local_branch = 1;\n \tstruct option options[] = {\n \t\tOPT__QUIET(&opts.quiet),\n \t\tOPT_STRING('b', NULL, &opts.new_branch, \"new branch\", \"branch\"),\n@@ -631,6 +632,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tOPT_STRING(0, \"conflict\", &conflict_style, \"style\",\n \t\t\t \"conflict style (merge or diff3)\"),\n \t\tOPT_BOOLEAN('p', \"patch\", &patch_mode, \"select hunks interactively\"),\n+\t\tOPT_SET_INT(0, \"nodwim\", &dwim_new_local_branch,\n+\t\t\t \"do not dwim local branch creation\", 0),\n \t\tOPT_END(),\n \t};\n \tint has_dash_dash;\n@@ -715,6 +718,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\t\tif (has_dash_dash) /* case (1) */\n \t\t\t\tdie(\"invalid reference: %s\", arg);\n \t\t\tif (!patch_mode &&\n+\t\t\t dwim_new_local_branch &&\n \t\t\t opts.track == BRANCH_TRACK_UNSPECIFIED &&\n \t\t\t !opts.new_branch &&\n \t\t\t !check_filename(NULL, arg) &&\n-- \n1.6.5.1.95.g09fbd\n"},{"id":"125273","messageId":"20091018193448.6117@nanako3.lavabit.com","threadId":"21136","inReplyTo":"7vaazpxha4.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/3] DWIM \"git checkout frotz\" to \"git checkout -b frotz origin/frotz\"","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-10-18T10:34:48Z","receivedAt":"2009-10-18T10:34:48Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano \n\n> When 'frotz' is not a valid object name nor a tracked filename,\n> we used to complain and failed this command. When there is only\n> one remote that has 'frotz' as one of its tracking branches, we can\n> DWIM it as a request to create a local branch 'frotz' forking from\n> the matching remote tracking branch.\n\nIn the subject you used 'git checkout -b frotz origin/frotz'. Did you forget to say '-t'?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"125274","messageId":"20091018120053.GA11391@atjola.homenet","threadId":"21136","inReplyTo":"20091018193448.6117@nanako3.lavabit.com","subject":"Re: [PATCH 2/3] DWIM \"git checkout frotz\" to \"git checkout -b frotz origin/frotz\"","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-10-18T12:00:53Z","receivedAt":"2009-10-18T12:00:53Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.10.18 19:34:48 +0900, Nanako Shiraishi wrote:\n> Quoting Junio C Hamano \n> \n> > When 'frotz' is not a valid object name nor a tracked filename,\n> > we used to complain and failed this command. When there is only\n> > one remote that has 'frotz' as one of its tracking branches, we can\n> > DWIM it as a request to create a local branch 'frotz' forking from\n> > the matching remote tracking branch.\n> \n> In the subject you used 'git checkout -b frotz origin/frotz'. Did you\n> forget to say '-t'?\n\nHm, the DWIMmery only triggers when opts.track is\nBRANCH_TRACK_UNSPECIFIED, i.e. -t was not used. And it doesn't change\nopts.track when it DWIMs, so it respects branch.autosetupmerge, which\nwould be overriden by -t. So it seems correct that -t is not in there.\n\nBjörn\n"},{"id":"125275","messageId":"81b0412b0910180540u7030c22br7efcaf7f51df771d@mail.gmail.com","threadId":"21136","inReplyTo":"7v63adxh9a.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-10-18T12:40:21Z","receivedAt":"2009-10-18T12:40:21Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Sun, Oct 18, 2009 at 10:01, Junio C Hamano wrote:\n> +               OPT_SET_INT(0, \"nodwim\", &dwim_new_local_branch,\n> +                           \"do not dwim local branch creation\", 0),\n\nIsn't there a special negation support for --no-something in parse-options?\n"},{"id":"125289","messageId":"7v7huspjg0.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"81b0412b0910180540u7030c22br7efcaf7f51df771d@mail.gmail.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T19:53:51Z","receivedAt":"2009-10-18T19:53:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> On Sun, Oct 18, 2009 at 10:01, Junio C Hamano wrote:\n>> +               OPT_SET_INT(0, \"nodwim\", &dwim_new_local_branch,\n>> +                           \"do not dwim local branch creation\", 0),\n>\n> Isn't there a special negation support for --no-something in parse-options?\n\nThere probably is, but this is a whetherbaloon patch without documentation\nand pretty much Porcelain only, so I took the lazy route.\n\nHelping hands in polishing it up is very welcome.\n"},{"id":"125291","messageId":"20091019052043.6117@nanako3.lavabit.com","threadId":"21136","inReplyTo":"20091018120053.GA11391@atjola.homenet","subject":"Re: [PATCH 2/3] DWIM \"git checkout frotz\" to \"git checkout -b frotz origin/frotz\"","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-10-18T20:20:43Z","receivedAt":"2009-10-18T20:20:43Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Björn Steinbrink writes:\n\n> On 2009.10.18 19:34:48 +0900, Nanako Shiraishi wrote:\n>> Quoting Junio C Hamano \n>> \n>> > When 'frotz' is not a valid object name nor a tracked filename,\n>> > we used to complain and failed this command. When there is only\n>> > one remote that has 'frotz' as one of its tracking branches, we can\n>> > DWIM it as a request to create a local branch 'frotz' forking from\n>> > the matching remote tracking branch.\n>> \n>> In the subject you used 'git checkout -b frotz origin/frotz'. Did you\n>> forget to say '-t'?\n>\n> Hm, the DWIMmery only triggers when opts.track is\n> BRANCH_TRACK_UNSPECIFIED, i.e. -t was not used. And it doesn't change\n> opts.track when it DWIMs, so it respects branch.autosetupmerge, which\n> would be overriden by -t. So it seems correct that -t is not in there.\n\nI see.\n\nA user who always wants tracking can set the config option and use \nthe new \"git checkout frotz\" shortcut, but a user who usually \ndoesn't want tracking doesn't have the config option and when he \nwants tracking only for this new branch he can explicitly say \"git \ncheckout -t origin/frotz\", right?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"125293","messageId":"20091018210222.GA5371@blimp.localdomain","threadId":"21136","inReplyTo":"7v7huspjg0.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Use \"--no-\" prefix to switch off some of checkout dwimmery","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-10-18T21:02:22Z","receivedAt":"2009-10-18T21:02:22Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"The one which guesses local branch name from a remote reference.\n\nSigned-off-by: Alex Riesen \n---\n\nJunio C Hamano, Sun, Oct 18, 2009 21:53:51 +0200:\n> Alex Riesen writes:\n> \n> > On Sun, Oct 18, 2009 at 10:01, Junio C Hamano wrote:\n> >> +               OPT_SET_INT(0, \"nodwim\", &dwim_new_local_branch,\n> >> +                           \"do not dwim local branch creation\", 0),\n> >\n> > Isn't there a special negation support for --no-something in parse-options?\n> \n> There probably is, but this is a whetherbaloon patch without documentation\n> and pretty much Porcelain only, so I took the lazy route.\n> \n> Helping hands in polishing it up is very welcome.\n\nMaybe like this?\n\nBTW, can parse-options take care of the \" (default)\" addition?\n\n builtin-checkout.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-checkout.c b/builtin-checkout.c\nindex 6ec9b83..22b023b 100644\n--- a/builtin-checkout.c\n+++ b/builtin-checkout.c\n@@ -632,8 +632,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tOPT_STRING(0, \"conflict\", &conflict_style, \"style\",\n \t\t\t \"conflict style (merge or diff3)\"),\n \t\tOPT_BOOLEAN('p', \"patch\", &patch_mode, \"select hunks interactively\"),\n-\t\tOPT_SET_INT(0, \"nodwim\", &dwim_new_local_branch,\n-\t\t\t \"do not dwim local branch creation\", 0),\n+\t\tOPT_SET_INT(0, \"dwim\", &dwim_new_local_branch,\n+\t\t\t \"Guess local branch from remote reference (default)\", 0),\n \t\tOPT_END(),\n \t};\n \tint has_dash_dash;\n-- \n1.6.5.1.50.g84e6e\n"},{"id":"125299","messageId":"7vzl7omi5z.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"20091018210222.GA5371@blimp.localdomain","subject":"Re: [PATCH] Use \"--no-\" prefix to switch off some of checkout dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T22:49:44Z","receivedAt":"2009-10-18T22:49:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> The one which guesses local branch name from a remote reference.\n>\n> Signed-off-by: Alex Riesen \n> ---\n>\n> Maybe like this?\n>\n> BTW, can parse-options take care of the \" (default)\" addition?\n>\n> builtin-checkout.c | 4 ++--\n> 1 files changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/builtin-checkout.c b/builtin-checkout.c\n> index 6ec9b83..22b023b 100644\n> --- a/builtin-checkout.c\n> +++ b/builtin-checkout.c\n> @@ -632,8 +632,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n> \t\tOPT_STRING(0, \"conflict\", &conflict_style, \"style\",\n> \t\t\t \"conflict style (merge or diff3)\"),\n> \t\tOPT_BOOLEAN('p', \"patch\", &patch_mode, \"select hunks interactively\"),\n> -\t\tOPT_SET_INT(0, \"nodwim\", &dwim_new_local_branch,\n> -\t\t\t \"do not dwim local branch creation\", 0),\n> +\t\tOPT_SET_INT(0, \"dwim\", &dwim_new_local_branch,\n> +\t\t\t \"Guess local branch from remote reference (default)\", 0),\n\nHumph, how does SET_INT know to set it to 1 with --dwim and set it to 0\nwith --no-dwim?\n\n> \t\tOPT_END(),\n> \t};\n> \tint has_dash_dash;\n> -- \n> 1.6.5.1.50.g84e6e\n"},{"id":"125300","messageId":"7vvdicmi4k.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"20091019052043.6117@nanako3.lavabit.com","subject":"Re: [PATCH 2/3] DWIM \"git checkout frotz\" to \"git checkout -b frotz origin/frotz\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-18T22:50:35Z","receivedAt":"2009-10-18T22:50:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n>>> In the subject you used 'git checkout -b frotz origin/frotz'. Did you\n>>> forget to say '-t'?\n>>\n>> Hm, the DWIMmery only triggers when opts.track is\n>> BRANCH_TRACK_UNSPECIFIED, i.e. -t was not used. And it doesn't change\n>> opts.track when it DWIMs, so it respects branch.autosetupmerge, which\n>> would be overriden by -t. So it seems correct that -t is not in there.\n>\n> I see.\n>\n> A user who always wants tracking can set the config option and use \n> the new \"git checkout frotz\" shortcut, but a user who usually \n> doesn't want tracking doesn't have the config option and when he \n> wants tracking only for this new branch he can explicitly say \"git \n> checkout -t origin/frotz\", right?\n\nCorrect.\n"},{"id":"125334","messageId":"20091019055811.GA7779@atjola.homenet","threadId":"21136","inReplyTo":"20091019052043.6117@nanako3.lavabit.com","subject":"Re: [PATCH 2/3] DWIM \"git checkout frotz\" to \"git checkout -b frotz origin/frotz\"","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-10-19T05:58:11Z","receivedAt":"2009-10-19T05:58:11Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.10.19 05:20:43 +0900, Nanako Shiraishi wrote:\n> A user who always wants tracking can set the config option and use \n> the new \"git checkout frotz\" shortcut, but a user who usually \n> doesn't want tracking doesn't have the config option and when he \n> wants tracking only for this new branch he can explicitly say \"git \n> checkout -t origin/frotz\", right?\n\nWell, branch.autosetupmerge has three possible values.\n - true: Do the upstream setup when starting from remote tracking\n branches\n - always: Also do the upstream setup when starting from a local branch\n head\n - false: Don't do any upstream setup\n\nThe default is \"true\", which should catch the \"git checkout frotz\"\nshortcut, as that selects a remote tracking branch as the starting\npoint. So the user doesn't have to change any config setting to have\nthat act as if -t was given.\n\nOnly if we doesn't want \"git checkout frotz\" to not do the upstream\nsetup, he needs to set branch.autosetupmerge to false.\n\nAnd falling back to \"git checkout --track/--no-track origin/frotz\" he\ncan override whatever config setting he has.\n\nBjörn\n"},{"id":"125337","messageId":"81b0412b0910182307n53b4a51cvaa14829ea8b40207@mail.gmail.com","threadId":"21136","inReplyTo":"7vzl7omi5z.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Use \"--no-\" prefix to switch off some of checkout dwimmery","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-10-19T06:07:37Z","receivedAt":"2009-10-19T06:07:37Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Mon, Oct 19, 2009 at 00:49, Junio C Hamano wrote:\n> Alex Riesen writes:\n>> +             OPT_SET_INT(0, \"dwim\", &dwim_new_local_branch,\n>> +                         \"Guess local branch from remote reference (default)\", 0),\n>\n> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0\n> with --no-dwim?\n\nIt seems to do, though (I checked before sending).\n"},{"id":"125338","messageId":"81b0412b0910182312h583e74e4v2678eb4375164c34@mail.gmail.com","threadId":"21136","inReplyTo":"81b0412b0910182307n53b4a51cvaa14829ea8b40207@mail.gmail.com","subject":"Re: [PATCH] Use \"--no-\" prefix to switch off some of checkout dwimmery","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-10-19T06:12:13Z","receivedAt":"2009-10-19T06:12:13Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Mon, Oct 19, 2009 at 08:07, Alex Riesen wrote:\n> On Mon, Oct 19, 2009 at 00:49, Junio C Hamano wrote:\n>> Alex Riesen writes:\n>>> +             OPT_SET_INT(0, \"dwim\", &dwim_new_local_branch,\n>>> +                         \"Guess local branch from remote reference (default)\", 0),\n>>\n>> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0\n>> with --no-dwim?\n>\n> It seems to do, though (I checked before sending).\n>\n\nRight, just looked at the parse-options: it is defined for all types.\n\nparse-options.c +/get_value\n\n\tconst int unset = flags & OPT_UNSET;\n...\n\tcase OPTION_SET_INT:\n\t\t*(int *)opt->value = unset ? 0 : opt->defval;\n\t\treturn 0;\n\nVery useful.\n"},{"id":"125339","messageId":"7vhbtv7vsr.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"81b0412b0910182312h583e74e4v2678eb4375164c34@mail.gmail.com","subject":"Re: [PATCH] Use \"--no-\" prefix to switch off some of checkout dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-19T06:16:36Z","receivedAt":"2009-10-19T06:16:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> On Mon, Oct 19, 2009 at 08:07, Alex Riesen wrote:\n>> On Mon, Oct 19, 2009 at 00:49, Junio C Hamano wrote:\n>>> Alex Riesen writes:\n>>>> +             OPT_SET_INT(0, \"dwim\", &dwim_new_local_branch,\n>>>> +                         \"Guess local branch from remote reference (default)\", 0),\n>>>\n>>> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0\n>>> with --no-dwim?\n>>\n>> It seems to do, though (I checked before sending).\n>>\n>\n> Right, just looked at the parse-options: it is defined for all types.\n>\n> parse-options.c +/get_value\n>\n> \tconst int unset = flags & OPT_UNSET;\n> ...\n> \tcase OPTION_SET_INT:\n> \t\t*(int *)opt->value = unset ? 0 : opt->defval;\n> \t\treturn 0;\n>\n> Very useful.\n\nAh, did you mean to change the default value to 1 as well?\n"},{"id":"125345","messageId":"81b0412b0910190017o2e6dfd47v868517404d362843@mail.gmail.com","threadId":"21136","inReplyTo":"7vhbtv7vsr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Use \"--no-\" prefix to switch off some of checkout dwimmery","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-10-19T07:17:58Z","receivedAt":"2009-10-19T07:17:58Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Mon, Oct 19, 2009 at 08:16, Junio C Hamano wrote:\n> Alex Riesen writes:\n>\n>> On Mon, Oct 19, 2009 at 08:07, Alex Riesen wrote:\n>>> On Mon, Oct 19, 2009 at 00:49, Junio C Hamano wrote:\n>>>> Alex Riesen writes:\n>>>>> +             OPT_SET_INT(0, \"dwim\", &dwim_new_local_branch,\n>>>>> +                         \"Guess local branch from remote reference (default)\", 0),\n>>>>\n>>>> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0\n>>>> with --no-dwim?\n>>>\n>>> It seems to do, though (I checked before sending).\n>>>\n>>\n>> Right, just looked at the parse-options: it is defined for all types.\n>>\n>> parse-options.c +/get_value\n>>\n>>       const int unset = flags & OPT_UNSET;\n>> ...\n>>       case OPTION_SET_INT:\n>>               *(int *)opt->value = unset ? 0 : opt->defval;\n>>               return 0;\n>>\n>> Very useful.\n>\n> Ah, did you mean to change the default value to 1 as well?\n>\n\nErr... yes. I (wrongly) assumed that the current value in the\nstorage is the default. Now, having looked at struct option\nI see that It isn't (and the default is in defval).\n\nBTW, why is the option an ...INT? Where a future extension planned?\n"},{"id":"125346","messageId":"7v63ab7slh.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"81b0412b0910190017o2e6dfd47v868517404d362843@mail.gmail.com","subject":"Re: [PATCH] Use \"--no-\" prefix to switch off some of checkout dwimmery","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-19T07:25:46Z","receivedAt":"2009-10-19T07:25:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> BTW, why is the option an ...INT? Where a future extension planned?\n\nNo, in my original I wanted to default to 1 and an option to set it to\nzero, only because I did not want a variable with negative name.\n"},{"id":"125624","messageId":"32541b130910211029x2f4295c3w40dd13b3cdc7762c@mail.gmail.com","threadId":"21136","inReplyTo":"7v7huspjg0.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-10-21T17:29:09Z","receivedAt":"2009-10-21T17:29:09Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano wrote:\n> Alex Riesen writes:\n>\n>> On Sun, Oct 18, 2009 at 10:01, Junio C Hamano wrote:\n>>> +               OPT_SET_INT(0, \"nodwim\", &dwim_new_local_branch,\n>>> +                           \"do not dwim local branch creation\", 0),\n>>\n>> Isn't there a special negation support for --no-something in parse-options?\n>\n> There probably is, but this is a whetherbaloon patch without documentation\n> and pretty much Porcelain only, so I took the lazy route.\n>\n> Helping hands in polishing it up is very welcome.\n\nI find the idea of an option for \"don't do what I mean\" to be pretty\nentertaining. Or maybe just misleading :)\n\nHave fun,\n\nAvery\n"},{"id":"125646","messageId":"20091022062145.6117@nanako3.lavabit.com","threadId":"21136","inReplyTo":"32541b130910211029x2f4295c3w40dd13b3cdc7762c@mail.gmail.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-10-21T21:21:45Z","receivedAt":"2009-10-21T21:21:45Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Avery Pennarun \n\n> On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano wrote:\n>> Helping hands in polishing it up is very welcome.\n>\n> I find the idea of an option for \"don't do what I mean\" to be pretty\n> entertaining. Or maybe just misleading :)\n>\n> Have fun,\n>\n> Avery\n\nAs Junio asked for helping hands, let's try to be helpful and constructive.\n\nMaybe \"don't second-guess\" explains it better?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"125657","messageId":"7vskdcz973.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"20091022062145.6117@nanako3.lavabit.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T22:14:08Z","receivedAt":"2009-10-21T22:14:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> As Junio asked for helping hands, let's try to be helpful and constructive.\n>\n> Maybe \"don't second-guess\" explains it better?\n\nPerhaps --no-guess, as --no-second-guess is rather hard to read even in scripts.\n"},{"id":"125660","messageId":"7vtyxsxtmp.fsf_-_@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"7vskdcz973.fsf@alter.siamese.dyndns.org","subject":"[PATCH] git checkout --no-guess","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T22:35:42Z","receivedAt":"2009-10-21T22:35:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Porcelains may want to make sure their calls to \"git checkout\" will\nreliably fail regardless of the presense of random remote tracking\nbranches by the new DWIMmery introduced.\n\nLuckily all existing in-tree callers have extra checks to make sure they\nfeed local branch name when they want to switch, or they explicitly ask to\ndetach HEAD at the given commit, so there is no need to add this option\nfor them.\n\nAs this is strictly script-only option, do not even bother to document it,\nand do bother to hide it from \"git checkout -h\".\n\nSigned-off-by: Junio C Hamano \n---\n\n Junio C Hamano writes:\n\n > Nanako Shiraishi writes:\n >\n >> As Junio asked for helping hands, let's try to be helpful and constructive.\n >>\n >> Maybe \"don't second-guess\" explains it better?\n >\n > Perhaps --no-guess, as --no-second-guess is rather hard to read even in scripts.\n\n builtin-checkout.c | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-checkout.c b/builtin-checkout.c\nindex fb7e68a..da04eed 100644\n--- a/builtin-checkout.c\n+++ b/builtin-checkout.c\n@@ -616,6 +616,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \tstruct tree *source_tree = NULL;\n \tchar *conflict_style = NULL;\n \tint patch_mode = 0;\n+\tint dwim_new_local_branch = 1;\n \tstruct option options[] = {\n \t\tOPT__QUIET(&opts.quiet),\n \t\tOPT_STRING('b', NULL, &opts.new_branch, \"new branch\", \"branch\"),\n@@ -631,6 +632,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\tOPT_STRING(0, \"conflict\", &conflict_style, \"style\",\n \t\t\t \"conflict style (merge or diff3)\"),\n \t\tOPT_BOOLEAN('p', \"patch\", &patch_mode, \"select hunks interactively\"),\n+\t\t{ OPTION_BOOLEAN, 0, \"guess\", &dwim_new_local_branch, NULL,\n+\t\t \"second guess 'git checkout no-such-branch'\",\n+\t\t PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },\n \t\tOPT_END(),\n \t};\n \tint has_dash_dash;\n@@ -715,6 +719,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)\n \t\t\tif (has_dash_dash) /* case (1) */\n \t\t\t\tdie(\"invalid reference: %s\", arg);\n \t\t\tif (!patch_mode &&\n+\t\t\t dwim_new_local_branch &&\n \t\t\t opts.track == BRANCH_TRACK_UNSPECIFIED &&\n \t\t\t !opts.new_branch &&\n \t\t\t !check_filename(NULL, arg) &&\n-- \n1.6.5.1.107.gba912\n"},{"id":"125665","messageId":"32541b130910211551n13e0dd1bha6dcdc82d1d6b4cd@mail.gmail.com","threadId":"21136","inReplyTo":"7vtyxsxtmp.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] git checkout --no-guess","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-10-21T22:51:46Z","receivedAt":"2009-10-21T22:51:46Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Oct 21, 2009 at 6:35 PM, Junio C Hamano wrote:\n> As this is strictly script-only option, do not even bother to document it,\n> and do bother to hide it from \"git checkout -h\".\n\nIs it a standard git policy to not document script-only options? As a\nperson who writes scripts that use git, we will need to discover these\noptions somehow...\n\nJust curious. (And now wondering how many other wonderful options are\nin there but undocumented...)\n\nThanks,\n\nAvery\n"},{"id":"125669","messageId":"alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"20091022062145.6117@nanako3.lavabit.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-22T00:27:30Z","receivedAt":"2009-10-22T00:27:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Oct 2009, Nanako Shiraishi wrote:\n\n> Quoting Avery Pennarun \n> \n> > On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano wrote:\n> >> Helping hands in polishing it up is very welcome.\n> >\n> > I find the idea of an option for \"don't do what I mean\" to be pretty\n> > entertaining. Or maybe just misleading :)\n> >\n> > Have fun,\n> >\n> > Avery\n> \n> As Junio asked for helping hands, let's try to be helpful and constructive.\n> \n> Maybe \"don't second-guess\" explains it better?\n\nMy take on it:\n\n1) --no-porcelain\n\n2) we all are bike-shedding, not being constructive at all\n\nCiao,\nDscho\n"},{"id":"125681","messageId":"40aa078e0910220009p729b7dc6iaf14eab3bda37670@mail.gmail.com","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-10-22T07:09:13Z","receivedAt":"2009-10-22T07:09:13Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Oct 22, 2009 at 2:27 AM, Johannes Schindelin\n wrote:\n> My take on it:\n>\n> 1) --no-porcelain\n>\n> 2) we all are bike-shedding, not being constructive at all\n\nIn that case, I propose \"--yellow\".\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"125782","messageId":"4AE17006.9070006@drmicha.warpmail.net","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-10-23T08:57:42Z","receivedAt":"2009-10-23T08:57:42Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 22.10.2009 02:27:\n> Hi,\n> \n> On Thu, 22 Oct 2009, Nanako Shiraishi wrote:\n> \n>> Quoting Avery Pennarun \n>>\n>>> On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano wrote:\n>>>> Helping hands in polishing it up is very welcome.\n>>>\n>>> I find the idea of an option for \"don't do what I mean\" to be pretty\n>>> entertaining. Or maybe just misleading :)\n>>>\n>>> Have fun,\n>>>\n>>> Avery\n>>\n>> As Junio asked for helping hands, let's try to be helpful and constructive.\n>>\n>> Maybe \"don't second-guess\" explains it better?\n> \n> My take on it:\n> \n> 1) --no-porcelain\n\nBetween --no-dwim and --no-porcelain, maybe --no-wimp is a good compromise?\n\n> 2) we all are bike-shedding, not being constructive at all\n\nThat's the fun part!\n\nMichael\n"},{"id":"125824","messageId":"7vzl7h8fjp.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-24T06:35:54Z","receivedAt":"2009-10-24T06:35:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Thu, 22 Oct 2009, Nanako Shiraishi wrote:\n>\n>> Quoting Avery Pennarun \n>> \n>> > On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano wrote:\n>> >> Helping hands in polishing it up is very welcome.\n>> >\n>> > I find the idea of an option for \"don't do what I mean\" to be pretty\n>> > entertaining. Or maybe just misleading :)\n>> >\n>> > Have fun,\n>> >\n>> > Avery\n>> \n>> As Junio asked for helping hands, let's try to be helpful and constructive.\n>> \n>> Maybe \"don't second-guess\" explains it better?\n>\n> My take on it:\n>\n> 1) --no-porcelain\n>\n> 2) we all are bike-shedding, not being constructive at all\n\nYou are right about (2), regarding the option name. I've queued one that\nuses --no-guess.\n\nRegarding the correct use of parse_options(), I had to figure it out\nmyself, and helping hand would have, eh, helped me.\n"},{"id":"125848","messageId":"117f2cc80910240759oa9f57e7h67f06816d37e328c@mail.gmail.com","threadId":"21136","inReplyTo":"7vzl7h8fjp.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"David Roundy","fromEmail":"roundyd@physics.oregonstate.edu","sentAt":"2009-10-24T14:59:47Z","receivedAt":"2009-10-24T14:59:47Z","isPatch":true,"sender":{"key":"roundyd@physics.oregonstate.edu","avatar":"https://gravatar.com/avatar/20c6928b273bb8a1c23deb12399d0e74782ce911504ad5ee604294fc6a61940a?d=mp&s=160"},"body":"On Sat, Oct 24, 2009 at 2:35 AM, Junio C Hamano wrote:\n>> My take on it:\n>>\n>> 1) --no-porcelain\n>>\n>> 2) we all are bike-shedding, not being constructive at all\n>\n> You are right about (2), regarding the option name. I've queued one that\n> uses --no-guess.\n\nPerhaps a universal --plumbing flag would be handy? It'd be nice to be\nable to pass any command --plumbing and it'll either behave in a\nstable, predictable, plumbing-like way, or die with an error message\nstating that it isn't a plumbing command. Right now, it's sort of\nhard to figure out what is plumbing and what is porcelain. Some\ncommands are clear, but other commands labelled as plumbing in git(1)\nare deprecated in favor of commands labelled as porcelain.\n\nDavid\n"},{"id":"125855","messageId":"7v7huk61c3.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"117f2cc80910240759oa9f57e7h67f06816d37e328c@mail.gmail.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-24T19:25:48Z","receivedAt":"2009-10-24T19:25:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Roundy writes:\n\n> Perhaps a universal --plumbing flag would be handy?\n\nYes in general but it is unclear what aspect of its behaviour we will\nbe casting in stone with a generic --plumbing option in this case. I\nalso think that \"checkout\" Porcelain is not yet mature enough for us\nto do this right now. For example, I am reasonably sure that somebody\nmotivated enough will teach it to touch submodule trees when switching\nto another branch by default, and it is unclear if we should turn off\nthese expected additions when --plumbing is seen.\n"},{"id":"125905","messageId":"4AE48E7B.3030204@gmail.com","threadId":"21136","inReplyTo":"7vfx9modqf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Uri Okrent","fromEmail":"uokrent@gmail.com","sentAt":"2009-10-25T17:44:27Z","receivedAt":"2009-10-25T17:44:27Z","isPatch":true,"sender":{"key":"uokrent@gmail.com","avatar":"https://gravatar.com/avatar/7788ed2d4f1bfefc11082b08b0234fd2d752113623753bda4a032a2ae9687acf?d=mp&s=160"},"body":"Junio C Hamano wrote:\n > When you do not have local \"frotz\" branch, and do have cloned/fetched from\n> the origin that has \"frotz\" branch, I am actually Ok with this\n> \n> $ git checkout frotz [--]\n> \n> to do an equivalent of:\n> \n> $ git checkout -t -b frotz origin/frotz\n> \n> I do not have problem with this _particular_ DWIMmery. It will not break\n> people's expectations, other than \"asking to check out non-existing ref\n> should fail\". That expectation might be logical, but I do not think it is\n> useful.\n\nFWIW most of the people we train (and we do spend time explaining the\ndistinction between origin/foo and foo) still find it annoying to have\nto create local branches that track branches from the cloned repo. I\nthink this probably has something to do with the fact that master is\nautomatically checked out when you clone--people expect other upstream\nbranches to just 'exist' locally in a similar fashion.\n\nI think the above suggestion is simple enough and would provide the most\nbang-for-your-buck in terms of usability.\n-- \n Uri\n\nPlease consider the environment before printing this message.\nhttp://www.panda.org/how_you_can_help/\n"},{"id":"125906","messageId":"4AE48F88.1030108@gmail.com","threadId":"21136","inReplyTo":"7vhbu2syi6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Uri Okrent","fromEmail":"uokrent@gmail.com","sentAt":"2009-10-25T17:48:56Z","receivedAt":"2009-10-25T17:48:56Z","isPatch":true,"sender":{"key":"uokrent@gmail.com","avatar":"https://gravatar.com/avatar/7788ed2d4f1bfefc11082b08b0234fd2d752113623753bda4a032a2ae9687acf?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> In this sequence:\n> \n> 1$ git checkout $commit_name_that_is_not_a_local_branch\n> 2$ git commit; hack; hack; hack;...\n> 3$ git checkout $branch_name\n> [...]\n> Step #3 is where the state built in the detached HEAD \"branch\" vanishes\n> into lost-found.\n> \n> The experts argued that #3 is where it is dangerous...\n\nIf step 3 is where the danger lies, wouldn't it then be most appropriate to put\nthe warning message there? I.e., warn or refuse to switch branches when\ncurrently on a detached head containing new commits, kind of like branch -d's\ncowardliness.\n-- \n Uri\n\nPlease consider the environment before printing this message.\nhttp://www.panda.org/how_you_can_help/\n"},{"id":"125923","messageId":"7vbpjupqy5.fsf@alter.siamese.dyndns.org","threadId":"21136","inReplyTo":"4AE48F88.1030108@gmail.com","subject":"Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-26T07:14:26Z","receivedAt":"2009-10-26T07:14:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Uri Okrent writes:\n\n> Junio C Hamano wrote:\n>> In this sequence:\n>>\n>> 1$ git checkout $commit_name_that_is_not_a_local_branch\n>> 2$ git commit; hack; hack; hack;...\n>> 3$ git checkout $branch_name\n>> [...]\n>> Step #3 is where the state built in the detached HEAD \"branch\" vanishes\n>> into lost-found.\n>>\n>> The experts argued that #3 is where it is dangerous...\n>\n> If step 3 is where the danger lies, wouldn't it then be most appropriate to put\n> the warning message there?\n\nYou already get reminded that you were on a detached HEAD in step #3.\n\nThe primary point of the message you are replying to was that I do not\nagree with the view that step #3 is the most problematic step. The\nexisting reminder would help people who read it and are capable of\nrealizing \"ah, I started it on a throw-away branch but ended up with\nsomething I would rather keep\" and doing \"git branch topic HEAD@{1}\". \n\nIt will not help people who haven't got enough clue yet to know what a\ndetached HEAD is, or you can refer to your previous point with HEAD@{1}\nnotation. We do give brief advice at step #1 to alleviate this issue.\n"},{"id":"125938","messageId":"76718490910261117i60a556ebv7405e945796a3610@mail.gmail.com","threadId":"21136","inReplyTo":"32541b130910211551n13e0dd1bha6dcdc82d1d6b4cd@mail.gmail.com","subject":"Re: [PATCH] git checkout --no-guess","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2009-10-26T18:17:04Z","receivedAt":"2009-10-26T18:17:04Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Wed, Oct 21, 2009 at 3:51 PM, Avery Pennarun wrote:\n> On Wed, Oct 21, 2009 at 6:35 PM, Junio C Hamano wrote:\n>> As this is strictly script-only option, do not even bother to document it,\n>> and do bother to hide it from \"git checkout -h\".\n>\n> Is it a standard git policy to not document script-only options?  As a\n> person who writes scripts that use git, we will need to discover these\n> options somehow...\n>\n> Just curious.  (And now wondering how many other wonderful options are\n> in there but undocumented...)\n\n * PARSE_OPT_HIDDEN: this option is skipped in the default usage, and\n * shown only in the full usage.\n\nWhich translates to --help-all:\n\n--help-all\n Some git commands take options that are only used for\nplumbing or that are deprecated, and such options are hidden from the\ndefault usage. This option gives the full list of options.\n\n So git checkout --help-all should show it.\n\nj.\n"},{"id":"125939","messageId":"32541b130910261125h7be6631axc4ed1256c606c3bb@mail.gmail.com","threadId":"21136","inReplyTo":"76718490910261117i60a556ebv7405e945796a3610@mail.gmail.com","subject":"Re: [PATCH] git checkout --no-guess","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-10-26T18:25:31Z","receivedAt":"2009-10-26T18:25:31Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Oct 26, 2009 at 2:17 PM, Jay Soffian wrote:\n> On Wed, Oct 21, 2009 at 3:51 PM, Avery Pennarun wrote:\n>> Just curious.  (And now wondering how many other wonderful options are\n>> in there but undocumented...)\n>\n>  *   PARSE_OPT_HIDDEN: this option is skipped in the default usage, and\n>  *                     shown only in the full usage.\n>\n> Which translates to --help-all:\n>\n> --help-all\n>           Some git commands take options that are only used for\n> plumbing or that are deprecated, and such options are hidden from the\n> default usage. This option gives the full list of options.\n>\n>  So git checkout --help-all should show it.\n\nThanks! I had no idea about --help-all.\n\nAvery\n"},{"id":"125943","messageId":"alpine.DEB.1.00.0910262111340.4985@pacific.mpi-cbg.de","threadId":"21136","inReplyTo":"117f2cc80910240759oa9f57e7h67f06816d37e328c@mail.gmail.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-10-26T20:12:49Z","receivedAt":"2009-10-26T20:12:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Oct 2009, David Roundy wrote:\n\n> On Sat, Oct 24, 2009 at 2:35 AM, Junio C Hamano wrote:\n> >> My take on it:\n> >>\n> >> 1) --no-porcelain\n> >>\n> >> 2) we all are bike-shedding, not being constructive at all\n> >\n> > You are right about (2), regarding the option name. I've queued one that\n> > uses --no-guess.\n> \n> Perhaps a universal --plumbing flag would be handy?\n\nNo. Older Git versions do not know about it, so you cannot Just Modify \nYour Scripts. So the benefit of --plumbing is dubitable.\n\nFWIW the same goes for --no-porcelain.\n\nCiao,\nDscho\n"},{"id":"125948","messageId":"32541b130910261340g1988caednc17f3d159ec00d26@mail.gmail.com","threadId":"21136","inReplyTo":"alpine.DEB.1.00.0910262111340.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-10-26T20:40:41Z","receivedAt":"2009-10-26T20:40:41Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Oct 26, 2009 at 4:12 PM, Johannes Schindelin\n wrote:\n> On Sat, 24 Oct 2009, David Roundy wrote:\n>> Perhaps a universal --plumbing flag would be handy?\n>\n> No.  Older Git versions do not know about it, so you cannot Just Modify\n> Your Scripts.  So the benefit of --plumbing is dubitable.\n>\n> FWIW the same goes for --no-porcelain.\n\nI suppose that, three years down the road, the existence of such an\noption would be useful. Until then, any change at all to any\ncommand's interface seems to have the same problem as you describe.\n\nThat said, as a person who maintains a bunch of git-wrapping scripts\nat work, it seems more straightforward to me to continue the\nseparation between plumbing vs. porcelain commands, rather than giving\neach command two subtly incompatible modes. It's much easier for me\nto remember \"don't use git checkout\" than to remember \"when you call\ngit checkout, make sure to use --plumbing, even though *today* it\nworks just fine without it.\"\n\nI don't think there's actually a plumbing alternative to git-checkout,\nhowever. My git-subtree script (and another script at work) have\nalready had some bugs because of this (specifically, the differing\nbehaviour of git-checkout with and without a path specified). Is\nthere something else I should be using in my scripts to be maximally\nsafe?\n\nHave fun,\n\nAvery\n"},{"id":"125951","messageId":"20091026212628.GC27744@sigio.peff.net","threadId":"21136","inReplyTo":"32541b130910261340g1988caednc17f3d159ec00d26@mail.gmail.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-26T21:26:28Z","receivedAt":"2009-10-26T21:26:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 26, 2009 at 04:40:41PM -0400, Avery Pennarun wrote:\n\n> I don't think there's actually a plumbing alternative to git-checkout,\n> however. My git-subtree script (and another script at work) have\n> already had some bugs because of this (specifically, the differing\n> behaviour of git-checkout with and without a path specified). Is\n> there something else I should be using in my scripts to be maximally\n> safe?\n\nIt's git-update-ref. Which highlights one problem with the\nporcelain/plumbing distinction. Our plumbing building blocks work at a\nvery low level, but often when scripting you want to use higher level\nbuilding blocks. So porcelain gets used in scripts, and gets an\nambiguous state. Consider \"git commit\", for example. Does anyone\nactually script around \"write-tree\" and \"commit-tree\" these days, or do\nthey just script around \"git commit\"?\n\n-Peff\n"},{"id":"125953","messageId":"32541b130910261501n32046cc5s12283a8e3981d04e@mail.gmail.com","threadId":"21136","inReplyTo":"20091026212628.GC27744@sigio.peff.net","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-10-26T22:01:29Z","receivedAt":"2009-10-26T22:01:29Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Oct 26, 2009 at 5:26 PM, Jeff King wrote:\n> On Mon, Oct 26, 2009 at 04:40:41PM -0400, Avery Pennarun wrote:\n>> I don't think there's actually a plumbing alternative to git-checkout,\n>> however.  My git-subtree script (and another script at work) have\n>> already had some bugs because of this (specifically, the differing\n>> behaviour of git-checkout with and without a path specified).  Is\n>> there something else I should be using in my scripts to be maximally\n>> safe?\n>\n> It's git-update-ref.\n\nThat would be similar to git commit, not git checkout, right? Oh\nwait, I see the confusion: git checkout does two things. It switches\nbranches, and it checks out files from the index into the work tree.\nI meant the latter meaning.\n\n> Consider \"git commit\", for example. Does anyone\n> actually script around \"write-tree\" and \"commit-tree\" these days, or do\n> they just script around \"git commit\"?\n\nOh, I use those all the time. They're awesome! It allows you to\ncreate commits without having a working tree, which lets me do very\ninteresting tricks. git-subtree uses this heavily.\n\nI'm probably a weirdo, though.\n\nHave fun,\n\nAvery\n"},{"id":"125955","messageId":"20091026221424.GA28184@sigio.peff.net","threadId":"21136","inReplyTo":"32541b130910261501n32046cc5s12283a8e3981d04e@mail.gmail.com","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-26T22:14:24Z","receivedAt":"2009-10-26T22:14:24Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:\n\n> > It's git-update-ref.\n> \n> That would be similar to git commit, not git checkout, right? Oh\n> wait, I see the confusion: git checkout does two things. It switches\n> branches, and it checks out files from the index into the work tree.\n> I meant the latter meaning.\n\nEr, sorry, yes. It should be \"git symbolic-ref\", of course, to change\nHEAD, and then probably read-tree and checkout-index. I was just not\nthinking when I wrote the other message (hopefully I am doing so now).\n\n> > Consider \"git commit\", for example. Does anyone\n> > actually script around \"write-tree\" and \"commit-tree\" these days, or do\n> > they just script around \"git commit\"?\n> \n> Oh, I use those all the time. They're awesome! It allows you to\n> create commits without having a working tree, which lets me do very\n> interesting tricks. git-subtree uses this heavily.\n> \n> I'm probably a weirdo, though.\n\nOK, I should have phrased my statement differently (see, I told you I\nwasn't thinking). Yes, there are reasons to script around low-level\nbuilding blocks, when you don't want the assumptions associated with the\nhigher level. But I'm sure there are tons of scripts that munge some\nfiles in a worktree, followed by \"git add -A; git commit -m 'automagic\nupdate'\". And in that case, nobody would script around \"commit-tree\"\nbecause it's a lot more work.\n\n-Peff\n"},{"id":"125960","messageId":"32541b130910261528s12cbe3c0gda163be6a906bdf6@mail.gmail.com","threadId":"21136","inReplyTo":"20091026221424.GA28184@sigio.peff.net","subject":"Re: [PATCH 3/3] git checkout --nodwim","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-10-26T22:28:51Z","receivedAt":"2009-10-26T22:28:51Z","isPatch":true,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Oct 26, 2009 at 6:14 PM, Jeff King wrote:\n> On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:\n>> > It's git-update-ref.\n>>\n>> That would be similar to git commit, not git checkout, right?  Oh\n>> wait, I see the confusion: git checkout does two things.  It switches\n>> branches, and it checks out files from the index into the work tree.\n>> I meant the latter meaning.\n>\n> Er, sorry, yes. It should be \"git symbolic-ref\", of course, to change\n> HEAD, and then probably read-tree and checkout-index. I was just not\n> thinking when I wrote the other message (hopefully I am doing so now).\n\nWow, I've browsed through the git manpages repeatedly and never found\ncheckout-index. It was exactly the missing building block I was\nlooking for. Thanks!\n\n>> > Consider \"git commit\", for example. Does anyone\n>> > actually script around \"write-tree\" and \"commit-tree\" these days, or do\n>> > they just script around \"git commit\"?\n>>\n>> Oh, I use those all the time.  They're awesome!  It allows you to\n>> create commits without having a working tree, which lets me do very\n>> interesting tricks.  git-subtree uses this heavily.\n>>\n>> I'm probably a weirdo, though.\n>\n> OK, I should have phrased my statement differently (see, I told you I\n> wasn't thinking). Yes, there are reasons to script around low-level\n> building blocks, when you don't want the assumptions associated with the\n> higher level. But I'm sure there are tons of scripts that munge some\n> files in a worktree, followed by \"git add -A; git commit -m 'automagic\n> update'\". And in that case, nobody would script around \"commit-tree\"\n> because it's a lot more work.\n\nUnfortunately this is pretty tricky to get perfect; perhaps there's no\nway to do it.\n\nIn git-subtree, for example, I *mostly* use write-tree and\ncommit-tree, but when I do the final merge operation (to take the\nsynthetic history and merge it into your \"real\" history) I use commit.\n This is because I wanted the default merge handling, commit message,\netc for that part. Unfortunately, it's possible that this dragged in\na bunch of stuff I *didn't* want. It also makes git-subtree, which\notherwise could be used as plumbing, effectively into a porcelain.\n\nI don't really know what to do about that. You could introduce an\nabstraction level somewhere between commit-tree and commit, but surely\nsomeone would eventually find a case where that abstraction level is\nstill not right. To bring this around to the original topic of this\nthread, such an extra level of abstraction is equivalent to the\nsuggested --plumbing (or whatever) option, whether it's presented as\nan option or a separate command.\n\nHave fun,\n\nAvery\n"}]}