{"thread":{"id":"13037","subject":"git annoyances","startedAt":"2008-04-09T10:14:28Z","lastAt":"2008-04-23T11:15:56Z","messageCount":86,"participants":["Ingo Molnar","Björn Steinbrink","Jeff King","Johannes Schindelin","Avery Pennarun","Daniel Barkalow","Teemu Likonen","Junio C Hamano","Jon Loeliger","Nicolas Pitre","André Goddard Rosa","Jean-Christian de Rivaz","Sverre Rabbelier","Karl Hasselström","Govind Salinas","Gabriel","Christian Couder","Luciano Rocha","Wincent Colaiuta","Stephen Sinclair","Santiago Gala","Matt Graham","Miles Bader","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"73943","messageId":"20080409101428.GA2637@elte.hu","threadId":"13037","inReplyTo":null,"subject":"git annoyances","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-04-09T10:14:28Z","receivedAt":"2008-04-09T10:14:28Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\ni just had a rather annoying session with git - here's the dump and \ncommentary, in case anyone is interested in usability fineprint.\n\nit was with git-core-1.5.4.3-2.fc8 - so if it's all fixed/improved in \n1.5.5, or if this is blatant user error for which i deserve to be \npunished then my apologies!\n\nusually i just have a single git repo that tracks everything \ninteresting, but this time i did something i rarely do: i tried to merge \none local tree of mine into another local tree of mine. So i had no \ncommands (or even concepts) cached in my short-term memory that would \nachieve this goal, i just tried the commands that i thought to be \n'obvious', without applying much (or any) IQ to those commands:\n\n $ cd linux-2.6-sched-devel.git\n\n $ git-remote add ~/linux-2.6-x86.git\n\n $ git-remote show x86\n * remote x86\n URL: /home/mingo/linux-2.6-x86.git\n New remote branches (next fetch will store in remotes/x86)\n base for-akpm for-linus latest master testing\n\n $ git-merge x86/latest\n x86/latest - not something we can merge\n\n #\n # ho hum. Not something 'we' can merge. Do i care? :-) There's no \n # actionable reference given to the user about how to resolve this \n # problem. So i kept on trying:\n #\n\n $ git-fetch x86/latest\n fatal: 'x86/latest': unable to chdir or not a git archive\n fatal: The remote end hung up unexpectedly\n\n $ git-pull x86/latest\n fatal: 'x86/latest': unable to chdir or not a git archive\n fatal: The remote end hung up unexpectedly\n\n #\n # hm. two fatal messages, suggesting that there's something really \n # wrong while there's nothing wrong.\n #\n\nwhat got me going after experimenting around some more was this exact \ncommand:\n\n $ git-pull x86 latest\n\n(that fetch+merge went problem-free.)\n\nbut it was a PITA and all of git's messages about the problem were not \nonly unhelpful, they confused me into looking for problems where there \nwere none IMO. I was starting to wonder whether i have to have some git \ndaemon running on that box for example. But in retrospect IMO it was \nrather clear from the outset what i wanted git to do (merge the tip of \nmy other tree into the tip of this tree, on the local box, no frills), i \njust didnt figure out the exact command to do it.\n\nanother (minor) usability annoyance: one of the first things i tried was \nto verify the remote setup, via:\n\n$ git-remote show\n\nwhich gave me this answer:\n\n Usage: git remote show \n\nthen i tried git-remote show -a (to list all repositories, etc.) - what \ni didnt figure out was to show all repositories is to do a simple \n\"git-remote\". I think \"git-remote show\" should output all repositories, \nor at least indicate it in its help line what to do to get such a list. \n(for us poor sobs forgetting commandline details ;)\n\nalso, the first natural thing i did was to just type:\n\n $ git-merge ~/linux-2.6-x86.git/\n\nwhich i naively assumed would sort things out for me and provide some \nreasonable default behavior - but instead it just gave an annoyingly \nunhelpful error message:\n\n /home/mingo/linux-2.6-x86.git/ - not something we can merge\n\nthere should really be a consciously established \"route of failure \nresolution\" - directing people towards relevant sources of information \nor commands when the git command-line utilities return some error due to \nuser incompetence. Otherwise users just guess around and get frustrated.\n\nalso, i think this session also probably matches the newbie's experience \nabout git, and making certain git operations so hard to achieve is \ncertainly not a reassuring experience for them either. [ Or shall they \nall be filtered out as fundamentally incompetent people? ;-) ]\n\n\tIngo\n"},{"id":"73948","messageId":"20080409104125.GA16607@atjola.homenet","threadId":"13037","inReplyTo":"20080409101428.GA2637@elte.hu","subject":"Re: git annoyances","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-04-09T10:41:25Z","receivedAt":"2008-04-09T10:41:25Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.04.09 12:14:28 +0200, Ingo Molnar wrote:\n> \n> i just had a rather annoying session with git - here's the dump and \n> commentary, in case anyone is interested in usability fineprint.\n> \n> it was with git-core-1.5.4.3-2.fc8 - so if it's all fixed/improved in \n> 1.5.5, or if this is blatant user error for which i deserve to be \n> punished then my apologies!\n> \n> usually i just have a single git repo that tracks everything \n> interesting, but this time i did something i rarely do: i tried to merge \n> one local tree of mine into another local tree of mine. So i had no \n> commands (or even concepts) cached in my short-term memory that would \n> achieve this goal, i just tried the commands that i thought to be \n> 'obvious', without applying much (or any) IQ to those commands:\n> \n> $ cd linux-2.6-sched-devel.git\n> \n> $ git-remote add ~/linux-2.6-x86.git\n> \n> $ git-remote show x86\n> * remote x86\n> URL: /home/mingo/linux-2.6-x86.git\n> New remote branches (next fetch will store in remotes/x86)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nI gues that's key here. The remote was added, but you don't actually\nhave fetched the branches yet. Thus the merge fails, but the pull with\nthe correct syntax succeeded, because it does a fetch first.\n\n> base for-akpm for-linus latest master testing\n> \n> $ git-merge x86/latest\n> x86/latest - not something we can merge\n> \n> #\n> # ho hum. Not something 'we' can merge. Do i care? :-) There's no \n> # actionable reference given to the user about how to resolve this \n> # problem. So i kept on trying:\n> #\n\nNo branch, no merge ;-)\n\n> $ git-fetch x86/latest\n> fatal: 'x86/latest': unable to chdir or not a git archive\n> fatal: The remote end hung up unexpectedly\n> \n> $ git-pull x86/latest\n> fatal: 'x86/latest': unable to chdir or not a git archive\n> fatal: The remote end hung up unexpectedly\n> \n> #\n> # hm. two fatal messages, suggesting that there's something really \n> # wrong while there's nothing wrong.\n> #\n\nThe syntax is \"git pull \"\n\nSo you're trying to fetch/pull from a repository in \"x86/latest\", that\npath doesn't exist and that is pretty fatal as you cannot fetch/pull\nfrom a repository that doesn't exist.\n\n> what got me going after experimenting around some more was this exact \n> command:\n> \n> $ git-pull x86 latest\n> \n> (that fetch+merge went problem-free.)\n\nYeah, correct syntax and pull does the fetch for you.\n\n> also, the first natural thing i did was to just type:\n> \n> $ git-merge ~/linux-2.6-x86.git/\n> \n> which i naively assumed would sort things out for me and provide some \n> reasonable default behavior - but instead it just gave an annoyingly \n> unhelpful error message:\n> \n> /home/mingo/linux-2.6-x86.git/ - not something we can merge\n\nAFAIK merge cannot handle stuff that's outside your repo. To merge stuff\nfrom another repo without adding a remote, you have to use pull (or\nmanually do the fetch+merge dance), ie.:\n\ngit pull ~/linux-2.6-x86.git latest\n\nshould do.\n\nBjörn\n"},{"id":"73961","messageId":"20080409145758.GB20874@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080409101428.GA2637@elte.hu","subject":"Re: git annoyances","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-09T14:57:59Z","receivedAt":"2008-04-09T14:57:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 09, 2008 at 12:14:28PM +0200, Ingo Molnar wrote:\n\n> $ cd linux-2.6-sched-devel.git\n> \n> $ git-remote add ~/linux-2.6-x86.git\n> \n> $ git-remote show x86\n> * remote x86\n> URL: /home/mingo/linux-2.6-x86.git\n> New remote branches (next fetch will store in remotes/x86)\n> base for-akpm for-linus latest master testing\n> \n> $ git-merge x86/latest\n> x86/latest - not something we can merge\n\nAs you figured out later, the problem was that \"git remote add\" doesn't\nactually fetch the remote's contents: it just sets up the remote. There\nis a \"-f\" option which does the fetch automagically after adding.\n\nIn this case, had \"-f\" been the default, it would have Just Worked for\nyou. So that's something for us to consider, but I'm not sure if we\nwould annoy more users who _didn't_ want the fetch.\n\n> $ git-fetch x86/latest\n> fatal: 'x86/latest': unable to chdir or not a git archive\n> fatal: The remote end hung up unexpectedly\n\nThis is another place where we might have DWYM, by seeing that your\nrepository name started with \"/\" and splitting it into\n\" \". This could affect current usage, but it seems\nunlikely that people have remote names which are exact prefixes (with\ntrailing slash) of non-remote repositories they are trying to fetch.\n\nReading \"git help fetch\" should show you the synopsis:\n\n git-fetch \n\nwhich maybe gives a clue about the syntax. But I think the problem here\nis that there are two different syntaxes for what is _almost_ the same\nthing. The ref refs/remotes/x86/latest, which you can call \"x86/latest\"\nas a shorthand, and the (remote, refspec) pair (x86, latest).\n\n> $ git-pull x86 latest\n> \n> (that fetch+merge went problem-free.)\n\nUnless you are planning on merging this remote a lot, the common usage\nis probably to just forget the remote stuff and do:\n\n git pull ~/linux-2.6-x86.git latest\n\n> then i tried git-remote show -a (to list all repositories, etc.) - what \n> i didnt figure out was to show all repositories is to do a simple \n> \"git-remote\". I think \"git-remote show\" should output all repositories, \n> or at least indicate it in its help line what to do to get such a list. \n> (for us poor sobs forgetting commandline details ;)\n\nYes, just showing the remotes would be consistent with what other\ncommands do (e.g., git-branch, git-tag). I'll post a patch in a minute.\n\n> also, the first natural thing i did was to just type:\n> \n> $ git-merge ~/linux-2.6-x86.git/\n> \n> which i naively assumed would sort things out for me and provide some \n> reasonable default behavior - but instead it just gave an annoyingly \n> unhelpful error message:\n> \n> /home/mingo/linux-2.6-x86.git/ - not something we can merge\n\nThat is an annoying message. Perhaps we could notice that it looks like\na file path (because it begins with '.') and suggest \"maybe you wanted\nto \"git pull ...\"?\n\n-Peff\n"},{"id":"73964","messageId":"20080409151551.GA30439@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080409145758.GB20874@sigill.intra.peff.net","subject":"[PATCH] git-remote: show all remotes with \"git remote show\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-09T15:15:51Z","receivedAt":"2008-04-09T15:15:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Many other commands use the \"no arguments\" form to show a\nlist (e.g., git-branch, git-tag). While we did show all\nremotes for just \"git remote\", we displayed a usage error\nfor \"git remote show\" with no arguments. This is\ncounterintuitive, since by giving it _more_ information, we\nget _less_ result.\n\nThe usage model can now be thought of as:\n\n - \"git remote show \": show a remote\n - \"git remote show\": show all remotes\n - \"git remote\": assume \"show\"; i.e., shorthand for \"git remote show\"\n\nSigned-off-by: Jeff King \n---\nOn Wed, Apr 09, 2008 at 10:57:58AM -0400, Jeff King wrote:\n\n> > then i tried git-remote show -a (to list all repositories, etc.) - what \n> > i didnt figure out was to show all repositories is to do a simple \n> > \"git-remote\". I think \"git-remote show\" should output all repositories, \n> > or at least indicate it in its help line what to do to get such a list. \n> > (for us poor sobs forgetting commandline details ;)\n> \n> Yes, just showing the remotes would be consistent with what other\n> commands do (e.g., git-branch, git-tag). I'll post a patch in a minute.\n\nAnd here it is.\n\n builtin-remote.c | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex d77f10a..06d33e5 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -19,6 +19,8 @@ static const char * const builtin_remote_usage[] = {\n \n static int verbose;\n \n+static int show_all(void);\n+\n static inline int postfixcmp(const char *string, const char *postfix)\n {\n \tint len1 = strlen(string), len2 = strlen(postfix);\n@@ -380,8 +382,11 @@ static int show_or_prune(int argc, const char **argv, int prune)\n \n \targc = parse_options(argc, argv, options, builtin_remote_usage, 0);\n \n-\tif (argc < 1)\n+\tif (argc < 1) {\n+\t\tif (!prune)\n+\t\t\treturn show_all();\n \t\tusage_with_options(builtin_remote_usage, options);\n+\t}\n \n \tmemset(&states, 0, sizeof(states));\n \tfor (; argc; argc--, argv++) {\n-- \n1.5.5.1.g272c\n"},{"id":"73965","messageId":"alpine.DEB.1.00.0804091754170.2074@eeepc-johanness","threadId":"13037","inReplyTo":"20080409151551.GA30439@sigill.intra.peff.net","subject":"Re: [PATCH] git-remote: show all remotes with \"git remote show\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-09T16:54:45Z","receivedAt":"2008-04-09T16:54:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 9 Apr 2008, Jeff King wrote:\n\n> Many other commands use the \"no arguments\" form to show a\n> list (e.g., git-branch, git-tag). While we did show all\n> remotes for just \"git remote\", we displayed a usage error\n> for \"git remote show\" with no arguments. This is\n> counterintuitive, since by giving it _more_ information, we\n> get _less_ result.\n> \n> The usage model can now be thought of as:\n> \n> - \"git remote show \": show a remote\n> - \"git remote show\": show all remotes\n> - \"git remote\": assume \"show\"; i.e., shorthand for \"git remote show\"\n> \n> Signed-off-by: Jeff King \n\nAcked-by: Johannes Schindelin \n\nCiao,\nDscho\n"},{"id":"73968","messageId":"32541b130804091008h1a757552o14dd8e937ed19058@mail.gmail.com","threadId":"13037","inReplyTo":"20080409145758.GB20874@sigill.intra.peff.net","subject":"Re: git annoyances","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-04-09T17:08:39Z","receivedAt":"2008-04-09T17:08:39Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Apr 9, 2008 at 10:57 AM, Jeff King wrote:\n> > $ git-fetch x86/latest\n[...]\n> git-fetch \n[...]\n> > $ git-pull x86 latest\n[...]\n> git pull ~/linux-2.6-x86.git latest\n\nMy co-workers frequently get confused by this too. The problem is\nthat \"x86/latest\" is a locally existing remote branch ref, while \"x86\nlatest\" is supposed to be a branch ref on a remote system.\n\nI think the real problem here is that you can't refer to a\nremote+branch as a single \"word\". If you could, then people could\njust learn to use that everywhere and never get confused.\n\nFor example, in svn you can talk about\nsvn+ssh://reposerver/path/to/repo/branches/foo@1234; it's a single\n\"word\" that refers to a particular revision on a particular branch of\na particular server. It therefore makes sense to talk about copying\nfrom one branch to another, etc, using exactly one word for the source\nand one for the destination.\n\nImagine if \"git pull ~/linux/2.6-x86.git:latest\" would work; then it\ncould mean exactly the same thing as \"git merge\n~/linux/2.6-x86.git:latest\" (which would presumably switch to 'pull'\nmode automatically). Or even \"git diff master..x86:latest\", which\ncould diff my local master with an auto-fetched x86:latest.\n\nNaturally we'd have to find a new punctuation mark for this, since all\nthe obvious ones are already used :)\n\nHave fun,\n\nAvery\n"},{"id":"73971","messageId":"alpine.LNX.1.00.0804091442190.19665@iabervon.org","threadId":"13037","inReplyTo":"20080409101428.GA2637@elte.hu","subject":"Re: git annoyances","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-04-09T19:21:04Z","receivedAt":"2008-04-09T19:21:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 9 Apr 2008, Ingo Molnar wrote:\n\n> \n> i just had a rather annoying session with git - here's the dump and \n> commentary, in case anyone is interested in usability fineprint.\n> \n> it was with git-core-1.5.4.3-2.fc8 - so if it's all fixed/improved in \n> 1.5.5, or if this is blatant user error for which i deserve to be \n> punished then my apologies!\n> \n> usually i just have a single git repo that tracks everything \n> interesting, but this time i did something i rarely do: i tried to merge \n> one local tree of mine into another local tree of mine. So i had no \n> commands (or even concepts) cached in my short-term memory that would \n> achieve this goal, i just tried the commands that i thought to be \n> 'obvious', without applying much (or any) IQ to those commands:\n> \n> $ cd linux-2.6-sched-devel.git\n> \n> $ git-remote add ~/linux-2.6-x86.git\n> \n> $ git-remote show x86\n> * remote x86\n> URL: /home/mingo/linux-2.6-x86.git\n> New remote branches (next fetch will store in remotes/x86)\n> base for-akpm for-linus latest master testing\n\nGood so far.\n\n> $ git-merge x86/latest\n> x86/latest - not something we can merge\n\nGit is missing the fact that, while refs/remotes/x86/latest doesn't exist, \nthere is a fetch rule that would create it. It should suggest \"git fetch \nx86\" or \"git fetch x86 latest\". This is a bit tricky, because you've used \na shorthand for something that doesn't exist, so there isn't a unique \nanswer for which full name you're looking for, but there is a unique \nsolution (in this case) for which one could be created by a pattern you \nhave.\n\n> #\n> # ho hum. Not something 'we' can merge. Do i care? :-) There's no \n> # actionable reference given to the user about how to resolve this \n> # problem. So i kept on trying:\n> #\n> \n> $ git-fetch x86/latest\n> fatal: 'x86/latest': unable to chdir or not a git archive\n> fatal: The remote end hung up unexpectedly\n\nThe right error message here would probably be:\n\n/home/mingo/linux-2.6-sched-devel.git/x86/latest: No such file or directory\n\nThat should at least tell you what git thinks, incorrectly, that you want \nit to do, and why it doesn't work.\n\n> what got me going after experimenting around some more was this exact \n> command:\n> \n> $ git-pull x86 latest\n> \n> (that fetch+merge went problem-free.)\n> \n> but it was a PITA and all of git's messages about the problem were not \n> only unhelpful, they confused me into looking for problems where there \n> were none IMO. I was starting to wonder whether i have to have some git \n> daemon running on that box for example. But in retrospect IMO it was \n> rather clear from the outset what i wanted git to do (merge the tip of \n> my other tree into the tip of this tree, on the local box, no frills), i \n> just didnt figure out the exact command to do it.\n> \n> another (minor) usability annoyance: one of the first things i tried was \n> to verify the remote setup, via:\n> \n> $ git-remote show\n> \n> which gave me this answer:\n> \n> Usage: git remote show \n> \n> then i tried git-remote show -a (to list all repositories, etc.) - what \n> i didnt figure out was to show all repositories is to do a simple \n> \"git-remote\". I think \"git-remote show\" should output all repositories, \n> or at least indicate it in its help line what to do to get such a list. \n> (for us poor sobs forgetting commandline details ;)\n> \n> also, the first natural thing i did was to just type:\n> \n> $ git-merge ~/linux-2.6-x86.git/\n> \n> which i naively assumed would sort things out for me and provide some \n> reasonable default behavior - but instead it just gave an annoyingly \n> unhelpful error message:\n> \n> /home/mingo/linux-2.6-x86.git/ - not something we can merge\n> \n> there should really be a consciously established \"route of failure \n> resolution\" - directing people towards relevant sources of information \n> or commands when the git command-line utilities return some error due to \n> user incompetence. Otherwise users just guess around and get frustrated.\n\nI'm not sure we can figure out what the user actually meant in this case; \nthere's just too much overlap in namespaces to determine reliably that you \nwere giving it a remote repository on the local filesystem rather than \nanything else.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"73975","messageId":"20080409200708.GB18968@elte.hu","threadId":"13037","inReplyTo":"20080409151551.GA30439@sigill.intra.peff.net","subject":"Re: [PATCH] git-remote: show all remotes with \"git remote show\"","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-04-09T20:07:08Z","receivedAt":"2008-04-09T20:07:08Z","isPatch":true,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Jeff King wrote:\n\n> Many other commands use the \"no arguments\" form to show a\n> list (e.g., git-branch, git-tag). While we did show all\n> remotes for just \"git remote\", we displayed a usage error\n> for \"git remote show\" with no arguments. This is\n> counterintuitive, since by giving it _more_ information, we\n> get _less_ result.\n> \n> The usage model can now be thought of as:\n> \n> - \"git remote show \": show a remote\n> - \"git remote show\": show all remotes\n> - \"git remote\": assume \"show\"; i.e., shorthand for \"git remote show\"\n> \n> Signed-off-by: Jeff King \n\ncool, thanks!\n\n\tIngo\n"},{"id":"73977","messageId":"20080409200836.GA19248@mithlond","threadId":"13037","inReplyTo":"20080409145758.GB20874@sigill.intra.peff.net","subject":"Friendly refspecs (Was: Re: git annoyances)","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-09T20:08:36Z","receivedAt":"2008-04-09T20:08:36Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Jeff King wrote (2008-04-09 10:57 -0400):\n\n> git-fetch \n\nI have found this refs/heads/*:refs/remotes/* stuff quite confusing, but\nI'm starting to understand them. I know my way with them but still they\nseem quite unnecessary hackerish. Pull and push work pretty nicely\nwithout knowing about any refs/* stuff; they can be operated with simple\nbranch names. Fetch is another story. Some ideas:\n\n $ git fetch \n\nwould be equivalent to\n\n $ git fetch +refs/heads/*:refs/remotes//*\n\nIn other words, fetch all the branches from remote repo and store them\nlocally as remote tracking branches to / hieararchy. The is\nthe last component taken from the (maybe \"origin\" if it can't be\ndetected). \n\nCurrently \"git fetch \" does not seem to do anything useful for\nnon-git-hackers. It seems to fetch objects but not create any branches\nreferring to them. As a comparison, let's configure a remote and run\nsimilar fetch command without any refspecs explicitly named:\n\n $ git remote add \n $ git fetch \n\nNow this fetch really creates all the branches (as defined in\nremote..fetch) which is nice and the way Git currently works.\n\nSo would it be any good if \"git fetch \" without refpecs would use\n+refs/heads/*:refs/remotes//* ? In any case the current behaviour\nseems quite unfriendly.\n\nSome more ideas for simple refspecs:\n\n $ git fetch \n\nwould be equivalent to\n\n $ git fetch +refs/heads/:refs/remotes//\n\nAgain the same behaviour with and configured remote . In the\n case the is the last component of the .\n\n $ git fetch :\n\nwould be equivalent to\n\n $ git fetch +refs/heads/:refs/remotes/\n\nNote that by giving the destination branch (the right side of colon) the\nnew remote tracking branch would be created directly to the\nrefs/remotes/ hierarchy, not to refs/remotes// hierarchy like in\nprevious examples. This lets user a bit more control as she decided to\ngive explicitly. User may want to give refspec\nmaster:/master to have new branch created as\nrefs/remotes//master.\n\nWith above example commands it is not possible to fetch remote branches\nand store refs locally to refs/heads/ hierarchy. For this it would\neither need another step - \"git branch my-branch /master\" - or use\nthe long refspec form with fetch:\n+refs/heads/master:refs/heads/my-branch .\n\nDoes this sound any good?\n"},{"id":"73980","messageId":"32541b130804091332g539037d9x7f135a27ec25b888@mail.gmail.com","threadId":"13037","inReplyTo":"20080409200836.GA19248@mithlond","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-04-09T20:32:09Z","receivedAt":"2008-04-09T20:32:09Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Wed, Apr 9, 2008 at 4:08 PM, Teemu Likonen wrote:\n> So would it be any good if \"git fetch \" without refpecs would use\n> +refs/heads/*:refs/remotes//* ? In any case the current behaviour\n> seems quite unfriendly.\n\nBut what should be if you didn't provide it by doing\ngit-remote-add? I think the lack of an obvious name for them is\nexactly why the branch names don't get created automatically.\n\nAvery\n"},{"id":"73981","messageId":"20080409203453.GA10370@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080409200836.GA19248@mithlond","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-09T20:34:54Z","receivedAt":"2008-04-09T20:34:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 09, 2008 at 11:08:36PM +0300, Teemu Likonen wrote:\n\n> seem quite unnecessary hackerish. Pull and push work pretty nicely\n> without knowing about any refs/* stuff; they can be operated with simple\n> branch names. Fetch is another story. Some ideas:\n> \n> $ git fetch \n> \n> would be equivalent to\n> \n> $ git fetch +refs/heads/*:refs/remotes//*\n> \n> In other words, fetch all the branches from remote repo and store them\n> locally as remote tracking branches to / hieararchy. The is\n> the last component taken from the (maybe \"origin\" if it can't be\n> detected).\n\nThis has been discussed before and rejected, because the point of doing\na fetch of a URL (rather than a remote name) is to do a \"one-off\" thing.\nIOW, you don't _want_ the tracking branches, as they will just clutter\nyour branch space (plus choosing the last component is a bad heuristic;\nlots of people must ask Linus to pull from their .../linux-2.6\nrepository).\n\nAlmost nobody says \"git fetch \"; it is just a subpart of \"git\npull \" which is intended for one-off merges (i.e., you are not\ntracking somebody over the long term, you just want to grab their work\nand merge it).\n\n> Currently \"git fetch \" does not seem to do anything useful for\n> non-git-hackers. It seems to fetch objects but not create any branches\n> referring to them. As a comparison, let's configure a remote and run\n\nIt does; it puts the refs into FETCH_HEAD. Maybe a status table like the\nusual one would be more informative, like:\n\n From git://host/path/to/repo\n * [new branch] foo -> FETCH_HEAD\n\nthough again, it would help if we could see a workflow that uses \"git\nfetch \" for something. I think the simplest answer in your case is\n\"don't use git fetch \".\n\n> similar fetch command without any refspecs explicitly named:\n> \n> $ git remote add \n> $ git fetch \n> \n> Now this fetch really creates all the branches (as defined in\n> remote..fetch) which is nice and the way Git currently works.\n\nSure. There is an explicit design decision that \"because you gave this\nthing a nickname, you are probably interested in keeping its tracking\nbranches around.\"\n\n> Some more ideas for simple refspecs:\n> \n> $ git fetch \n> \n> would be equivalent to\n> \n> $ git fetch +refs/heads/:refs/remotes//\n\nIt would probably be nice if \"git fetch name foo\" saved the remote\ntracking branch remotes/name/foo, which it doesn't currently. But\nwhether to do it with a URL is orthogonal; it depends on whether we use\ntracking branches for URLs in general, as you suggested above.\n\n> $ git fetch :\n> \n> would be equivalent to\n> \n> $ git fetch +refs/heads/:refs/remotes/\n\nWe almost have that. It's actually spelled:\n\n git fetch :remotes/\n\nBut again, what is the workflow? There are generally two ways of\nfetching:\n\n 1. I am tracking some remote with multiple branches. I give it a\n remote name (either by editing the config file or by using\n git-remote). When i want to get updates, I do \"git fetch \",\n and then I can work with the /* branches as I want (diffing,\n merging, etc).\n\n 2. \"Somehow\" I found out about something interesting in a particular\n branch of a particular repo. I want to pull that in to see the\n work, so I use \"git pull \". Alternatively, if I\n prefer to fetch and examine before pulling (even though the merge\n can of course be cancelled easily), I can \"git fetch \n \", followed by \"git diff HEAD FETCH_HEAD\", followed by \"git\n merge FETCH_HEAD\".\n\nIt seems like you are getting caught up on using \"git fetch\" in\ndifferent ways that don't really make sense to its original use. So the\nproblem is not so much one of \"fetch doesn't do what I want it to do\" as\nmuch as \"it is easy to be confused about what it is I want to do.\"\n\n-Peff\n"},{"id":"73983","messageId":"20080409204149.GC18968@elte.hu","threadId":"13037","inReplyTo":"alpine.LNX.1.00.0804091442190.19665@iabervon.org","subject":"Re: git annoyances","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-04-09T20:41:49Z","receivedAt":"2008-04-09T20:41:49Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Daniel Barkalow wrote:\n\n> > also, the first natural thing i did was to just type:\n> > \n> > $ git-merge ~/linux-2.6-x86.git/\n> > \n> > which i naively assumed would sort things out for me and provide \n> > some reasonable default behavior - but instead it just gave an \n> > annoyingly unhelpful error message:\n> > \n> > /home/mingo/linux-2.6-x86.git/ - not something we can merge\n> > \n> > there should really be a consciously established \"route of failure \n> > resolution\" - directing people towards relevant sources of \n> > information or commands when the git command-line utilities return \n> > some error due to user incompetence. Otherwise users just guess \n> > around and get frustrated.\n> \n> I'm not sure we can figure out what the user actually meant in this \n> case; there's just too much overlap in namespaces to determine \n> reliably that you were giving it a remote repository on the local \n> filesystem rather than anything else.\n\nwell, current git got to /home/mingo/linux-2.6-x86.git/ which is a local \npath. (it is printing it in the error message above) So i think it was \nrather unambiguous what i meant and Git knew about it, right?\n\nbut even if it _was_ ambiguous, i think tools should generally default \nto a minimal amount of hassle for new users and should try to pick \nreasonable \"action\" versus any \"inaction\". (as long as the behavior is \nstill deterministic and reasonable even to the long-time user)\n\nbut more importantly, i think this whole problem area has to be handled \nwith a slightly different kind of mindset than other, more technical \naspects of Git.\n\nHumans, and in particular males, when they see or learn new things, are \nvery emotion-driven. The first 1-2 minutes (often just the first few \nseconds) have a very strong influence on whether that person 'likes' a \nnew topic, tool or gizmo he is checking out - or not. Males often think \nof themselves as being objective when shopping new items - while in \nreality more than 90% of their purchasing decisions are emotion-driven \nand it's all set and done in the first 10 seconds of visual contact. \n(this ration is far higher than for females)\n\nCommand-line tools like Git are at heavy natural disadvantage compared \nto say GUI tools because the \"first impression\" is so minimalistic and \nrelatively unremarkable. A GUI can get people hooked by making the first \n10% look easy just via old-fashioned, dishonest visual deception.\n\nso basically for 90% of the new users, we've got 2-3 shots or we lose \ntheir \"sympathy\". Starting with an error message is bad. Being \nuninformative about what happened is bad. Making the user wait without \nsignalling why he is waiting is bad. Etc. etc. I think this experience \nof mine was a reasonable simulation of a first-time user reaction (by \nvirtue of me having forgotten certain Git details).\n\nAnd the moment a negative first-time impression has settled in it's very \nhard to overcome that emotional mindset and barrier. People might still \nthink \"Git is quirky\" even if we do all things perfectly from that point \non. The same holds for the other direction: a positive first-time \nimpression is harder to destroy, even if it turns out to be not that \nsimple later on.\n\nA tool's reaction back to first-time users is like a decision tree: \nevery negative reaction, every error message, every unreasonable wait, \nevery uninformative output is a way for the user to exit our ecosystem \nand to never discover the true strengths of Git.\n\nSo i really think that maintaining this aspect of Git and in essence \nHuffman-optimizing the interface and the learning curve for first-time \nGit users is perhaps the most important thing. Especially since some \nusers like me will often re-learn Git details that they use rarely.\n\nGetting these details right is _extremely hard_, because the people who \nare capable of fixing these details have long forgotten the first-time \nannoyances they had! (if they had any - often developers are \nstatistically lucky and never hit any pitfalls.)\n\nIt's doubly hard because Git developers work on Git exactly because they \n_like_ it, so one's own positive experience has to be contrasted to the \nprospect of negative first-time experience.\n\nIt's triple hard because it might also mean changing some things that \nhave been done in Git since the start of the project. A negative \nexperience that isnt some technical problem in the strict sense - it's \nan emotional thing that is much harder to define and much harder to \nagree on and improve.\n\nSo i think it's really hard mentally - and i'm positively surprised by \nthe many constructive and positive reactions that my mail generated.\n\nImproving this area is perhaps even harder than adding new functionality \n- but i think it's a key and extremely strategic aspect of Git, because \nit affects the very heart of the Git project: it maximizes the influx of \nnew users (who also include future Git developers btw.) and minimizes \noutflux of existing users.\n\n\tIngo\n"},{"id":"73984","messageId":"7vfxtu3fku.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080409101428.GA2637@elte.hu","subject":"Re: git annoyances","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-09T21:04:33Z","receivedAt":"2008-04-09T21:04:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ingo Molnar writes:\n\n> i just had a rather annoying session with git - here's the dump and \n> commentary, in case anyone is interested in usability fineprint.\n\nThanks. It is always enlightening to see this kind of walkthru session to\nlearn where the UI warts are. The ones with concrete suggestions for\nimprovements are even more appreciated.\n\n> usually i just have a single git repo that tracks everything \n> interesting, but this time i did something i rarely do: i tried to merge \n> one local tree of mine into another local tree of mine. So i had no \n> commands (or even concepts) cached in my short-term memory that would \n> achieve this goal, i just tried the commands that i thought to be \n> 'obvious', without applying much (or any) IQ to those commands:\n>\n> $ cd linux-2.6-sched-devel.git\n>\n> $ git-remote add ~/linux-2.6-x86.git\n\nYou told git that \"I'll interact with this other repository from now on,\nso please help me with some extra settings to do so. Namely I do not want\nto keep typing it in full URL all the time so I want an abbreviated way to\ntell you I am talking about this remote repository, and also I want to\nhave set of remote tracking branches for this one\".\n\nMaybe \"remote add\" is not quite the right name to convey the above\nconcept.\n\n> $ git-remote show x86\n> * remote x86\n> URL: /home/mingo/linux-2.6-x86.git\n> New remote branches (next fetch will store in remotes/x86)\n> base for-akpm for-linus latest master testing\n\nSo the command did as you told it to.\n\n> $ git-merge x86/latest\n> x86/latest - not something we can merge\n\nYou told git \"I want to merge a commit into the current branch, and that\ncommit is called x86/latest\". Alas, no such commit exists in your\nrepository (yet). Should we be saying \"no such commit exists, you need to\nfetch it from elsewhere first\"?\n\n> $ git-fetch x86/latest\n> fatal: 'x86/latest': unable to chdir or not a git archive\n> fatal: The remote end hung up unexpectedly\n\n\"Not a git archive\" should be clear enough. You already said \"remote show\nx86\" correctly above, and it makes me wonder why you are now saying\n\"x86/latest\", not \"x86\" without \"latest\".\n\nIn other words, \"git fetch x86\".\n\nWith that, you would tell git \"Hey, I've already told you what I want you\nto do with this short-hand name \"x86\". It is the name for the long URL\nI've previously given you and I want you to fetch from that repository,\nand I want its branches to be stored in remote tracking branches in my\nrepository\".\n\nBut you didn't. You are not taking advantage of your previous \"git remote\nadd\".\n\nI am suspecting that a cause of this confusion is partly because earlier\nin 1.3.0 days we tried to make things easy for CVS migrants where they\nalways interact with a single \"upstream\" repository and with _the_ single\nbranch, and we were _too_ successful in doing so.\n\nThat made us allowing the users to type \"git pull\" and \"git fetch\" without\nparameters. This is generally a good thing: shorter to type for doing\ncommon things is always good, as long as the user knows what he is doing.\n\nBut at the same time, this allowed docs and cheat-sheets that mention only\nthe form without parameters and not the normative \"repository refspec\"\nform. This dumbed down the users not understand that in that context\nfetch (and pull, which is a fetch followed by a merge) is always happening\nagainst a single branch of single remote repository, the way to name\nremote repository and its branch(es) is to give them as separate\nparameters, and their not typing the pair explicitly is a mere convenience\nfeature. This particular aspect of the shorthand is actually very bad.\nIt makes the mental model fuzzy, and hiding important rules of how the\nworld works from new people would lead them to unnecessary confusion. In\nshort, we made it harder for the new people to \"get\" it.\n\nThe introductory documents may need to be updated to teach explicit \"git\npull $repo $branch\" form first, and if they are short documents, end in\nintroductory phase and leave the remainder to \"further reading\", they\nshould probably be fixed not talk about the shorthand form \"git pull\n$nick\" and \"git pull\" without parameters at all. That may help fixing\nthis mental-model breakdown.\n\n> $ git-pull x86 latest\n>\n> (that fetch+merge went problem-free.)\n\nYes.\n\nBecause git is distributed, a branch in the global scope is named with a\npair \"remote\" and \"branch\" as two separate parameters, and we consistently\ndo so. Always. Just like you are supposed to say in your \"Linus, please\npull\" requests (e.g. http://article.gmane.org/gmane.linux.kernel/321590).\n\n> but it was a PITA and all of git's messages about the problem were not \n> only unhelpful, they confused me into looking for problems where there \n> were none IMO.\n\nYes, we need to teach \"git\" to do more mind-reading (I am not being\nsarcastic). There should be a pattern in common user errors that share\ntheir roots to the same user misperception, and if we can identify that,\nmaybe we can make git guess what the user was really trying to do and give\nbetter error messages than it currently does.\n\n> also, the first natural thing i did was to just type:\n>\n> $ git-merge ~/linux-2.6-x86.git/\n>\n> which i naively assumed would sort things out for me and provide some \n> reasonable default behavior - but instead it just gave an annoyingly \n> unhelpful error message:\n>\n> /home/mingo/linux-2.6-x86.git/ - not something we can merge\n\nI'd agree that it is fair to get frustrated with this.\n\nWe actually did not have \"git merge\" as the first level UI citizen for\nquite some time, and the way to merge in _anything_ was done with \"git\npull\", even within the local repository. If you did not know \"git merge\"\nexisted, the above would have been either one of\n\n\t$ git pull ~/linux-2.6-x86.git/\n\t$ git pull ~/linux-2.6-x86.git/ master\n\nand would have been nicer. But people wanted \"git merge\" which is a\npurely local operation, which made (and still does makes) sense. But now\npeople need to know two different commands, one that works globally and\nthe other that works locally.\n\nC.f.\n\n http://thread.gmane.org/gmane.comp.version-control.git/10778/focus=10900\n http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31528\n http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31490\n\n> there should really be a consciously established \"route of failure \n> resolution\" - directing people towards relevant sources of information \n> or commands when the git command-line utilities return some error due to \n> user incompetence. Otherwise users just guess around and get frustrated.\n\nYes, I called it mind-reading above, but we are wishing for the same\nthing.\n\nby the way, because you already paid for your Shift keys, you might want\nto use it consistently to enhance readability. i find it somewhat\nirritating not to be able to tell where each sentence begins with enough\nvisual cues (i.e. full-stop, two spaces and initial capital letter) and\nfirst person subject not spelled with capital letter i.\n"},{"id":"73986","messageId":"7vabk23esz.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080409200836.GA19248@mithlond","subject":"Re: Friendly refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-09T21:21:16Z","receivedAt":"2008-04-09T21:21:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Teemu Likonen writes:\n\n[By the way, please never redirect the response to your messages away from\nyou with:\n\n Mail-Followup-To: Jeff King , Ingo Molnar ,\n git@vger.kernel.org\n\nYou wasted 30 seconds of my (and anybody who potentially wanted to give\nadvice to you) time by forcing me fix the To: header while composing this\nresponse. I know Jeff understands what I am going to mention, and I do\nnot want to waste his time by putting him on To: header.]\n\n> Currently \"git fetch \" does not seem to do anything useful for\n> non-git-hackers. It seems to fetch objects but not create any branches\n> referring to them.\n\nI'd suggest you to study:\n\n http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31634\n\nNot everybody wants remote tracking.\n"},{"id":"73988","messageId":"47FD37A7.6030404@freescale.com","threadId":"13037","inReplyTo":"7vfxtu3fku.fsf@gitster.siamese.dyndns.org","subject":"Re: git annoyances","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2008-04-09T21:39:51Z","receivedAt":"2008-04-09T21:39:51Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"Junio C Hamano wrote:\n>\n\n> The introductory documents may need to be updated to teach explicit \"git\n> pull $repo $branch\" form first,\n\nHey Junio,\n\nI'm hearing you here! :-)\n\nI think a furtherance of this notion is to\nteach \"git fetch ; git merge\" before \"git pull\".\n\nThanks,\njdl\n"},{"id":"73989","messageId":"20080409214504.GA11110@sigill.intra.peff.net","threadId":"13037","inReplyTo":"7vfxtu3fku.fsf@gitster.siamese.dyndns.org","subject":"Re: git annoyances","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-09T21:45:04Z","receivedAt":"2008-04-09T21:45:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 09, 2008 at 02:04:33PM -0700, Junio C Hamano wrote:\n\n> The introductory documents may need to be updated to teach explicit \"git\n> pull $repo $branch\" form first, and if they are short documents, end in\n> introductory phase and leave the remainder to \"further reading\", they\n> should probably be fixed not talk about the shorthand form \"git pull\n> $nick\" and \"git pull\" without parameters at all. That may help fixing\n> this mental-model breakdown.\n\nFor me personally, I think this bottom-up approach makes the most sense\nto learning (this may look familiar from the commit message to a patch I\nsent earlier):\n\n 1. here is what \"git pull $repo $branch\" means\n 2. here is a way to shorten it to \"git pull $repo\" (set up remote\n $repo)\n 3. here is a way to shorten it to \"git pull\" (default to origin)\n\nBut I think there are people who will get to the list and say \"why\ndidn't you just tell me 'git pull' in the first place?\" That is, the\ncomplaints we have seen in the past reveal _too many_ low level details\ntoo quickly.\n\nMaybe we have stepped too far towards \"top down workflow\ndescriptions\" and need to go back. I dunno.\n\nAnother way of thinking about it is that we need two sets of\ndocumentation with the same information (heresy, I know!): one bottom-up\nand one top-down. I think the manpages tend to be \"bottom up\"\nreferences. Bruce's user manual is more \"top down\" describing workflows.\nI wonder which one(s) Ingo read, and which helped the most.\n\n-Peff\n"},{"id":"73992","messageId":"20080409222500.GB19248@mithlond","threadId":"13037","inReplyTo":"20080409203453.GA10370@sigill.intra.peff.net","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-09T22:25:00Z","receivedAt":"2008-04-09T22:25:00Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Jeff King wrote (2008-04-09 16:34 -0400):\n\n> On Wed, Apr 09, 2008 at 11:08:36PM +0300, Teemu Likonen wrote:\n\n> > $ git fetch \n> > \n> > would be equivalent to\n> > \n> > $ git fetch +refs/heads/*:refs/remotes//*\n\n> This has been discussed before and rejected, because the point of\n> doing a fetch of a URL (rather than a remote name) is to do\n> a \"one-off\" thing.\n\nFirst, thank you for such a detailed information and giving somewhat\ndifferent point of view from mine.\n\nOk, \"git fetch \" has its own \"point\", as you noted, and no doubt\nit's for good reasons. I just had partially misunderstood its point. See\nbelow:\n\n> Almost nobody says \"git fetch \"; it is just a subpart of \"git\n> pull \" [...]\n\nHmm, maybe. I recently wanted to join two purely local repos together.\nBoth of them had just one branch. Totally different histories so no\nactual mergin would happen; just two branches in the same repo. I don't\nknow why but \"git fetch /the/other/repo/\" just happened to be the one\nI tried first. I saw it fetched something but as no new branch appeared\nand I had never heard of this FETCH_HEAD thing it was a \"didn't work,\nwhat should I try next?\" thing. I think your idea of showing\n\n> From git://host/path/to/repo\n> * [new branch] foo -> FETCH_HEAD\n\nwould be really good. At least to me this would have been enough\ninformation. As I'm starting to see the \"point of doing fetch \"\nI take back what I proposed. Just a bit more information would be nice.\n\nI have to agree with Ingo Molnar that sometimes Git is a bit un- or even\ndisinformative about what happened. One example is this \"git fetch\n\". Maybe it's not a \"sane thing to do\" but users are like this. We\njust try something and learn from it. To me \"git fetch \" was\na broken command (UI-wise) until I read your message (thanks again!). If\nGit had told me that it created FETCH_HEAD I had learned fetch's habits\nmyself and likely wouldn't have come up with this \"broken command\"\nconclusion.\n\nAnother thing I spoke of was this refs/ stuff. I know my way around with\nthem now, so maybe they are not actually confusing to me anymore. It's\njust that I have noticed a pattern: I always use refs/heads/... in\ncertain places and refs/remotes/ in certain places. If such a pattern is\nvery common (well, I don't know if it is) one starts to think that maybe\nthe pattern can/should be hidden and made part of the tool. Just\nthoughts.\n"},{"id":"73993","messageId":"20080409225112.GB12103@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080409222500.GB19248@mithlond","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-09T22:51:12Z","receivedAt":"2008-04-09T22:51:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 10, 2008 at 01:25:00AM +0300, Teemu Likonen wrote:\n\n> Hmm, maybe. I recently wanted to join two purely local repos together.\n> Both of them had just one branch. Totally different histories so no\n> actual mergin would happen; just two branches in the same repo. I don't\n> know why but \"git fetch /the/other/repo/\" just happened to be the one\n> I tried first. I saw it fetched something but as no new branch appeared\n> and I had never heard of this FETCH_HEAD thing it was a \"didn't work,\n> what should I try next?\" thing. I think your idea of showing\n\nAh, OK. In that case, I think the right thing to do would not be to set\nup a remote, but to fetch explicitly into a local branch. I assume when\nyou say \"joining\" you mean \"so I can get rid of the individual ones\".\nSo something like:\n\n cd repo1\n git fetch ../repo2 master:repo2-topic\n\nwhich creates refs/heads/repo2 in repo1, and you can safely delete\nrepo2.\n\nIf you _did_ want to keep repo2 around indefinitely, and you are\n\"joining\" so that you can do diffs, then you probably do want a remote\nwith tracking branches.\n\n cd repo1\n git remote add repo2 ../repo2\n git fetch repo2\n git diff repo2/master...master\n\n> > From git://host/path/to/repo\n> > * [new branch] foo -> FETCH_HEAD\n> \n> would be really good. At least to me this would have been enough\n> information. As I'm starting to see the \"point of doing fetch \"\n> I take back what I proposed. Just a bit more information would be nice.\n\nI wonder if people like Linus who do a lot of one-off pulls would find\nthat too cluttery. I guess we can post a patch and see. ;)\n\n> I have to agree with Ingo Molnar that sometimes Git is a bit un- or even\n> disinformative about what happened. One example is this \"git fetch\n> \". Maybe it's not a \"sane thing to do\" but users are like this. We\n> just try something and learn from it. To me \"git fetch \" was\n> a broken command (UI-wise) until I read your message (thanks again!). If\n> Git had told me that it created FETCH_HEAD I had learned fetch's habits\n> myself and likely wouldn't have come up with this \"broken command\"\n> conclusion.\n\nSure. In my other message I talked about workflows not to imply \"how\ndare you explore the commands!\" but rather to see where you were coming\nfrom. I agree that a lot of git messages could be improved. So I think\nthe take-away lesson is not that there needs to be some huge change in\nbehavior or what input is accepted, but that git-fetch without tracking\nbranches should probably give a clue that it did _something_.\n\n> Another thing I spoke of was this refs/ stuff. I know my way around with\n> them now, so maybe they are not actually confusing to me anymore. It's\n> just that I have noticed a pattern: I always use refs/heads/... in\n> certain places and refs/remotes/ in certain places. If such a pattern is\n> very common (well, I don't know if it is) one starts to think that maybe\n> the pattern can/should be hidden and made part of the tool. Just\n> thoughts.\n\nI almost never use refs/remotes/ or refs/heads/. Some effort has been\nput into doing the right thing with partial refnames (which you can of\ncourse override by being more specific). Do you have specific examples\nof where you use the full refname? I suspect it is either not required\n(and documentation may be out of date), or it is a bug we could fix. :)\n\n-Peff\n"},{"id":"73995","messageId":"alpine.LFD.1.00.0804091945100.2947@xanadu.home","threadId":"13037","inReplyTo":"47FD37A7.6030404@freescale.com","subject":"Re: git annoyances","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-04-09T23:45:38Z","receivedAt":"2008-04-09T23:45:38Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 9 Apr 2008, Jon Loeliger wrote:\n\n> Junio C Hamano wrote:\n> > \n> \n> > The introductory documents may need to be updated to teach explicit \"git\n> > pull $repo $branch\" form first,\n> \n> Hey Junio,\n> \n> I'm hearing you here! :-)\n> \n> I think a furtherance of this notion is to\n> teach \"git fetch ; git merge\" before \"git pull\".\n\nAmen!\n\n\nNicolas\n"},{"id":"73996","messageId":"b8bf37780804091656s2f24ebe5h758884e63cea4845@mail.gmail.com","threadId":"13037","inReplyTo":"7vfxtu3fku.fsf@gitster.siamese.dyndns.org","subject":"Re: git annoyances","fromName":"André Goddard Rosa","fromEmail":"andre.goddard@gmail.com","sentAt":"2008-04-09T23:56:03Z","receivedAt":"2008-04-09T23:56:03Z","isPatch":false,"sender":{"key":"andre.goddard@gmail.com","avatar":null},"body":"> > but it was a PITA and all of git's messages about the problem were not\n> > only unhelpful, they confused me into looking for problems where there\n> > were none IMO.\n>\n> Yes, we need to teach \"git\" to do more mind-reading (I am not being\n> sarcastic). There should be a pattern in common user errors that share\n> their roots to the same user misperception, and if we can identify that,\n> maybe we can make git guess what the user was really trying to do and give\n> better error messages than it currently does.\n\nSomething along the lines of:\n\nError description\nWhy it happened\nHow to solve/Sugestion\n\n-- \n[]s,\nAndré Goddard\n"},{"id":"74007","messageId":"20080410000349.GA16800@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080409225112.GB12103@sigill.intra.peff.net","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-10T00:03:49Z","receivedAt":"2008-04-10T00:03:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 09, 2008 at 06:51:12PM -0400, Jeff King wrote:\n\n> > > From git://host/path/to/repo\n> > > * [new branch] foo -> FETCH_HEAD\n\nAs it turns out, there is already code to do this very thing, but:\n\n 1. it was broken ;)\n\n 2. you need to specify \"-v\"erbose mode to see it\n\nHere is a patch that fixes the breakage, which should be done either\nway. If people think this is a good thing to show in general (and I do,\nbut then I am not a very frequent user of \"fetch without tracking\nbranches\"), then there is an obvious one-liner to make it always show.\n\n-- >8 --\ngit-fetch: fix status output when not storing tracking ref\n\nThere was code in update_local_ref for handling this case,\nbut it never actually got called. It assumed that storing in\nFETCH_HEAD meant a blank peer_ref name, but we actually have\na NULL peer_ref in this case, so we never even made it to\nthe update_local_ref function.\n\nOn top of that, the display formatting was different from\nall of the other cases, probably owing to the fact that\nnobody had ever actually seen the output.\n\nThis patch harmonizes the output with the other cases and\nmoves the detection of this case into store_updated_refs,\nwhere we can actually trigger it.\n\nSigned-off-by: Jeff King \n---\n builtin-fetch.c | 28 +++++++++++++---------------\n 1 files changed, 13 insertions(+), 15 deletions(-)\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 5841b3e..139a6b1 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -215,13 +215,6 @@ static int update_local_ref(struct ref *ref,\n \tif (type < 0)\n \t\tdie(\"object %s not found\", sha1_to_hex(ref->new_sha1));\n \n-\tif (!*ref->name) {\n-\t\t/* Not storing */\n-\t\tif (verbose)\n-\t\t\tsprintf(display, \"* branch %s -> FETCH_HEAD\", remote);\n-\t\treturn 0;\n-\t}\n-\n \tif (!hashcmp(ref->old_sha1, ref->new_sha1)) {\n \t\tif (verbose)\n \t\t\tsprintf(display, \"= %-*s %-*s -> %s\", SUMMARY_WIDTH,\n@@ -365,16 +358,21 @@ static int store_updated_refs(const char *url, struct ref *ref_map)\n \t\t\trm->merge ? \"\" : \"not-for-merge\",\n \t\t\tnote);\n \n-\t\tif (ref) {\n+\t\tif (ref)\n \t\t\tupdate_local_ref(ref, what, verbose, note);\n-\t\t\tif (*note) {\n-\t\t\t\tif (!shown_url) {\n-\t\t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n-\t\t\t\t\t\t\turl_len, url);\n-\t\t\t\t\tshown_url = 1;\n-\t\t\t\t}\n-\t\t\t\tfprintf(stderr, \" %s\\n\", note);\n+\t\telse if (verbose)\n+\t\t\tsprintf(note, \"* %-*s %-*s -> FETCH_HEAD\",\n+\t\t\t\tSUMMARY_WIDTH, *kind ? kind : \"branch\",\n+\t\t\t\t REFCOL_WIDTH, *what ? what : \"HEAD\");\n+\t\telse\n+\t\t\t*note = '\\0';\n+\t\tif (*note) {\n+\t\t\tif (!shown_url) {\n+\t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n+\t\t\t\t\t\turl_len, url);\n+\t\t\t\tshown_url = 1;\n \t\t\t}\n+\t\t\tfprintf(stderr, \" %s\\n\", note);\n \t\t}\n \t}\n \tfclose(fp);\n-- \n1.5.5.25.g43bd4.dirty\n"},{"id":"74009","messageId":"20080410001152.GB16800@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080410000349.GA16800@sigill.intra.peff.net","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-10T00:11:52Z","receivedAt":"2008-04-10T00:11:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 09, 2008 at 08:03:49PM -0400, Jeff King wrote:\n\n> Here is a patch that fixes the breakage, which should be done either\n> way. If people think this is a good thing to show in general (and I do,\n> but then I am not a very frequent user of \"fetch without tracking\n> branches\"), then there is an obvious one-liner to make it always show.\n\nAnd here is that one-liner, in case there is interest. The only negative\nI can think of is that git-pull will now produce two extra lines of\noutput mentioning FETCH_HEAD (which I actually think is a positive, but\nI can see that people might consider it clutter).\n\n-- >8 --\ngit-fetch: always show status of non-tracking-ref fetches\n\nPreviously, a fetch like:\n\n git fetch git://some/url\n\nwould show no ref status output (just the object downloading\nstatus, if there was any), leading to some confusion.\n\nWith this patch, we now show the usual ref table, with\nremote refs going into FETCH_HEAD. Previously this output\nwas shown only if \"-v\"erbose was specified.\n\nSigned-off-by: Jeff King \n---\n builtin-fetch.c | 4 +---\n 1 files changed, 1 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-fetch.c b/builtin-fetch.c\nindex 139a6b1..e4486e4 100644\n--- a/builtin-fetch.c\n+++ b/builtin-fetch.c\n@@ -360,12 +360,10 @@ static int store_updated_refs(const char *url, struct ref *ref_map)\n \n \t\tif (ref)\n \t\t\tupdate_local_ref(ref, what, verbose, note);\n-\t\telse if (verbose)\n+\t\telse\n \t\t\tsprintf(note, \"* %-*s %-*s -> FETCH_HEAD\",\n \t\t\t\tSUMMARY_WIDTH, *kind ? kind : \"branch\",\n \t\t\t\t REFCOL_WIDTH, *what ? what : \"HEAD\");\n-\t\telse\n-\t\t\t*note = '\\0';\n \t\tif (*note) {\n \t\t\tif (!shown_url) {\n \t\t\t\tfprintf(stderr, \"From %.*s\\n\",\n-- \n1.5.5.26.g8c565.dirty\n"},{"id":"74010","messageId":"20080410003352.GA14057@sigill.intra.peff.net","threadId":"13037","inReplyTo":"bd6139dc0804091616k53f4e0c1sf75aa9585c5a54c5@mail.gmail.com","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-10T00:33:52Z","receivedAt":"2008-04-10T00:33:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[Your message didn't go to the list, but I think it was supposed to, so\nI am re-adding the list].\n\nOn Thu, Apr 10, 2008 at 01:16:57AM +0200, Sverre Rabbelier wrote:\n\n> > I wonder if people like Linus who do a lot of one-off pulls would find\n> > that too cluttery. I guess we can post a patch and see. ;)\n> \n> Maybe a 'newbie' configuration option could be added?\n> We can then, if that option is set, provide this kind of information\n> to the user.\n> Then, later on, when the user is more confident, they can unset the option.\n> I reckon it should be set to default-off but that we should provide an\n> easy way to turn it on.\n> (That is, 'git config newbie on', is easy enough, as long as it is\n> mentioned in a/the newbie guide)\n\nThis has been discussed before, and I think the general consensus was\nthat it's a bad idea to separate the \"newbie\" and \"expert\" experience\ntoo much. It makes it harder to provide advice and documentation that\nworks for everyone.\n\nNow that argument generally applies to _behavior_ changes, not verbosity\nof messages. But in this case, I think it is easy enough to find a\n\"right\" behavior for everyone: show the message on fetch, which would\notherwise be a very confusing command, but suppress it on \"pull\", where\nthe fetching is mostly a side effect.\n\n-Peff\n"},{"id":"74018","messageId":"47FDAEEF.3090004@eclis.ch","threadId":"13037","inReplyTo":"7vfxtu3fku.fsf@gitster.siamese.dyndns.org","subject":"Re: git annoyances","fromName":"Jean-Christian de Rivaz","fromEmail":"jc@eclis.ch","sentAt":"2008-04-10T06:08:47Z","receivedAt":"2008-04-10T06:08:47Z","isPatch":false,"sender":{"key":"jc@eclis.ch","avatar":"https://gravatar.com/avatar/c5bc03f5e932f737c47e353ef0dac2892161d59831c170cab6d61342e6324eb3?d=mp&s=160"},"body":"Junio C Hamano a écrit :\n> That made us allowing the users to type \"git pull\" and \"git fetch\" without\n> parameters. This is generally a good thing: shorter to type for doing\n> common things is always good, as long as the user knows what he is doing.\n> \n> But at the same time, this allowed docs and cheat-sheets that mention only\n> the form without parameters and not the normative \"repository refspec\"\n> form. This dumbed down the users not understand that in that context\n> fetch (and pull, which is a fetch followed by a merge) is always happening\n> against a single branch of single remote repository, the way to name\n> remote repository and its branch(es) is to give them as separate\n> parameters, and their not typing the pair explicitly is a mere convenience\n> feature. This particular aspect of the shorthand is actually very bad.\n> It makes the mental model fuzzy, and hiding important rules of how the\n> world works from new people would lead them to unnecessary confusion. In\n> short, we made it harder for the new people to \"get\" it.\n\nA possible way it to, by default, make git print the full form of the \ncommand when a short form is used. So the user see the concept without \nhaving to read the documentation and learn it gradually. I personally \nlike tools that act this way. It permit to make a basic and easy \ntutorial with short commands that let know the general concept and show \nthe full potential of the tool.\n\nA \"short form\" flag in a user (not repository) configuration file should \nallow to suppress the long form printout for the comfort of the users \nthat don't want it.\n\n--\nJean-Christian de Rivaz\n"},{"id":"74035","messageId":"20080410073850.GC3160@mithlond","threadId":"13037","inReplyTo":"7vabk23esz.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-10T07:38:50Z","receivedAt":"2008-04-10T07:38:50Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Junio C Hamano wrote (2008-04-09 14:21 -0700):\n\n> [By the way, please never redirect the response to your messages away from\n> you with:\n> \n> Mail-Followup-To: Jeff King , Ingo Molnar ,\n> git@vger.kernel.org\n\nSorry, didn't even know such header existed. After consulting Mutt's\nmanual and some googling I think I understand it now. I'm a subscriber\nto git list (and my Mutt knows that) and Mail-Followup-To told\neveryone's MUAs to not include me in recipient list since I get\neverything through the list. But this is configurable and generating\nMail-Followup-To should be now turned off.\n\n> > Currently \"git fetch \" does not seem to do anything useful for\n> > non-git-hackers. It seems to fetch objects but not create any\n> > branches referring to them.\n> \n> I'd suggest you to study:\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31634\n> \n> Not everybody wants remote tracking.\n\nThanks, and I agree. Me neither always want remote tracking. Git's\ncurrent behaviour to only create/update FETCH_HEAD seems actually better\n- now that I know what it does. I think it's a good idea to show \"[new\nbranch] foo -> FETCH_HEAD\" after fetching.\n"},{"id":"74037","messageId":"7vlk3mxi4z.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080410001152.GB16800@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-10T07:51:08Z","receivedAt":"2008-04-10T07:51:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks for bringing this issue up and proposing a pair of improvements.\n\nI am very inclined to apply [1/2] to maint. I am not convinced if [2/2]\nis a good idea in general but if it is silent on pull and verbose on\none-off fetch without local store, it probably is an improvement.\n"},{"id":"74039","messageId":"bd6139dc0804100058r44488432ke19c27432b561561@mail.gmail.com","threadId":"13037","inReplyTo":"20080410003352.GA14057@sigill.intra.peff.net","subject":"Re: Friendly refspecs (Was: Re: git annoyances)","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-04-10T07:58:56Z","receivedAt":"2008-04-10T07:58:56Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Thu, Apr 10, 2008 at 2:33 AM, Jeff King wrote:\n> [Your message didn't go to the list, but I think it was supposed to, so\n> I am re-adding the list].\n\nYes, it was supposed to go to the list, my bad for hitting 'reply'\ninstead of 'reply to all'.\n\n> On Thu, Apr 10, 2008 at 01:16:57AM +0200, Sverre Rabbelier wrote:\n> > > I wonder if people like Linus who do a lot of one-off pulls would find\n> > > that too cluttery. I guess we can post a patch and see. ;)\n> >\n> > Maybe a 'newbie' configuration option could be added?\n> > We can then, if that option is set, provide this kind of information\n> > to the user.\n> > Then, later on, when the user is more confident, they can unset the option.\n> > I reckon it should be set to default-off but that we should provide an\n> > easy way to turn it on.\n> > (That is, 'git config newbie on', is easy enough, as long as it is\n> > mentioned in a/the newbie guide)\n>\n> This has been discussed before, and I think the general consensus was\n> that it's a bad idea to separate the \"newbie\" and \"expert\" experience\n> too much. It makes it harder to provide advice and documentation that\n> works for everyone.\n\nI would agree here, not only will it make it hard to provide\nconsequent advice and documentation, it will also make it more\ndifficult to switch to \"expert\" mode if the \"newbie\" mode is a lot\ndifferent.\n\n> Now that argument generally applies to _behavior_ changes, not verbosity\n> of messages. But in this case, I think it is easy enough to find a\n> \"right\" behavior for everyone: show the message on fetch, which would\n> otherwise be a very confusing command, but suppress it on \"pull\", where\n> the fetching is mostly a side effect.\n\nThis makes sense, but I think that if it is made default behavior it\nwould be nice to add a way to make it quiet. Perhaps 'quiet' can be\nused (I recall seeing used it elsewhere), either through a config\noption or a command line argument. Then again, if everybody agrees\nthat this added verbosity is good, there'd be no reason to go through\nthat trouble.\n\nCheers,\n\nSverre Rabbelier\n"},{"id":"74040","messageId":"20080410080325.GA15791@sigill.intra.peff.net","threadId":"13037","inReplyTo":"7vlk3mxi4z.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-10T08:03:25Z","receivedAt":"2008-04-10T08:03:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 10, 2008 at 12:51:08AM -0700, Junio C Hamano wrote:\n\n> Thanks for bringing this issue up and proposing a pair of improvements.\n> \n> I am very inclined to apply [1/2] to maint. I am not convinced if [2/2]\n> is a good idea in general but if it is silent on pull and verbose on\n> one-off fetch without local store, it probably is an improvement.\n\nI think that is the right behavior for 2/2; I was just being a little\nlazy earlier. I will try to work up an improved 2/2, but I will probably\nbe out of touch for a few days. Maybe we will see some comments from the\nlist in the meantime.\n\n-Peff\n"},{"id":"74042","messageId":"bd6139dc0804100119s30a0b62fyc819a7b247b2a972@mail.gmail.com","threadId":"13037","inReplyTo":"47FDAEEF.3090004@eclis.ch","subject":"Re: git annoyances","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-04-10T08:19:41Z","receivedAt":"2008-04-10T08:19:41Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Thu, Apr 10, 2008 at 8:08 AM, Jean-Christian de Rivaz wrote:\n> A possible way it to, by default, make git print the full form of the\n> command when a short form is used. So the user see the concept without\n> having to read the documentation and learn it gradually. I personally like\n> tools that act this way. It permit to make a basic and easy tutorial with\n> short commands that let know the general concept and show the full potential\n> of the tool.\n\nI think this would be a very nice solution, not only do you allow the\nuser to realize what it is they are doing, you also provide them with\nan easy way to be more verbose. Perhaps they wish to switch from the\ndefault short behavior to a somewhat different form (e.g., change a\ndefault 'master' argument to another branch). When writing out the\nfull form each time the user gets an intuitive and gradual\nintroduction into the rest of git, without limiting them or more\nadvanced users.\n\n> A \"short form\" flag in a user (not repository) configuration file should\n> allow to suppress the long form printout for the comfort of the users that\n> don't want it.\n\nOr perhaps, as I mentioned in the thread on \"friendly refspecs\", a\n\"newbie\" config option or command that turns on the informative\nverboseness options. As such, perhaps a \"long form\" flag would be more\ndesired instead, to prevent existing developers from being spammed\nwith information they do not are interested in.\n\nCheers,\n\nSverre Rabbelier\n"},{"id":"74045","messageId":"20080410084119.GA8979@diana.vm.bytemark.co.uk","threadId":"13037","inReplyTo":"32541b130804091008h1a757552o14dd8e937ed19058@mail.gmail.com","subject":"Re: git annoyances","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-04-10T08:41:19Z","receivedAt":"2008-04-10T08:41:19Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-04-09 13:08:39 -0400, Avery Pennarun wrote:\n\n> For example, in svn you can talk about\n> svn+ssh://reposerver/path/to/repo/branches/foo@1234; it's a single\n> \"word\" that refers to a particular revision on a particular branch\n> of a particular server.\n\nHeh, not really. Subversion actually makes this even more confusing\nthan git does.\n\nThe @rev is called a \"peg revision\", and is different from the\n\"operative revision\" specified with the -r flag. The peg revision is\nused in conjunction with a path to specify the file (or directory) you\nwant, and the operative revision is used to specify which revision of\nthat file you mean. (This complexity is needed because subversion has\na concept of file identity.)\n\nSo\n\n $ svn cp -r 4711 $REPO/foo@1234 somewhere-else\n\nmeans \"find the file (or directory) that was called 'foo' in revision\n1234, then copy revision 4711 of that file to somewhere-else\".\n\nSee http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html for\nthe full story.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"74055","messageId":"7vod8ivuyw.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"alpine.DEB.1.00.0804091754170.2074@eeepc-johanness","subject":"Re: [PATCH] git-remote: show all remotes with \"git remote show\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-10T10:56:55Z","receivedAt":"2008-04-10T10:56:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Applied, thanks.\n"},{"id":"74059","messageId":"20080410114739.GA15229@elte.hu","threadId":"13037","inReplyTo":"20080409101428.GA2637@elte.hu","subject":"git-bisect annoyances","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-04-10T11:47:39Z","receivedAt":"2008-04-10T11:47:39Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\nOk, just in case i dont bore people with \"stupid user\" experiences and \nlogs of sessions of confusion, here's another session i just had with \nGit.\n\nThis time it's with our good friend git-bisect - which i thought to \nmaster pretty well and which i already used successfully to bisect \nkernel bugs up to a hundred times already (at least).\n\nThe 'v' repository is a vanilla clone of Linus's upstream linux-2.6.git \nkernel tree with no other modifications done to it.\n \n dione:~> git-clone v linux-tmp4\n Initialized empty Git repository in /home/mingo/linux-tmp4/.git/\n 0 blocks\n Checking out files: 100% (23809/23809), done.\n dione:~> cd linux-tmp4/\n dione:~/linux-tmp4> ls\n COPYING MAINTAINERS arch fs kernel samples usr\n CREDITS Makefile block include lib scripts virt\n Documentation README crypto init mm security\n Kbuild REPORTING-BUGS drivers ipc net sound\n\n #\n # ok, so far so good. done this a thousand times before.\n #\n # Now lets check out v2.6.24 and check whether the bug i'm interested \n # in triggers on v2.6.24. I dont create an extra branch for it, because \n # this is pure temporary work, i use a plain git-checkout as a \n # throwaway temporary branch:\n #\n\n dione:~/linux-tmp4> git-checkout v2.6.24\n Note: moving to \"v2.6.24\" 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 4991408... Linux 2.6.24\n\n #\n # i build that kernel and boot it - the bug doesnt trigger - good. \n # We've got all prerequisites for a bisection session - a 'good' kernel \n # [v2.6.24] and a 'bad' kernel [HEAD].\n #\n #\n\n dione:~/linux-tmp4> git-bisect start\n fatal: ref HEAD is not a symbolic ref\n won't bisect on seeked tree\n\n #\n # Hm. It's not a symbolic ref, and git-bisect just wont do it. Ok but \n # then what, and what can the user do to progress? It should be rather \n # clear to Git what i'm intending to do here. I'm not interested in \n # HEAD at all, i want to start bisection and i'll feed the good/bad \n # points to git-bisect - once it lets me do that.\n #\n # Ok, lets see where we are:\n #\n\n dione:~/linux-tmp4> git-branch -a\n * (no branch)\n master\n origin/HEAD\n origin/master\n origin/new_branch\n\n #\n # So perhaps this new, unnamed branch is what is causing the trouble? \n # Lets try a specific branch then:\n #\n\n dione:~/linux-tmp4> git-checkout master\n Previous HEAD position was 4991408... Linux 2.6.24\n Switched to branch \"master\"\n\n dione:~/linux-tmp4> git-bisect start\n won't bisect on seeked tree\n\n #\n # Hm, still no go. Lets see what git-bisect has to offer:\n #\n\n dione:~/linux-tmp4> git-bisect\n Usage: /usr/bin/git-bisect \n [start|bad|good|skip|next|reset|visualize|replay|log|run]\n\n #\n # Ah, it has a reset thing, lets try it:\n #\n\n dione:~/linux-tmp4> git-bisect reset\n Note: moving to \"49914084e797530d9baaf51df9eda77babc98fa8\" which isn't a \n 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 4991408... Linux 2.6.24\n\n dione:~/linux-tmp4> git-bisect start\n fatal: ref HEAD is not a symbolic ref\n\n #\n # hm, still no go. I'm not interested in a new branch at all, but i \n # want to bisect, so lets try what was suggested then and name the \n # branch:\n #\n\n dione:~/linux-tmp4> git-checkout -b tmp\n Switched to a new branch \"tmp\"\n\n #\n # Looks good so far - can i bisect?\n #\n\n dione:~/linux-tmp4> git-bisect start\n won't bisect on seeked tree\n\n #\n # Hm, still no go. Ok, lets forget this whole temporary branch thing \n # that looked good and try a more pristine state:\n #\n\n dione:~/linux-tmp4> git-checkout -b tmp2 master\n Previous HEAD position was 4991408... Linux 2.6.24\n Switched to a new branch \"tmp2\"\n\n dione:~/linux-tmp4> git-bisect start\n\n #\n # Halleluya! While i have typed much more than i wanted, and ended up \n # with two extra branches that i have to throw away, it seems to be \n # working! Although the command printing nothing is not really \n # reassuring - did it really do something?\n #\n # Ok, lets get the bisection going now:\n #\n\n dione:~/linux-tmp4> git-bisect good v2.6.24 bad HEAD\n dione:~/linux-tmp4>\n\n #\n # Hm, no indication about what happened, and no \"middle\" bisection \n # point offered. No way to figure out what's wrong.\n #\n # Ok, backtrack one more step - something's wrong here. Lets start \n # again with a completely new tree:\n #\n\n dione:~> git-clone v linux-tmp5\n Initialized empty Git repository in /home/mingo/linux-tmp5/.git/\n 0 blocks\n Checking out files: 100% (23809/23809), done.\n dione:~> cd linux-tmp5/\n dione:~/linux-tmp5> git-checkout -b tmp master\n Switched to a new branch \"tmp\"\n dione:~/linux-tmp5> git-bisect start good v2.6.24\n dione:~/linux-tmp5> cd\n dione:~> cd linux-tmp5/\n dione:~/linux-tmp5> git-bisect start good v2.6.24 bad master\n dione:~/linux-tmp5>\n\n #\n # Hm, nothing. Ho hum. Do i suck this much? One more tree than i wanted \n # and three more branches that i wanted and still no bisection?\n #\n # Ah, i must have switched the arguments?\n #\n\n dione:~/linux-tmp5> git-bisect start v2.6.24 good master bad\n won't bisect on seeked tree\n\n #\n # Nope.\n #\n\n dione:~/linux-tmp5> git-bisect visualize\n You need to give me at least one good and one bad revisions.\n (You can use \"git bisect bad\" and \"git bisect good\" for that.)\n dione:~/linux-tmp5> git bisect bad HEAD\n dione:~/linux-tmp5> git bisect good v2.6.24\n Bisecting: -1 revisions left to test after this\n [eb36f4fc019835cecf0788907f6cab774508087b] fix oops on rmmod capidrv\n\n #\n # -1 revisions left to test? Ouch ...\n #\n # But why did \"git bisect\" make a difference to \"git-bisect\" ?\n # Lets see whether it's all from the same package:\n #\n\n dione:~> type git\n git is hashed (/usr/bin/git)\n dione:~> type git-bisect\n git-bisect is hashed (/usr/bin/git-bisect)\n dione:~> rpm -qf /usr/bin/git-bisect\n git-core-1.5.4.3-2.fc8\n dione:~> rpm -qf /usr/bin/git\n git-core-1.5.4.3-2.fc8\n\n #\n # Yup, it is. 20 minutes spent on this already and no bisection.\n # I really suck today :-)\n #\n\n #\n # So i started suspecting my kernel and my hardware. Are timestamps \n # maybe messed up and confusing Git? Since the commands dont return \n # success nor failure i was unsure what Git thought about my attempts.\n #\n # So i rebooted the box and created a new tree. No go.\n #\n\n #\n # Just to be sure i also waited through a full git-fsck, only 10 \n # minutes runtime:\n #\n\n dione:~/linux-tmp4> git-fsck --full --strict\n dangling commit f4be31ec9690cfe6e94fcbed6ae60a6a38b3c3ed\n dione:~/linux-tmp4>\n\n #\n # [ Sidenote #1: git-fsck is such a heavy operation that it should \n # really return some indication by default that it's all appears OK.\n # A user typically only runs git-fsck if in deep doubt about some \n # git detail - so while silence is often good for a comment, it's \n # counter-intuitive here. Especially since the \"breakage\" of \n # git-bisect is \"silence\" too, so the user is unable to trust these \n # different modal forms of silence and gets frustrated ... ]\n #\n\n #\n # [ Sidenote #2: git-fsck --full --strict is slow and we always knew\n # this - it's a last-ditch thing for the truly hopeless. But this is \n # a 3.2 GHz quad box that is only 25% utilized during git-fsck but \n # takes 10 minutes to finish. Presumably git-fsck could run multiple \n # threads/tasks to be sped up? Making the slowest possible operation \n # of a tool significantly faster is a good way to reduce user \n # frustration IMO. A user is already frustrated enough when he tries \n # --full --strict. And i _bet_ a parallel version of git-fsck would \n # also be an fantastic bad-RAM checker ;-) ]\n #\n\n #\n # Then, many other silly attempts later and at linux-tmp8, by chance - \n # 30 minutes down the line - i got it going:\n #\n # I updated my Linus tree on the (rather pathetic) theory that maybe a \n # specific layout of the repo breaks bisection - and that seems to have \n # made a difference:\n #\n\n dione:~/linux-tmp8> git-checkout -b tmp2 master\n Switched to a new branch \"tmp2\"\n dione:~/linux-tmp8> git-bisect start\n won't bisect on seeked tree\n dione:~/linux-tmp8> git-bisect reset\n Switched to branch \"master\"\n dione:~/linux-tmp8> git-bisect bad master\n You need to start by \"git bisect start\"\n Do you want me to do it for you [Y/n]? Y\n dione:~/linux-tmp8> git-bisect good v2.6.24\n Bisecting: 6270 revisions left to test after this\n [4814bdbd590e835ecec2d5e505165ec1c19796b2] [NETNS]: Lookup in FIB \n semantic hashes taking into account the namespace.\n\n #\n # But i dont understand why. Before updating Linus's tree i saved away \n # the commit ID that showed the breakage, just in case it matters:\n #\n\n commit 7180c4c9e09888db0a188f729c96c6d7bd61fa83\n Merge: 4c3b01f... 869ab51...\n Author: Linus Torvalds \n Date: Mon Apr 7 19:15:35 2008 -0700\n\n #\n # .. but couldnt reproduce this weirdness with specifically checking \n # out 7180c4c9e09888db0a188f729c96c6d7bd61fa83. But i still have the \n # linux-tmp4 repository that shows this behavior reliably. It's all \n # quite weird. Either this repo is corrupted in some special way, or my \n # hardware has some really strange runtime failure, or i'm missing \n # something very obvious ;-)\n #\n\n #\n # One more minor sidenote. Git-bisect creates its own branch:\n #\n\n dione:~/linux-tmp12> git-branch -a\n * bisect\n master\n tmp\n tmp2\n origin/HEAD\n origin/master\n origin/new_branch\n\n #\n # So i assumed that i could get rid of that 'bisect' branch by doing \n # the obvious: \"git-bisect stop\", but no go:\n #\n\n dione:~/linux-tmp12> git-bisect stop\n Usage: /usr/bin/git-bisect [start|bad|good|skip|next|reset|visualize|replay|log|run]\n\n #\n # After some experimentation \"git-bisect reset\" did the trick - but \n # it's a bit counter-intuitive IMO, because the logical extension of \n # 'start' is 'stop', and i often use 'git-bisect reset' to just restart\n # bisection anew. (it chimes in on 'restart')\n #\n\n #\n # Ok, that's all for today. :-)\n #\n\n\tIngo\n"},{"id":"74062","messageId":"alpine.LNX.1.00.0804091830590.19665@iabervon.org","threadId":"13037","inReplyTo":"20080409204149.GC18968@elte.hu","subject":"Re: git annoyances","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-04-10T14:08:08Z","receivedAt":"2008-04-10T14:08:08Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 9 Apr 2008, Ingo Molnar wrote:\n\n> \n> * Daniel Barkalow wrote:\n> \n> > > also, the first natural thing i did was to just type:\n> > > \n> > > $ git-merge ~/linux-2.6-x86.git/\n> > > \n> > > which i naively assumed would sort things out for me and provide \n> > > some reasonable default behavior - but instead it just gave an \n> > > annoyingly unhelpful error message:\n> > > \n> > > /home/mingo/linux-2.6-x86.git/ - not something we can merge\n> > > \n> > > there should really be a consciously established \"route of failure \n> > > resolution\" - directing people towards relevant sources of \n> > > information or commands when the git command-line utilities return \n> > > some error due to user incompetence. Otherwise users just guess \n> > > around and get frustrated.\n> > \n> > I'm not sure we can figure out what the user actually meant in this \n> > case; there's just too much overlap in namespaces to determine \n> > reliably that you were giving it a remote repository on the local \n> > filesystem rather than anything else.\n> \n> well, current git got to /home/mingo/linux-2.6-x86.git/ which is a local \n> path. (it is printing it in the error message above) So i think it was \n> rather unambiguous what i meant and Git knew about it, right?\n\nActually, your shell did that. I don't think git can tell that the user \ntyped something different and the shell converted it because it's a local \npath.\n\n> but even if it _was_ ambiguous, i think tools should generally default \n> to a minimal amount of hassle for new users and should try to pick \n> reasonable \"action\" versus any \"inaction\". (as long as the behavior is \n> still deterministic and reasonable even to the long-time user)\n\nIt's hard to evaluate proposals for extending cases from inaction to some \naction because in trying to keep it deterministic, you have to decide \nwhether future, possibly more compelling, extensions might want to overlap \nthe space of commands. It's more conservative to have the command suggest \nsome things the user might have meant, even if that's sometimes a list of \none, so that the user doesn't come to rely on behavior that is only \ndeterministic within a vaguely-delineated area.\n\n> but more importantly, i think this whole problem area has to be handled \n> with a slightly different kind of mindset than other, more technical \n> aspects of Git.\n> \n> Humans, and in particular males, when they see or learn new things, are \n> very emotion-driven. The first 1-2 minutes (often just the first few \n> seconds) have a very strong influence on whether that person 'likes' a \n> new topic, tool or gizmo he is checking out - or not. Males often think \n> of themselves as being objective when shopping new items - while in \n> reality more than 90% of their purchasing decisions are emotion-driven \n> and it's all set and done in the first 10 seconds of visual contact. \n> (this ration is far higher than for females)\n> \n> Command-line tools like Git are at heavy natural disadvantage compared \n> to say GUI tools because the \"first impression\" is so minimalistic and \n> relatively unremarkable. A GUI can get people hooked by making the first \n> 10% look easy just via old-fashioned, dishonest visual deception.\n> \n> so basically for 90% of the new users, we've got 2-3 shots or we lose \n> their \"sympathy\". Starting with an error message is bad. Being \n> uninformative about what happened is bad. Making the user wait without \n> signalling why he is waiting is bad. Etc. etc. I think this experience \n> of mine was a reasonable simulation of a first-time user reaction (by \n> virtue of me having forgotten certain Git details).\n\nI think that it's far enough along before a user types \"git merge ...\" \nthat we've got a chance to give a suggestive error message instead of just \ndoing something, particularly if the thing we might do might be wrong and \neither annoying to clean up or slow. (OTOH, \"git clone ...\" had better \nwork, and I think it does)\n\nAnd I agree strongly with the need for the error messages in the cases \nwhere the user was closer to be clear and suggest the right thing.\n\n> So i really think that maintaining this aspect of Git and in essence \n> Huffman-optimizing the interface and the learning curve for first-time \n> Git users is perhaps the most important thing. Especially since some \n> users like me will often re-learn Git details that they use rarely.\n\nOn the other hand, there's a conflict between having git do what the user \nseems to want it to do and having git's commands delineated by concepts \nthat users need to know, such that users will be assisted in learning \nthose concepts (and therefore have an easier time getting the results they \nexpect from git consistantly). For example, \"merge\" works on information \nyou have within the repository, and \"fetch\" brings information into the \nrepository. In some cases, we could guess that the user has typed \"merge\" \nbut wants to bring information into the repository, but we won't always be \nright, and we want the user to learn how to tell git unambiguous things.\n\n> Getting these details right is _extremely hard_, because the people who \n> are capable of fixing these details have long forgotten the first-time \n> annoyances they had! (if they had any - often developers are \n> statistically lucky and never hit any pitfalls.)\n> \n> It's doubly hard because Git developers work on Git exactly because they \n> _like_ it, so one's own positive experience has to be contrasted to the \n> prospect of negative first-time experience.\n> \n> It's triple hard because it might also mean changing some things that \n> have been done in Git since the start of the project. A negative \n> experience that isnt some technical problem in the strict sense - it's \n> an emotional thing that is much harder to define and much harder to \n> agree on and improve.\n> \n> So i think it's really hard mentally - and i'm positively surprised by \n> the many constructive and positive reactions that my mail generated.\n> \n> Improving this area is perhaps even harder than adding new functionality \n> - but i think it's a key and extremely strategic aspect of Git, because \n> it affects the very heart of the Git project: it maximizes the influx of \n> new users (who also include future Git developers btw.) and minimizes \n> outflux of existing users.\n\nI think the market segment that most git developers would really like to \nget is the projects that they work on aside from git. There's a \nsubstantial itch to make git sufficiently compelling that nobody would \nmake them use CVS/SVN/Perforce/ClearCase/etc. This has a significant \nusability-to-new-users component, and so there's more attention to that \nthan in projects where use of the project doesn't require getting \nparticular other people to use it.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"74064","messageId":"32541b130804100805o4ad1e9a6x38e9b1fcf17c5d1d@mail.gmail.com","threadId":"13037","inReplyTo":"20080410084119.GA8979@diana.vm.bytemark.co.uk","subject":"Re: git annoyances","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-04-10T15:05:07Z","receivedAt":"2008-04-10T15:05:07Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Apr 10, 2008 at 4:41 AM, Karl Hasselström wrote:\n> On 2008-04-09 13:08:39 -0400, Avery Pennarun wrote:\n>\n> > For example, in svn you can talk about\n> > svn+ssh://reposerver/path/to/repo/branches/foo@1234; it's a single\n> > \"word\" that refers to a particular revision on a particular branch\n> > of a particular server.\n>\n> Heh, not really. Subversion actually makes this even more confusing\n> than git does.\n>\n> The @rev is called a \"peg revision\", and is different from the\n> \"operative revision\" specified with the -r flag. The peg revision is\n> used in conjunction with a path to specify the file (or directory) you\n> want, and the operative revision is used to specify which revision of\n> that file you mean.\n\nYes, but I believe you get the one from @rev if you don't specify -r.\n\nFor example, I can ask for an \"svn diff svn://blahblah@56\nsvn://blahblah@59\" and it'll feed it to me as expected.\n\nThis is nearly the same as \"svn diff -r56:59 svn://blahblah\", except\nthat it might look for blahblah in different places, as you say. I\ntend to prefer the @notation for exactly at that reason.\n\n> (This complexity is needed because subversion has\n> a concept of file identity.)\n\nFile renames make diffing and merging complicated no matter whether\nyou track them or not.\n\nsvn's tracking of file identity is additional, but doesn't increase\nthe (UI) complexity in the common case. At least with svn, a newbie\ncan even get real work done without even knowing about -r *or*\n@notation.\n\nCompare that to arbitrary differences in behaviour between \"git-fetch\"\nvs \"git-fetch a\" vs \"git-fetch a b\", or the difference between HEAD^\nand HEAD~1 and HEAD@1. git is very powerful, but also definitely more\ncomplex for beginners.\n\nHave fun,\n\nAvery\n"},{"id":"74092","messageId":"5d46db230804101245yf4a0c22qaee99f2c01256938@mail.gmail.com","threadId":"13037","inReplyTo":"b8bf37780804091656s2f24ebe5h758884e63cea4845@mail.gmail.com","subject":"Re: git annoyances","fromName":"Govind Salinas","fromEmail":"govind@sophiasuchtig.com","sentAt":"2008-04-10T19:45:36Z","receivedAt":"2008-04-10T19:45:36Z","isPatch":false,"sender":{"key":"govind@sophiasuchtig.com","avatar":null},"body":"On Wed, Apr 9, 2008 at 6:56 PM, André Goddard Rosa\n wrote:\n> > > but it was a PITA and all of git's messages about the problem were not\n> > > only unhelpful, they confused me into looking for problems where there\n> > > were none IMO.\n> >\n> > Yes, we need to teach \"git\" to do more mind-reading (I am not being\n> > sarcastic). There should be a pattern in common user errors that share\n> > their roots to the same user misperception, and if we can identify that,\n> > maybe we can make git guess what the user was really trying to do and give\n> > better error messages than it currently does.\n>\n> Something along the lines of:\n>\n> Error description\n> Why it happened\n> How to solve/Sugestion\n>\n\nHi,\n\nThis actually touches on one of my main purposes behind Pyrite. I intend to\ndo the following things to help the situation and I was wondering what the\ngit community's reaction is.\n\n1) Since it will be designed for end users I intend to remove the options not\ndesigned for end users. This will also shorten up the help so that the entire\nhelp can be shown to the user when they encounter an error.\n\n2) No unnamed options. I think this would have helped the above case\nalthough it would have required a *bit* more typing. The command would\nhave looked like \"pyt pull/fetch -r x86 -b latest\" Combined with the above\nthe command would have spit out the help and a message stating what was\nmissing.\n\n3) No syntax. Git has a lot of syntax. It has refspecs, revision ranges,\nsymbolic names (although i do like these) that a user has to learn. I\nthink this\nis one of the most error prone parts of the git for new users.\nHopefully, I will\nbe able to find simple and straightforward ways for the user to supply\nthis info.\n\nAny comments/suggestions will be appreciated.\n\nThanks,\nGovind.\n"},{"id":"74093","messageId":"20080410195910.GB26779@elte.hu","threadId":"13037","inReplyTo":"20080409151551.GA30439@sigill.intra.peff.net","subject":"Re: [PATCH] git-remote: show all remotes with \"git remote show\"","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-04-10T19:59:10Z","receivedAt":"2008-04-10T19:59:10Z","isPatch":true,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Jeff King wrote:\n\n> Many other commands use the \"no arguments\" form to show a\n> list (e.g., git-branch, git-tag). While we did show all\n> remotes for just \"git remote\", we displayed a usage error\n> for \"git remote show\" with no arguments. This is\n> counterintuitive, since by giving it _more_ information, we\n> get _less_ result.\n> \n> The usage model can now be thought of as:\n> \n> - \"git remote show \": show a remote\n> - \"git remote show\": show all remotes\n> - \"git remote\": assume \"show\"; i.e., shorthand for \"git remote show\"\n\nbtw., another suggestion: because i use 'git-remote show' rather \nfrequently, i recently typoed \"git-bisect show\" and then realized that \nit was \"git-bisect visualize\". Shouldnt there be a \"git-bisect show\" \nalias?\n\nI think using 'show' for all such 'display state' things would be rather \nintuitive, if it was applied consistently all across the board. \n('visualize' could still remain indefinitely, for compatibility - and \n'git-bisect log' would still do the log of the bisection decisions that \nwere entered.)\n\nOr is there some purpose behind this deviation that i missed?\n\n\tIngo\n"},{"id":"74103","messageId":"1207869946-17013-1-git-send-email-g2p.code@gmail.com","threadId":"13037","inReplyTo":"20080409101428.GA2637@elte.hu","subject":"[PATCH] When a remote is added but not fetched, tell the user.","fromName":"Gabriel","fromEmail":"g2p.code@gmail.com","sentAt":"2008-04-10T23:25:46Z","receivedAt":"2008-04-10T23:25:46Z","isPatch":true,"sender":{"key":"g2p.code@gmail.com","avatar":null},"body":"A helpful message tells the user when a remote was added\nwithout being fetched, and how to fetch it.\n\nOur default of not fetching is breaking the users' workflow\nin the common \"let me access this repo\" use case.\nThis message alleviates the problem.\n\nSigned-off-by: Gabriel \n---\n builtin-remote.c | 12 ++++++++++--\n 1 files changed, 10 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex d77f10a..044215a 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -111,8 +111,16 @@ static int add(int argc, const char **argv)\n \t\t\treturn 1;\n \t}\n \n-\tif (fetch && fetch_remote(name))\n-\t\treturn 1;\n+\tif (fetch) {\n+\t\tif (fetch_remote(name))\n+\t\t\treturn 1;\n+\t}\n+\telse {\n+\t\tprintf (\"Added remote repository `%s' without fetching it.\\n\"\n+\t\t\t\"Before accessing the branches of this \"\n+\t\t\t\"remote, run `git fetch %s' \"\n+\t\t\t\"or `git remote update'.\\n\", name, name);\n+\t}\n \n \tif (master) {\n \t\tstrbuf_reset(&buf);\n-- \n1.5.5.24.geb27\n"},{"id":"74112","messageId":"200804110741.40732.chriscool@tuxfamily.org","threadId":"13037","inReplyTo":"20080410114739.GA15229@elte.hu","subject":"Re: git-bisect annoyances","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-04-11T05:41:40Z","receivedAt":"2008-04-11T05:41:40Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le jeudi 10 avril 2008, Ingo Molnar a écrit :\n> Ok, just in case i dont bore people with \"stupid user\" experiences and\n> logs of sessions of confusion, here's another session i just had with\n> Git.\n\nThanks, this is very much appreciated.\n\n> This time it's with our good friend git-bisect - which i thought to\n> master pretty well and which i already used successfully to bisect\n> kernel bugs up to a hundred times already (at least).\n>\n> The 'v' repository is a vanilla clone of Linus's upstream linux-2.6.git\n> kernel tree with no other modifications done to it.\n>\n> dione:~> git-clone v linux-tmp4\n> Initialized empty Git repository in /home/mingo/linux-tmp4/.git/\n> 0 blocks\n> Checking out files: 100% (23809/23809), done.\n> dione:~> cd linux-tmp4/\n> dione:~/linux-tmp4> ls\n> COPYING MAINTAINERS arch fs kernel samples usr\n> CREDITS Makefile block include lib scripts virt\n> Documentation README crypto init mm security\n> Kbuild REPORTING-BUGS drivers ipc net sound\n>\n> #\n> # ok, so far so good. done this a thousand times before.\n> #\n> # Now lets check out v2.6.24 and check whether the bug i'm interested\n> # in triggers on v2.6.24. I dont create an extra branch for it, because\n> # this is pure temporary work, i use a plain git-checkout as a\n> # throwaway temporary branch:\n> #\n>\n> dione:~/linux-tmp4> git-checkout v2.6.24\n> Note: moving to \"v2.6.24\" 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 4991408... Linux 2.6.24\n>\n> #\n> # i build that kernel and boot it - the bug doesnt trigger - good.\n> # We've got all prerequisites for a bisection session - a 'good' kernel\n> # [v2.6.24] and a 'bad' kernel [HEAD].\n> #\n> #\n>\n> dione:~/linux-tmp4> git-bisect start\n> fatal: ref HEAD is not a symbolic ref\n> won't bisect on seeked tree\n\nYeah, it seems that this is a left over from cogito. \nThere has been some work on it lately but it seems not enough. See:\n\nhttp://git.kernel.org/?p=git/git.git;a=commitdiff;h=0f497e75f05cdf0c0c1278eaba898cda6f118d71\n\n> #\n> # Hm. It's not a symbolic ref, and git-bisect just wont do it. Ok but\n> # then what, and what can the user do to progress? It should be rather\n> # clear to Git what i'm intending to do here. I'm not interested in\n> # HEAD at all, i want to start bisection and i'll feed the good/bad\n> # points to git-bisect - once it lets me do that.\n> #\n> # Ok, lets see where we are:\n> #\n>\n> dione:~/linux-tmp4> git-branch -a\n> * (no branch)\n> master\n> origin/HEAD\n> origin/master\n> origin/new_branch\n>\n> #\n> # So perhaps this new, unnamed branch is what is causing the trouble?\n> # Lets try a specific branch then:\n> #\n>\n> dione:~/linux-tmp4> git-checkout master\n> Previous HEAD position was 4991408... Linux 2.6.24\n> Switched to branch \"master\"\n>\n> dione:~/linux-tmp4> git-bisect start\n> won't bisect on seeked tree\n\nThis seems to work for me with git 1.5.5 on the git tree:\n\n$ git checkout master\nSwitched to branch \"master\"\nYour branch is ahead of the tracked remote branch 'origin/master' by 4 \ncommits.\n$ git bisect start\n$ \n\nWhat git version do you have ?\n\n> #\n> # Hm, still no go. Lets see what git-bisect has to offer:\n> #\n>\n> dione:~/linux-tmp4> git-bisect\n> Usage: /usr/bin/git-bisect\n> [start|bad|good|skip|next|reset|visualize|replay|log|run]\n>\n> #\n> # Ah, it has a reset thing, lets try it:\n> #\n>\n> dione:~/linux-tmp4> git-bisect reset\n> Note: moving to \"49914084e797530d9baaf51df9eda77babc98fa8\" which isn't a\n> 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 4991408... Linux 2.6.24\n>\n> dione:~/linux-tmp4> git-bisect start\n> fatal: ref HEAD is not a symbolic ref\n\nThis probably come from previous failures.\n\n> #\n> # hm, still no go. I'm not interested in a new branch at all, but i\n> # want to bisect, so lets try what was suggested then and name the\n> # branch:\n> #\n>\n> dione:~/linux-tmp4> git-checkout -b tmp\n> Switched to a new branch \"tmp\"\n>\n> #\n> # Looks good so far - can i bisect?\n> #\n>\n> dione:~/linux-tmp4> git-bisect start\n> won't bisect on seeked tree\n\nThis too.\n\n> #\n> # Hm, still no go. Ok, lets forget this whole temporary branch thing\n> # that looked good and try a more pristine state:\n> #\n>\n> dione:~/linux-tmp4> git-checkout -b tmp2 master\n> Previous HEAD position was 4991408... Linux 2.6.24\n> Switched to a new branch \"tmp2\"\n>\n> dione:~/linux-tmp4> git-bisect start\n>\n> #\n> # Halleluya! While i have typed much more than i wanted, and ended up\n> # with two extra branches that i have to throw away, it seems to be\n> # working! Although the command printing nothing is not really\n> # reassuring - did it really do something?\n> #\n> # Ok, lets get the bisection going now:\n> #\n>\n> dione:~/linux-tmp4> git-bisect good v2.6.24 bad HEAD\n> dione:~/linux-tmp4>\n\nThis is really bad, because, as you can see from the man page or \"git \nbisect -h\" (see also the patch I just sent), \"git bisect good\" can take \nmany known good revisions: \n\ngit bisect good [...]\n mark ... known-good revisions.\n\nSo you marked also \"bad\" and HEAD as \"good\".\n\nThis is really strange, because here I get for example:\n\n$ git-bisect good bad HEAD\nBad rev input: bad HEAD\n\nSo you must have something tagged as \"bad\" or have a \"bad\" branch, and \nthat's why the command works for you but does the wrong thing.\n\nIf you wanted to do it all in one command you could have done:\n\n$ git bisect start HEAD v2.6.24\n\nThat would have marked HEAD as \"bad\" and v2.6.24 as \"good\":\n\ngit bisect start [ [...]] [--] [...]\n reset bisect state and start bisection.\n\n> #\n> # Hm, no indication about what happened, and no \"middle\" bisection\n> # point offered. No way to figure out what's wrong.\n\nRight, we probably need to have at look at this more closely, maybe warn if \na \"bad\" or a \"good\" tag or branch exists or something like that.\n\n> # Ok, backtrack one more step - something's wrong here. Lets start\n> # again with a completely new tree:\n> #\n>\n> dione:~> git-clone v linux-tmp5\n> Initialized empty Git repository in /home/mingo/linux-tmp5/.git/\n> 0 blocks\n> Checking out files: 100% (23809/23809), done.\n> dione:~> cd linux-tmp5/\n> dione:~/linux-tmp5> git-checkout -b tmp master\n> Switched to a new branch \"tmp\"\n> dione:~/linux-tmp5> git-bisect start good v2.6.24\n\nThis marked \"good\" as \"bad\" and \"v2.6.24\" as \"good\".\n\nAgain this should \"work\" only if you have a \"good\" tag or branch in your \nrepo.\n\n> dione:~/linux-tmp5> cd\n> dione:~> cd linux-tmp5/\n> dione:~/linux-tmp5> git-bisect start good v2.6.24 bad master\n\nThis marked \"good\" as \"bad\", and \"v2.6.24\", \"bad\" and \"master\" as \"good\".\n\n> dione:~/linux-tmp5>\n>\n> #\n> # Hm, nothing. Ho hum. Do i suck this much? One more tree than i wanted\n> # and three more branches that i wanted and still no bisection?\n> #\n> # Ah, i must have switched the arguments?\n> #\n>\n> dione:~/linux-tmp5> git-bisect start v2.6.24 good master bad\n> won't bisect on seeked tree\n\nThis marked \"v2.6.24\" as \"bad\", and \"good\", \"master\" and \"bad\" as \"good\".\nSo it's wrong too.\n\n> #\n> # Nope.\n> #\n>\n> dione:~/linux-tmp5> git-bisect visualize\n> You need to give me at least one good and one bad revisions.\n> (You can use \"git bisect bad\" and \"git bisect good\" for that.)\n> dione:~/linux-tmp5> git bisect bad HEAD\n> dione:~/linux-tmp5> git bisect good v2.6.24\n> Bisecting: -1 revisions left to test after this\n> [eb36f4fc019835cecf0788907f6cab774508087b] fix oops on rmmod capidrv\n\nThat's much better but you didn't \"reset\" or \"start\" again before giving it \ncorrectly the good and bad revs, so there are still some wrong left over \nfrom your previous start above.\n\n> #\n> # -1 revisions left to test? Ouch ...\n> #\n> # But why did \"git bisect\" make a difference to \"git-bisect\" ?\n\nIt should not have made any difference.\n\n> # Lets see whether it's all from the same package:\n> #\n>\n> dione:~> type git\n> git is hashed (/usr/bin/git)\n> dione:~> type git-bisect\n> git-bisect is hashed (/usr/bin/git-bisect)\n> dione:~> rpm -qf /usr/bin/git-bisect\n> git-core-1.5.4.3-2.fc8\n> dione:~> rpm -qf /usr/bin/git\n> git-core-1.5.4.3-2.fc8\n>\n> #\n> # Yup, it is. 20 minutes spent on this already and no bisection.\n> # I really suck today :-)\n> #\n>\n> #\n> # So i started suspecting my kernel and my hardware. Are timestamps\n> # maybe messed up and confusing Git? Since the commands dont return\n> # success nor failure i was unsure what Git thought about my attempts.\n> #\n> # So i rebooted the box and created a new tree. No go.\n> #\n>\n> #\n> # Just to be sure i also waited through a full git-fsck, only 10\n> # minutes runtime:\n> #\n>\n> dione:~/linux-tmp4> git-fsck --full --strict\n> dangling commit f4be31ec9690cfe6e94fcbed6ae60a6a38b3c3ed\n> dione:~/linux-tmp4>\n>\n> #\n> # [ Sidenote #1: git-fsck is such a heavy operation that it should\n> # really return some indication by default that it's all appears OK.\n> # A user typically only runs git-fsck if in deep doubt about some\n> # git detail - so while silence is often good for a comment, it's\n> # counter-intuitive here. Especially since the \"breakage\" of\n> # git-bisect is \"silence\" too, so the user is unable to trust these\n> # different modal forms of silence and gets frustrated ... ]\n> #\n\nI cannot comment on \"git fsck\" but I think it has nothing to do with \nbisect \"breakages\".\n\n> #\n> # [ Sidenote #2: git-fsck --full --strict is slow and we always knew\n> # this - it's a last-ditch thing for the truly hopeless. But this is\n> # a 3.2 GHz quad box that is only 25% utilized during git-fsck but\n> # takes 10 minutes to finish. Presumably git-fsck could run multiple\n> # threads/tasks to be sped up? Making the slowest possible operation\n> # of a tool significantly faster is a good way to reduce user\n> # frustration IMO. A user is already frustrated enough when he tries\n> # --full --strict. And i _bet_ a parallel version of git-fsck would\n> # also be an fantastic bad-RAM checker ;-) ]\n> #\n>\n> #\n> # Then, many other silly attempts later and at linux-tmp8, by chance -\n> # 30 minutes down the line - i got it going:\n> #\n> # I updated my Linus tree on the (rather pathetic) theory that maybe a\n> # specific layout of the repo breaks bisection - and that seems to have\n> # made a difference:\n> #\n>\n> dione:~/linux-tmp8> git-checkout -b tmp2 master\n> Switched to a new branch \"tmp2\"\n> dione:~/linux-tmp8> git-bisect start\n> won't bisect on seeked tree\n> dione:~/linux-tmp8> git-bisect reset\n> Switched to branch \"master\"\n> dione:~/linux-tmp8> git-bisect bad master\n> You need to start by \"git bisect start\"\n> Do you want me to do it for you [Y/n]? Y\n> dione:~/linux-tmp8> git-bisect good v2.6.24\n> Bisecting: 6270 revisions left to test after this\n> [4814bdbd590e835ecec2d5e505165ec1c19796b2] [NETNS]: Lookup in FIB\n> semantic hashes taking into account the namespace.\n>\n> #\n> # But i dont understand why.\n\nI hope you understand better now.\n\n> # Before updating Linus's tree i saved away \n> # the commit ID that showed the breakage, just in case it matters:\n> #\n>\n> commit 7180c4c9e09888db0a188f729c96c6d7bd61fa83\n> Merge: 4c3b01f... 869ab51...\n> Author: Linus Torvalds \n> Date: Mon Apr 7 19:15:35 2008 -0700\n>\n> #\n> # .. but couldnt reproduce this weirdness with specifically checking\n> # out 7180c4c9e09888db0a188f729c96c6d7bd61fa83. But i still have the\n> # linux-tmp4 repository that shows this behavior reliably. It's all\n> # quite weird. Either this repo is corrupted in some special way, or my\n> # hardware has some really strange runtime failure, or i'm missing\n> # something very obvious ;-)\n> #\n>\n> #\n> # One more minor sidenote. Git-bisect creates its own branch:\n> #\n>\n> dione:~/linux-tmp12> git-branch -a\n> * bisect\n> master\n> tmp\n> tmp2\n> origin/HEAD\n> origin/master\n> origin/new_branch\n>\n> #\n> # So i assumed that i could get rid of that 'bisect' branch by doing\n> # the obvious: \"git-bisect stop\", but no go:\n> #\n>\n> dione:~/linux-tmp12> git-bisect stop\n> Usage: /usr/bin/git-bisect\n> [start|bad|good|skip|next|reset|visualize|replay|log|run]\n>\n> #\n> # After some experimentation \"git-bisect reset\" did the trick - but\n> # it's a bit counter-intuitive IMO, because the logical extension of\n> # 'start' is 'stop', and i often use 'git-bisect reset' to just restart\n> # bisection anew. (it chimes in on 'restart')\n> #\n\n\"git bisect start\" also does a \"restart\" if a bisect is already started.\nBut yes, we could add \"stop\" as a synonym for \"reset\" and \"restart\" as a \nsynonym for \"start\".\n\nThanks,\nChristian.\n\n> #\n> # Ok, that's all for today. :-)\n> #\n>\n> \tIngo\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"74114","messageId":"7vhce9szmt.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080410114739.GA15229@elte.hu","subject":"Re: git-bisect annoyances","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-11T05:56:42Z","receivedAt":"2008-04-11T05:56:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ingo Molnar writes:\n\n> dione:~/linux-tmp4> git-bisect start\n> fatal: ref HEAD is not a symbolic ref\n> won't bisect on seeked tree\n>\n> #\n> # Hm. It's not a symbolic ref, and git-bisect just wont do it.\n\nEnough people were unhappy with this historical wart and we stopped\nrefusing to \"bisect on seeked tree\" since b577bb9 (Eliminate confusing\n\"won't bisect on seeked tree\" failure, 2008-02-23); you should find it as\npart of the 1.5.5 release.\n\nThe disturbing \"fatal: ref HEAD not a symref\" is still there even though\nit should be harmless. The message should be squelched.\n"},{"id":"74115","messageId":"20080411070016.GA25970@diana.vm.bytemark.co.uk","threadId":"13037","inReplyTo":"32541b130804100805o4ad1e9a6x38e9b1fcf17c5d1d@mail.gmail.com","subject":"Re: git annoyances","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-04-11T07:00:16Z","receivedAt":"2008-04-11T07:00:16Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-04-10 11:05:07 -0400, Avery Pennarun wrote:\n\n> On Thu, Apr 10, 2008 at 4:41 AM, Karl Hasselström wrote:\n>\n> > The @rev is called a \"peg revision\", and is different from the\n> > \"operative revision\" specified with the -r flag. The peg revision\n> > is used in conjunction with a path to specify the file (or\n> > directory) you want, and the operative revision is used to specify\n> > which revision of that file you mean.\n>\n> Yes, but I believe you get the one from @rev if you don't specify\n> -r.\n>\n> For example, I can ask for an \"svn diff svn://blahblah@56\n> svn://blahblah@59\" and it'll feed it to me as expected.\n\nAh, I didn't know that. But the URL I threw at you agrees:\n\n> Note that even when you don't explicitly supply a peg revision or\n> operative revision, they are still present. For your convenience,\n> the default peg revision is BASE for working copy items and HEAD for\n> repository URLs. And when no operative revision is provided, it\n> defaults to being the same revision as the peg revision.\n\nClearly, I need to use Subversion more, and not fool around with git\nall the time. :-)\n\n> > (This complexity is needed because subversion has a concept of\n> > file identity.)\n>\n> File renames make diffing and merging complicated no matter whether\n> you track them or not.\n>\n> svn's tracking of file identity is additional, but doesn't increase\n> the (UI) complexity in the common case. At least with svn, a newbie\n> can even get real work done without even knowing about -r *or*\n> @notation.\n\nI don't quite agree with you here. Subversion stores extra state, and\nthat state needs to be considered (in the general case) when\npredicting what Subversion will do. There are a large number of simple\ncases where the user doesn't have to care, as you say, but every so\noften there's a case that's not so simple, and in those cases I\n_really_ prefer git's data model to Subversion's.\n\n> Compare that to arbitrary differences in behaviour between\n> \"git-fetch\" vs \"git-fetch a\" vs \"git-fetch a b\", or the difference\n> between HEAD^ and HEAD~1 and HEAD@1. git is very powerful, but also\n> definitely more complex for beginners.\n\nOh, I'm not arguing on that point. I like git because it's beutiful on\nthe _inside_.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"74117","messageId":"20080411101516.GA31248@bit.office.eurotux.com","threadId":"13037","inReplyTo":"20080409101428.GA2637@elte.hu","subject":"Re: git annoyances","fromName":"Luciano Rocha","fromEmail":"luciano@eurotux.com","sentAt":"2008-04-11T10:15:17Z","receivedAt":"2008-04-11T10:15:17Z","isPatch":false,"sender":{"key":"luciano@eurotux.com","avatar":null},"body":"\nAnother inconsistency:\n$ git remote prune\nusage: git remote\n or: git remote add \n or: git remote rm \n or: git remote show \n or: git remote prune \n or: git remote update [group]\n\nshow specific options\n -n, --dry-run dry run\n\nIt took me a while to parse the \"show specific options\" properly.\n\nWouldn't \"specific options for show\" be better?\n\n-- \nLuciano Rocha \nEurotux Informática, S.A. \n"},{"id":"74118","messageId":"01C218CC-9F7C-47C9-A47B-4127E0886DFC@wincent.com","threadId":"13037","inReplyTo":"20080411101516.GA31248@bit.office.eurotux.com","subject":"Re: git annoyances","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-04-11T10:27:18Z","receivedAt":"2008-04-11T10:27:18Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 11/4/2008, a las 12:15, Luciano Rocha escribió:\n>\n> Another inconsistency:\n> $ git remote prune\n> usage: git remote\n> or: git remote add \n> or: git remote rm \n> or: git remote show \n> or: git remote prune \n> or: git remote update [group]\n>\n> show specific options\n> -n, --dry-run dry run\n>\n> It took me a while to parse the \"show specific options\" properly.\n>\n> Wouldn't \"specific options for show\" be better?\n\nYes, or failing that: \"show-specific options:\"\n\nWithout the hyphen \"show specific options\" reads as \"verb adjective \nnoun\".\n\nCheers,\nWincent\n"},{"id":"74120","messageId":"20080411114104.GE9205@elte.hu","threadId":"13037","inReplyTo":"200804110741.40732.chriscool@tuxfamily.org","subject":"Re: git-bisect annoyances","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-04-11T11:41:04Z","receivedAt":"2008-04-11T11:41:04Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Christian Couder wrote:\n\n> > #\n> > # So perhaps this new, unnamed branch is what is causing the trouble?\n> > # Lets try a specific branch then:\n> > #\n> >\n> > dione:~/linux-tmp4> git-checkout master\n> > Previous HEAD position was 4991408... Linux 2.6.24\n> > Switched to branch \"master\"\n> >\n> > dione:~/linux-tmp4> git-bisect start\n> > won't bisect on seeked tree\n> \n> This seems to work for me with git 1.5.5 on the git tree:\n\n> What git version do you have ?\n\ngit-core-1.5.4.3-2.fc8, like for the previous report.\n\nand it worked for me too in a later tree - so the condition seems \ntransient.\n\n> > dione:~/linux-tmp4> git-bisect good v2.6.24 bad HEAD\n> > dione:~/linux-tmp4>\n> \n> This is really bad, because, as you can see from the man page or \"git \n> bisect -h\" (see also the patch I just sent), \"git bisect good\" can \n> take many known good revisions:\n> \n> git bisect good [...]\n> mark ... known-good revisions.\n> \n> So you marked also \"bad\" and HEAD as \"good\".\n> \n> This is really strange, because here I get for example:\n> \n> $ git-bisect good bad HEAD\n> Bad rev input: bad HEAD\n> \n> So you must have something tagged as \"bad\" or have a \"bad\" branch, and \n> that's why the command works for you but does the wrong thing.\n\nno, there are no 'bad' braches or revisions.\n\nand ... if \"git-bisect good X bad Y\" is invalid syntax it should be \ndetected by the tool ... I did not think up that syntax myself, i think \ni saw it somewhere else mentioned by someone and found it logical. \nWeird. Generally i do use the separate commands though.\n\n> > dione:~/linux-tmp5> git-bisect visualize\n> > You need to give me at least one good and one bad revisions.\n> > (You can use \"git bisect bad\" and \"git bisect good\" for that.)\n> > dione:~/linux-tmp5> git bisect bad HEAD\n> > dione:~/linux-tmp5> git bisect good v2.6.24\n> > Bisecting: -1 revisions left to test after this\n> > [eb36f4fc019835cecf0788907f6cab774508087b] fix oops on rmmod capidrv\n> \n> That's much better but you didn't \"reset\" or \"start\" again before \n> giving it correctly the good and bad revs, so there are still some \n> wrong left over from your previous start above.\n> \n> > #\n> > # -1 revisions left to test? Ouch ...\n> > #\n> > # But why did \"git bisect\" make a difference to \"git-bisect\" ?\n> \n> It should not have made any difference.\n\nit probably didnt - i was just grasping at straws because there was no \nreassuring feedback about what happened so my confidence about my \n_assumptions_ what was happening in the background gradually eroded so i \nwent in larger and larger circles around the problem dropping more and \nmore assumptions and re-checking them.\n\nBut i pasted this directly from that session so the \"-1\" is definitely \nnot imaginery and it is anomalous.\n\n\tIngo\n"},{"id":"74125","messageId":"alpine.DEB.1.00.0804111621080.31025@eeepc-johanness","threadId":"13037","inReplyTo":"1207869946-17013-1-git-send-email-g2p.code@gmail.com","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-11T15:21:45Z","receivedAt":"2008-04-11T15:21:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Apr 2008, Gabriel wrote:\n\n> +\telse {\n> +\t\tprintf (\"Added remote repository `%s' without fetching it.\\n\"\n> +\t\t\t\"Before accessing the branches of this \"\n> +\t\t\t\"remote, run `git fetch %s' \"\n> +\t\t\t\"or `git remote update'.\\n\", name, name);\n\nIs this really, really necessary? I was quite happy when a few people \nmade Git less chatty, recently.\n\nCiao,\nDscho\n"},{"id":"74132","messageId":"20080411203501.7095b866@localhost","threadId":"13037","inReplyTo":"alpine.DEB.1.00.0804111621080.31025@eeepc-johanness","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Gabriel","fromEmail":"g2p.code@gmail.com","sentAt":"2008-04-11T18:35:01Z","receivedAt":"2008-04-11T18:35:01Z","isPatch":true,"sender":{"key":"g2p.code@gmail.com","avatar":null},"body":"Le Fri, 11 Apr 2008 16:21:45 +0100 (BST),\nJohannes Schindelin a écrit :\n\n> Hi,\nHi\n\n> On Fri, 11 Apr 2008, Gabriel wrote:\n> \n> > +\telse {\n> > +\t\tprintf (\"Added remote repository `%s' without\n> > fetching it.\\n\"\n> > +\t\t\t\"Before accessing the branches of this \"\n> > +\t\t\t\"remote, run `git fetch %s' \"\n> > +\t\t\t\"or `git remote update'.\\n\", name, name);\n> \n> Is this really, really necessary? I was quite happy when a few\n> people made Git less chatty, recently.\n\nNot necessary, but a real usability improvement.\n\nI think the transcript that started the thread makes it clear that\nhaving \"git remote add\" not fetching is not the right default.\nThe user wants to use a remote repository, and has learned these are\ncalled \"remotes\". So he does not have too much trouble\nfinding/remembering the command \"git remote add \". Now with\nthe user's goal in mind, it makes no sense to add a remote and then not\nfetch it, because the user definitely wants to do something with the\nremote. By not fetching it, we are surprising the user (this is\napparent in the transcript), maybe we are making him go through some\ndocumentation, and he will have to go through a mental\nchecklist \"did I add the remote? yes. did I fetch it? yes\" later on.\n\nThe best solution is a patch that makes --fetch default to yes for git\nremote add and discuss that.\n\nIn case the remote wasn't fetched, adding some documentation at a place\nwhere it _will_ be needed does no harm. This is not an operation as\nfrequent as git status or git checkout, so the three lines it takes in\na terminal aren't expensive. A more experienced user that usually runs\n\"git remote add -f\", will not see it either.\n\n-- \nGabriel\n"},{"id":"74133","messageId":"1207939163-24787-1-git-send-email-g2p.code@gmail.com","threadId":"13037","inReplyTo":"20080411203501.7095b866@localhost","subject":"[PATCH] Default to fetching a remote after adding it.","fromName":"Gabriel","fromEmail":"g2p.code@gmail.com","sentAt":"2008-04-11T18:39:23Z","receivedAt":"2008-04-11T18:39:23Z","isPatch":true,"sender":{"key":"g2p.code@gmail.com","avatar":null},"body":"This is what the user wants in 99% of cases.\n\nSigned-off-by: Gabriel \n---\n Documentation/git-remote.txt | 4 ++--\n builtin-remote.c | 2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\nindex 2cbd1f7..04de972 100644\n--- a/Documentation/git-remote.txt\n+++ b/Documentation/git-remote.txt\n@@ -10,7 +10,7 @@ SYNOPSIS\n --------\n [verse]\n 'git-remote'\n-'git-remote' add [-t ] [-m ] [-f] [--mirror] \n+'git-remote' add [-t ] [-m ] [--no-fetch] [--mirror] \n 'git-remote' rm \n 'git-remote' show \n 'git-remote' prune \n@@ -34,7 +34,7 @@ Adds a remote named for the repository at\n . The command `git fetch ` can then be used to create and\n update remote-tracking branches /.\n +\n-With `-f` option, `git fetch ` is run immediately after\n+Without the `--no-fetch` option, `git fetch ` is run immediately after\n the remote information is set up.\n +\n With `-t ` option, instead of the default glob\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex 044215a..c0d7d96 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -54,7 +54,7 @@ static int fetch_remote(const char *name)\n \n static int add(int argc, const char **argv)\n {\n-\tint fetch = 0, mirror = 0;\n+\tint fetch = 1, mirror = 0;\n \tstruct path_list track = { NULL, 0, 0 };\n \tconst char *master = NULL;\n \tstruct remote *remote;\n-- \n1.5.5.25.g17ee\n"},{"id":"74135","messageId":"20080411190816.GA17277@mithlond","threadId":"13037","inReplyTo":"20080411203501.7095b866@localhost","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-11T19:08:16Z","receivedAt":"2008-04-11T19:08:16Z","isPatch":true,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Gabriel wrote (2008-04-11 20:35 +0200):\n\n> I think the transcript that started the thread makes it clear that\n> having \"git remote add\" not fetching is not the right default. The\n> user wants to use a remote repository, and has learned these are\n> called \"remotes\". So he does not have too much trouble\n> finding/remembering the command \"git remote add \". Now\n> with the user's goal in mind, it makes no sense to add a remote and\n> then not fetch it, because the user definitely wants to do something\n> with the remote. By not fetching it, we are surprising the user \n\nHmm, I'm quite newbie but I have never expected \"git remote add\" to\nfetch anything. I wouldn't want it to do it automatically. From the\nbeginning I saw \"git remote\" as a _configuration_ tool. No doubt it's\ncommon to fetch after configuring a remote but in my mind they are two\nlogically different steps (configure, fetch/pull) which I think should\nbe kept separate. Once I have configured something I may want to check\nthat I did the right thing, then configure some more remotes and maybe\nfetch tomorrow. Maybe I don't want to fetch at all but only pull from\nthat remote. So let's not build ready workflows for users, only\nconvenient, logical tools.\n\nThat said, I don't mind short messages like \"use 'git fetch' to obtain\nbranches\" but I don't think that is necessary.\n"},{"id":"74136","messageId":"9b3e2dc20804111217n1b45f78fh27363b76283219d8@mail.gmail.com","threadId":"13037","inReplyTo":"1207939163-24787-1-git-send-email-g2p.code@gmail.com","subject":"Re: [PATCH] Default to fetching a remote after adding it.","fromName":"Stephen Sinclair","fromEmail":"radarsat1@gmail.com","sentAt":"2008-04-11T19:17:50Z","receivedAt":"2008-04-11T19:17:50Z","isPatch":true,"sender":{"key":"radarsat1@gmail.com","avatar":null},"body":"On Fri, Apr 11, 2008 at 2:39 PM, Gabriel wrote:\n> This is what the user wants in 99% of cases.\n\nWhere did you get these magical statistics?\nI, for one, have never expected this behaviour.\n\nSteve\n"},{"id":"74138","messageId":"1207942169-2644-1-git-send-email-g2p.code@gmail.com","threadId":"13037","inReplyTo":"20080411203501.7095b866@localhost","subject":"[PATCH] Default to fetching a remote after adding it.","fromName":"Gabriel","fromEmail":"g2p.code@gmail.com","sentAt":"2008-04-11T19:29:29Z","receivedAt":"2008-04-11T19:29:29Z","isPatch":true,"sender":{"key":"g2p.code@gmail.com","avatar":null},"body":"This is what the user wants in 99% of cases.\n\nSigned-off-by: Gabriel \n---\n\nAlso update some tests; disregard the previous patch.\n\n Documentation/git-remote.txt | 4 ++--\n builtin-remote.c | 2 +-\n t/t5503-tagfollow.sh | 2 +-\n t/t5512-ls-remote.sh | 2 +-\n 4 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt\nindex 2cbd1f7..04de972 100644\n--- a/Documentation/git-remote.txt\n+++ b/Documentation/git-remote.txt\n@@ -10,7 +10,7 @@ SYNOPSIS\n --------\n [verse]\n 'git-remote'\n-'git-remote' add [-t ] [-m ] [-f] [--mirror] \n+'git-remote' add [-t ] [-m ] [--no-fetch] [--mirror] \n 'git-remote' rm \n 'git-remote' show \n 'git-remote' prune \n@@ -34,7 +34,7 @@ Adds a remote named for the repository at\n . The command `git fetch ` can then be used to create and\n update remote-tracking branches /.\n +\n-With `-f` option, `git fetch ` is run immediately after\n+Without the `--no-fetch` option, `git fetch ` is run immediately after\n the remote information is set up.\n +\n With `-t ` option, instead of the default glob\ndiff --git a/builtin-remote.c b/builtin-remote.c\nindex 044215a..c0d7d96 100644\n--- a/builtin-remote.c\n+++ b/builtin-remote.c\n@@ -54,7 +54,7 @@ static int fetch_remote(const char *name)\n \n static int add(int argc, const char **argv)\n {\n-\tint fetch = 0, mirror = 0;\n+\tint fetch = 1, mirror = 0;\n \tstruct path_list track = { NULL, 0, 0 };\n \tconst char *master = NULL;\n \tstruct remote *remote;\ndiff --git a/t/t5503-tagfollow.sh b/t/t5503-tagfollow.sh\nindex 86e5b9b..fd075d9 100755\n--- a/t/t5503-tagfollow.sh\n+++ b/t/t5503-tagfollow.sh\n@@ -134,7 +134,7 @@ test_expect_success 'new clone fetch master and tags' '\n \t\tmkdir clone2 &&\n \t\tcd clone2 &&\n \t\tgit init &&\n-\t\tgit remote add origin .. &&\n+\t\tgit remote add origin .. --no-fetch &&\n \t\tGIT_DEBUG_SEND_PACK=3 git fetch 3>../$U &&\n \t\ttest $B = $(git rev-parse --verify origin/master) &&\n \t\ttest $S = $(git rev-parse --verify tag2) &&\ndiff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh\nindex c0dc949..08855ed 100755\n--- a/t/t5512-ls-remote.sh\n+++ b/t/t5512-ls-remote.sh\n@@ -17,7 +17,7 @@ test_expect_success setup '\n \t\tgit show-ref -d\t| sed -e \"s/ /\t/\"\n \t) >expected.all &&\n \n-\tgit remote add self $(pwd)/.git\n+\tgit remote add self $(pwd)/.git --no-fetch\n \n '\n \n-- \n1.5.5.25.g9415\n"},{"id":"74139","messageId":"95DDA63A-EF82-430C-B4DB-7679858E0506@wincent.com","threadId":"13037","inReplyTo":"1207942169-2644-1-git-send-email-g2p.code@gmail.com","subject":"Re: [PATCH] Default to fetching a remote after adding it.","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-04-11T19:36:27Z","receivedAt":"2008-04-11T19:36:27Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 11/4/2008, a las 21:29, Gabriel escribió:\n> This is what the user wants in 99% of cases.\n\nNot sure about that. I often add a remote then push, not fetch.\n\nCheers,\nWincent\n"},{"id":"74140","messageId":"ftof7g$78v$1@ger.gmane.org","threadId":"13037","inReplyTo":"95DDA63A-EF82-430C-B4DB-7679858E0506@wincent.com","subject":"Re: [PATCH] Default to fetching a remote after adding it.","fromName":"Gabriel","fromEmail":"g2p.code@gmail.com","sentAt":"2008-04-11T19:46:56Z","receivedAt":"2008-04-11T19:46:56Z","isPatch":true,"sender":{"key":"g2p.code@gmail.com","avatar":null},"body":"On Fri, 11 Apr 2008 21:36:27 +0200, Wincent Colaiuta wrote:\n\n> El 11/4/2008, a las 21:29, Gabriel escribió:\n>> This is what the user wants in 99% of cases.\n> \n> Not sure about that. I often add a remote then push, not fetch.\n\nI didn't see that.\n\nWell, disregard this patch, it was a bad idea to change that default.\n"},{"id":"74147","messageId":"7v4pa8rs00.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080411190816.GA17277@mithlond","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-11T21:39:11Z","receivedAt":"2008-04-11T21:39:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Teemu Likonen writes:\n\n> Gabriel wrote (2008-04-11 20:35 +0200):\n>\n>> I think the transcript that started the thread makes it clear that\n>> having \"git remote add\" not fetching is not the right default. The\n>> user wants to use a remote repository, and has learned these are\n>> called \"remotes\". So he does not have too much trouble\n>> finding/remembering the command \"git remote add \". Now\n>> with the user's goal in mind, it makes no sense to add a remote and\n>> then not fetch it, because the user definitely wants to do something\n>> with the remote. By not fetching it, we are surprising the user \n>\n> Hmm, I'm quite newbie but I have never expected \"git remote add\" to\n> fetch anything. I wouldn't want it to do it automatically. From the\n> beginning I saw \"git remote\" as a _configuration_ tool.\n\nGood student ;-).\n\nNot only that fetch-after-add is _not_ a common nor majority thing at all\n(contrary to what Gabriel assumed), the \"fetch\" step is conceptually an\nunrelated operation from the primary point of \"remote add\"; \"-f\" option is\na mere convenience feature and we stop at making it conveniently\navailable, never making it a default nor overly advertising it.\n\nIf the user tells you not to fetch, the command should not bother the user\nwith excess messages, unless the user explicitly asks to, either.\n"},{"id":"74152","messageId":"bd6139dc0804111535y8073d22w79845341394c2067@mail.gmail.com","threadId":"13037","inReplyTo":"7v4pa8rs00.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-04-11T22:35:39Z","receivedAt":"2008-04-11T22:35:39Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Fri, Apr 11, 2008 at 11:39 PM, Junio C Hamano wrote:\n> If the user tells you not to fetch, the command should not bother the user\n> with excess messages, unless the user explicitly asks to, either.\n\nI fully agree here, but is there a way for the user to do so?\nEspecially the beginning user? Perhaps in the form of a -v(erbose)\nswitch, but for that to be useful it would have to be present across\nmost/all commands and have the same (type of) result. That is, it\nshould provide the user with additional information on what they did\nwrong/what they likely want to do from here.\nIn this case though I agree that, as Teemu pointed out, 'git remote\nadd' is a config tool. 'man git remote add' points this out more than\nclearly enough for regular use. Maybe keep it in mind for the to-be\n\"git mind reading\" functionality.\n\nCheers,\n\nSverre Rabbelier\n"},{"id":"74155","messageId":"7vbq4gouej.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"bd6139dc0804111535y8073d22w79845341394c2067@mail.gmail.com","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-11T23:15:32Z","receivedAt":"2008-04-11T23:15:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Rabbelier\" writes:\n\n> On Fri, Apr 11, 2008 at 11:39 PM, Junio C Hamano wrote:\n>> If the user tells you not to fetch, the command should not bother the user\n>> with excess messages, unless the user explicitly asks to, either.\n>\n> I fully agree here, but is there a way for the user to do so?\n> Especially the beginning user? Perhaps in the form of a -v(erbose)\n> switch,...\n\nYeah, I am not sure if that should be called --verbose, but a \"training\nwheel\" mode of operation somebody else mentioned the other day that echoes\nback what the command thinks it was told to do by the user, together with\nhelp text that explains what other things the user could have told to the\ncommand to enrich its operation, might be an interesting addition.\n"},{"id":"74158","messageId":"bd6139dc0804111620g3dc0eca0oe887fd206911329d@mail.gmail.com","threadId":"13037","inReplyTo":"7vbq4gouej.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-04-11T23:20:34Z","receivedAt":"2008-04-11T23:20:34Z","isPatch":true,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Sat, Apr 12, 2008 at 1:15 AM, Junio C Hamano wrote:\n> Yeah, I am not sure if that should be called --verbose, but a \"training\n> wheel\" mode of operation somebody else mentioned the other day that echoes\n> back what the command thinks it was told to do by the user, together with\n> help text that explains what other things the user could have told to the\n> command to enrich its operation, might be an interesting addition.\n\nHmmm, I'm not sure about '--verbose' as a name either, but it -is-\nusually used to display more information about the command(s) being\nexecuted. E.g.:\n-v, --verbose\n\t explain what is being done\nhttp://unixhelp.ed.ac.uk/CGI/man-cgi?mv\nSounds pretty much like what we're doing, explaining what command we\nthing is being executed. The extra text OTOH with 'possible other\nworkflow suggestions' doesn't quite fit in the '--verbose' picture.\nPerhaps a different kind of command, like '--newbie' (or, less\nhumiliating, '--explain') would be more appropriate.\n"},{"id":"74184","messageId":"200804120856.59290.chriscool@tuxfamily.org","threadId":"13037","inReplyTo":"20080411114104.GE9205@elte.hu","subject":"Re: git-bisect annoyances","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2008-04-12T06:56:59Z","receivedAt":"2008-04-12T06:56:59Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Le vendredi 11 avril 2008, Ingo Molnar a écrit :\n> * Christian Couder wrote:\n> > > #\n> > > # So perhaps this new, unnamed branch is what is causing the\n> > > trouble? # Lets try a specific branch then:\n> > > #\n> > >\n> > > dione:~/linux-tmp4> git-checkout master\n> > > Previous HEAD position was 4991408... Linux 2.6.24\n> > > Switched to branch \"master\"\n> > >\n> > > dione:~/linux-tmp4> git-bisect start\n> > > won't bisect on seeked tree\n> >\n> > This seems to work for me with git 1.5.5 on the git tree:\n> >\n> > What git version do you have ?\n>\n> git-core-1.5.4.3-2.fc8, like for the previous report.\n>\n> and it worked for me too in a later tree - so the condition seems\n> transient.\n\nYes, it probably depends on what you have done before.\nI didn't look at it yet, but I will have a look soon.\nAnyway as Junio said, there have been some improvements in 1.5.5 so it might \nbe a good idea to upgrade.\n\n> > > dione:~/linux-tmp4> git-bisect good v2.6.24 bad HEAD\n> > > dione:~/linux-tmp4>\n> >\n> > This is really bad, because, as you can see from the man page or \"git\n> > bisect -h\" (see also the patch I just sent), \"git bisect good\" can\n> > take many known good revisions:\n> >\n> > git bisect good [...]\n> > mark ... known-good revisions.\n> >\n> > So you marked also \"bad\" and HEAD as \"good\".\n> >\n> > This is really strange, because here I get for example:\n> >\n> > $ git-bisect good bad HEAD\n> > Bad rev input: bad HEAD\n> >\n> > So you must have something tagged as \"bad\" or have a \"bad\" branch, and\n> > that's why the command works for you but does the wrong thing.\n>\n> no, there are no 'bad' braches or revisions.\n\nYou are right, we have got some bugs here I think.\n\nIn my case bad and HEAD were neither proper revs, that's why I got an error.\nBut I realized that as long as there is one proper rev in what you give \nto \"git bisect good\" it will ignore bad revs and mark as good the proper \nrev you gave it.\n\nI just sent a patch to fix this, but I am not sure it's the right fix.\nMore work is probably needed. Ooops I just spotted one bug in my patch.\nPlease wait, I will send another one.\n\n> and ... if \"git-bisect good X bad Y\" is invalid syntax it should be\n> detected by the tool ... \n\nYes.\n\nThanks again,\nChristian.\n"},{"id":"74202","messageId":"alpine.DEB.1.00.0804121532550.16366@eeepc-johanness","threadId":"13037","inReplyTo":"1207939163-24787-1-git-send-email-g2p.code@gmail.com","subject":"Re: [PATCH] Default to fetching a remote after adding it.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-12T14:33:30Z","receivedAt":"2008-04-12T14:33:30Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 11 Apr 2008, Gabriel wrote:\n\n> This is what the user wants in 99% of cases.\n\nThis is wrong, at least in my experience. Do not make up statistics if \nyou want to be taken seriously.\n\nCiao,\nDscho\n"},{"id":"74209","messageId":"20080412171332.5abb2705@localhost","threadId":"13037","inReplyTo":"alpine.DEB.1.00.0804121532550.16366@eeepc-johanness","subject":"Re: [PATCH] Default to fetching a remote after adding it.","fromName":"Gabriel","fromEmail":"g2p.code@gmail.com","sentAt":"2008-04-12T15:13:32Z","receivedAt":"2008-04-12T15:13:32Z","isPatch":true,"sender":{"key":"g2p.code@gmail.com","avatar":null},"body":"On Sat, 12 Apr 2008 15:33:30 +0100 (BST),\nJohannes Schindelin wrote:\n\n> Hi,\n> \n> On Fri, 11 Apr 2008, Gabriel wrote:\n> \n> > This is what the user wants in 99% of cases.\n> \n> This is wrong, at least in my experience. Do not make up statistics\n> if you want to be taken seriously.\n\nThis is obviously not a real statistic, and poor wording on my part. It\nwas meant to summarise the justification that I gave in the parent\nmail; that justification was certainly up to discussion, and it turns\nout I was wrong.\n\nWhich leaves us with the other suggestion of the previous patch, that\nothers have discussed. Now that we have the maintainer's opinion, this\nis also settled.\n\nAnyway, it's easy to get into subjective arguments on usability, and\nI'll be more careful about this. Which shouldn't prevent us from\nimproving git usability.\n"},{"id":"74212","messageId":"alpine.DEB.1.00.0804121624040.16366@eeepc-johanness","threadId":"13037","inReplyTo":"20080412171332.5abb2705@localhost","subject":"Re: [PATCH] Default to fetching a remote after adding it.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-12T15:24:25Z","receivedAt":"2008-04-12T15:24:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 12 Apr 2008, Gabriel wrote:\n\n> Now that we have the maintainer's opinion, this is also settled.\n\nThanks for ignoring my opinion.\n\nHave a nice life,\nDscho\n"},{"id":"74224","messageId":"loom.20080412T184726-395@post.gmane.org","threadId":"13037","inReplyTo":"20080409145758.GB20874@sigill.intra.peff.net","subject":"Re: git annoyances","fromName":"Santiago Gala","fromEmail":"sgala@apache.org","sentAt":"2008-04-12T18:59:45Z","receivedAt":"2008-04-12T18:59:45Z","isPatch":false,"sender":{"key":"sgala@apache.org","avatar":"https://gravatar.com/avatar/3ce198370fff616e4d4b6d85d86f657c2d18762b036bf8cdf7330150f51c7558?d=mp&s=160"},"body":"Jeff King peff.net> writes:\n\n(...)\n> Unless you are planning on merging this remote a lot, the common usage\n> is probably to just forget the remote stuff and do:\n> \n> git pull ~/linux-2.6-x86.git latest\n> \n\nWell, he wants to *merge*, not really to *pull*. A problem I'm encountering a\nlot with git is this kind of mismatch between the naming of the command and the\nactions. Most of the time the things make sense when they are explained, but\nthey are not intuitive and I forget them once and again.\n\nI have special problems with \"pull\" and \"fetch\". I mean, for me \"pull\" is about\n\"pulling code\" from other repo, but not really to the working copy, or at least\nnot always to the working copy.\n\nIn fact, the first line of git-pull --help is \"Fetch from and merge with another\nrepository or a local\" (pulling together the other two words, fetch and merge,\nif you allow the pun). For my very limited git intuition, and I guess for a lot\nof people too, pull is just \"fetch\".\n"},{"id":"74247","messageId":"20080413093102.GC12107@mithlond.arda.local","threadId":"13037","inReplyTo":"20080409225112.GB12103@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-13T09:31:02Z","receivedAt":"2008-04-13T09:31:02Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Jeff King wrote (2008-04-09 18:51 -0400):\n\n> On Thu, Apr 10, 2008 at 01:25:00AM +0300, Teemu Likonen wrote:\n> \n> > Another thing I spoke of was this refs/ stuff. I know my way around\n> > with them now, so maybe they are not actually confusing to me\n> > anymore. It's just that I have noticed a pattern: I always use\n> > refs/heads/... in certain places and refs/remotes/ in certain\n> > places. If such a pattern is very common (well, I don't know if it\n> > is) one starts to think that maybe the pattern can/should be hidden\n> > and made part of the tool. Just thoughts.\n> \n> I almost never use refs/remotes/ or refs/heads/. Some effort has been\n> put into doing the right thing with partial refnames (which you can of\n> course override by being more specific). Do you have specific examples\n> of where you use the full refname? I suspect it is either not required\n> (and documentation may be out of date), or it is a bug we could fix.\n> :)\n\nIn real work I have used refs/heads/...:refs/remotes/... only once or\nmaybe twice (I just quite recently started using Git). But when\nI studied Git and the workflows it supports I tried all kinds of\nfetching, pulling and pushing, back and forth, between test repos. There\nI used refs/ paths a lot, almost all the time actually. At first it was\nvery much just trying to see how they work and this is where I found\nthis common pattern: local refs start with refs/heads/ and remote\ntracking ones with refs/remotes/ . Thoughts like \"why not simplify them,\nlike L: for local and R: for remote\" (or something) started to develop.\n\nNow it seems that I have been too much attached to the full refspec\nform. My guide have been the config remote..fetch as \"git remote\nadd\" adds those long refspecs. Now I learnt that almost all refspecs can\nbe written as \"branch:another\" or \"branch:remotes/another\" for example.\nSo the \"friendly refspecs\" are pretty much already there! Well, I've\nbeen stupid. :)\n\n(I understand that in real work when constantly dealing with same remote\nrepos one just adds a remote config and can forget about URLs and\nprobably most of the refspecs too.)\n\nOk, this was partly an RTFM error but even after reading man pages of\nfetch, pull and push it isn't quite clear how to use these short and\nnice and friendly refspecs. I thought about it and decided to add some\nmore examples to fetch manual (see my patch in the next message). My\nEnglish may not be manual-writing quality but I wanted to do something\nuseful anyway. Somebody needs to proof read my text though. Of course\nthere may be some inaccuracies too. Anyway, I think that concrete\nexamples in manuals help people to understand Git better.\n\nThere is still one thing (at least) that I don't quite understand. It's\nabout \"git push\". When I do\n\n $ git push \n\nthe refs/heads/ is updated or created on the remote side. But if\nI do\n\n $ git push :\n\nthe refs/heads/ is not automatically created. Why there is need\nto say \":refs/heads/\" to make it work if \ndoes not exist? The 'git push' manual says something vague about branch\nnot matching (?). What does it mean?\n"},{"id":"74248","messageId":"20080413093424.GA12861@mithlond.arda.local","threadId":"13037","inReplyTo":"20080413093102.GC12107@mithlond.arda.local","subject":"[PATCH] Add examples section to 'git fetch' manual","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-13T09:34:24Z","receivedAt":"2008-04-13T09:34:24Z","isPatch":true,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"This commit adds examples which intend to cover the various ways of\nusing 'git fetch'.\n\nSigned-off-by: Teemu Likonen \n---\n Documentation/git-fetch.txt | 43 ++++++++++++++++++++++++++++++++++++++++++-\n 1 files changed, 42 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt\nindex d982f96..d5b1c9f 100644\n--- a/Documentation/git-fetch.txt\n+++ b/Documentation/git-fetch.txt\n@@ -37,9 +37,50 @@ include::pull-fetch-param.txt[]\n \n include::urls-remotes.txt[]\n \n+EXAMPLES\n+--------\n+\n+git fetch git://host.xz/repo.git/ master:pu::\n+\tFetch branch `master` from given repository URL and store it locally\n+\tas `pu`.\n+\n+git fetch git://host.xz/repo.git/ master:remotes/pu::\n+\tFetch branch `master` from given repository URL and store it locally as\n+\tremote tracking branch `pu`.\n+\n+git fetch git://host.xz/repo.git/ master::\n+\tFetch branch `master` from given repository URL but do not create the\n+\tbranch locally. Only the temporary pointer FETCH_HEAD is set to refer\n+\tto the fetched branch.\n+\n+git fetch /home/bob/tmp/repo.git::\n+\tFetch the currently active branch from given local repository and set\n+\tthe temporary pointer FETCH_HEAD for the fetched branch.\n+\n+git fetch alice master:remotes/alice/pu::\n+\tFetch branch `master` from remote named `alice` and store it locally as\n+\tremote tracking branch `alice/pu`. See linkgit:git-remote[1] for more\n+\tinformation on configuring remotes.\n+\n+git fetch alice +master:remotes/alice/pu::\n+\tThe same as above but the remote tracking branch `alice/pu` is updated\n+\teven if it does not result in a fast forward update.\n+\n+git fetch alice +master:pu maint:tmp::\n+\tFetch branches `master` and `maint` from remote named `alice` and store\n+\tthem locally as `pu` and `tmp` respectively. The branch `pu` is updated\n+\teven if it does not result in a fast forward update.\n+\n+git fetch origin::\n+\tFrom the remote named `origin` fetch and store all branches as\n+\tconfigured in `remote.origin.fetch`. Usually this means fetching all\n+\tbranches and storing them locally as remote tracking branches\n+\t`origin/*`. See linkgit:git-remote[1] for more information.\n+\n+\n SEE ALSO\n --------\n-linkgit:git-pull[1]\n+linkgit:git-pull[1], linkgit:git-remote[1]\n \n \n Author\n-- \n1.5.5.32.g5279\n"},{"id":"74262","messageId":"7v63uld1nu.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080413093424.GA12861@mithlond.arda.local","subject":"Re: [PATCH] Add examples section to 'git fetch' manual","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-13T18:56:21Z","receivedAt":"2008-04-13T18:56:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Teemu Likonen writes:\n\n> +EXAMPLES\n> +--------\n> +\n> +git fetch git://host.xz/repo.git/ master:pu::\n> +\tFetch branch `master` from given repository URL and store it locally\n> +\tas `pu`.\n\nWhile this may technically be correct (and I'll say upfront that all of\nyour \"examples\" may technically be correct), I would suggest strongly\nagainst putting this into EXAMPLES section. People look at examples\nsection to look up something they need to do often; the section should\ndescribe the best practices we can suggest them in real life.\n\nThe above command line is a _great_ way to explain what happens under the\nhood when you have the matching configuration in .git/config for the\nremote, so that people would know how to update .git/config entries from\nwhat git-clone and \"git-remote add\" give them by default to suit their\nneeds (e.g. instead of storing all branches in remotes/origin/*, you can\nconfigure to only fetch and store a few selected branches). But, fetching\nfrom somewhere and storing it explicitly _from the command line_ like your\nexample command line is something you would _never_ do in real life if you\nknow git.\n\n> +git fetch git://host.xz/repo.git/ master:remotes/pu::\n> +\tFetch branch `master` from given repository URL and store it locally as\n> +\tremote tracking branch `pu`.\n\nAnd this example is even worse, as the common example is to have remote\nname between \"remotes\" and \"pu\".\n\n> +git fetch git://host.xz/repo.git/ master::\n> +\tFetch branch `master` from given repository URL but do not create the\n> +\tbranch locally. Only the temporary pointer FETCH_HEAD is set to refer\n> +\tto the fetched branch.\n\nThis one is a fine example of a one-shot command to look at what they\nhave without actually affecting your own history. Use of this form in\nreal life is very sane.\n\n> +git fetch alice master:remotes/alice/pu::\n> +\tFetch branch `master` from remote named `alice` and store it locally as\n> +\tremote tracking branch `alice/pu`. See linkgit:git-remote[1] for more\n> +\tinformation on configuring remotes.\n\nThis is a wrong example on multiple counts (this is one of the worst one\nin your change, so I'll explain in more detail than for others).\n\nFirst of all, think about the reason _why_ the convention is to use a\nseparate namespace under remotes/ per remote. It is to allow us to use\nthe names that correspond to what the remote repository uses without\nhaving to worry about name collisions, and the reason we took pains to\nimplement the mechanism to allow you to use such corresponding names is to\navoid having to remember \"what she calls master is what I call pu\".\n\n\"I want to make sure I can tell my master and her master apart without\nconfusing myself, so I'd call mine master and call hers alice/master\" is\nthe recommended use pattern which \"git clone\" and \"git remote add\" give\nthe user. An EXAMPLE that deviates from it without explaining why/when it\nis a good thing to do is BAD. Remember, many people blindly copy and\npaste the examples section without thinking, assuming that they suggest\nthe best practice.\n\nIf you have nickname \"alice\" defined, you are by definition interacting\nwith her regularly. If you are doing a one-off with such a repository,\nrunning \"git fetch alice master\" and operating on the resulting FETCH_HEAD\n(and you typically use tag or local branch if you want to mark that\ncommit, with \"git tag\" or \"git branch\"), would be much less error prone,\nless confusing, and more straightforward recommended approach. Typically,\nyou would have the usual refs/heads/*:refs/remotes/alice/* fetch refspec,\nso you would not even say \"master\" and instead run \"git fetch alice\" and\nlook at \"remotes/alice/master\".\n\nYour above command line again may be a great way to explain what you could\ndo and what the mechanism is equipped to allow you to, but I do not think\nthere is any reason to use it in the real life. It should not be in the\nEXAMPLE section.\n\n> +git fetch origin::\n> +\tFrom the remote named `origin` fetch and store all branches as\n> +\tconfigured in `remote.origin.fetch`. Usually this means fetching all\n> +\tbranches and storing them locally as remote tracking branches\n> +\t`origin/*`. See linkgit:git-remote[1] for more information.\n\nThis is a valid thing to add to the examples section, although I suspect\npeople would already know it when they encouter this page.\n"},{"id":"74266","messageId":"1c5969370804131248rca9765ei338a70cb6ff304f7@mail.gmail.com","threadId":"13037","inReplyTo":"7v63uld1nu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Add examples section to 'git fetch' manual","fromName":"Matt Graham","fromEmail":"mdg149@gmail.com","sentAt":"2008-04-13T19:48:35Z","receivedAt":"2008-04-13T19:48:35Z","isPatch":true,"sender":{"key":"mdg149@gmail.com","avatar":"https://gravatar.com/avatar/a1f130a60a6550f75e8d7d3849e58e46494f36bfaf764a38cfd695ac85de8576?d=mp&s=160"},"body":"On Sun, Apr 13, 2008 at 2:56 PM, Junio C Hamano wrote:\n> Teemu Likonen writes:\n>\n> > +git fetch origin::\n> > + From the remote named `origin` fetch and store all branches as\n> > + configured in `remote.origin.fetch`. Usually this means fetching all\n> > + branches and storing them locally as remote tracking branches\n> > + `origin/*`. See linkgit:git-remote[1] for more information.\n>\n> This is a valid thing to add to the examples section, although I suspect\n> people would already know it when they encouter this page.\n\nAs a recent CVS emigrant, I'm finding the refspecs one of the more\nconfusing areas of git. I think having good, basic examples might be\nmore helpful than experienced users expect. In my case at least, this\nis a helpful example.\n"},{"id":"74268","messageId":"20080413200500.GA5464@mithlond.arda.local","threadId":"13037","inReplyTo":"7v63uld1nu.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Add examples section to 'git fetch' manual","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-13T20:05:00Z","receivedAt":"2008-04-13T20:05:00Z","isPatch":true,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Junio C Hamano wrote (2008-04-13 11:56 -0700):\n\n> People look at examples section to look up something they need to do\n> often; the section should describe the best practices we can suggest\n> them in real life.\n\nThanks for your explanations, they made a lot of sense. I see, I gave\nexamples of various ways of using \"git fetch\" but they may not reflect\nreal life usage patterns very well. I still feel that refspecs need more\nexplaining (for newbies, that is) so I may later bring another patch\nhopefully with better examples and applicable to real workflows.\n"},{"id":"74293","messageId":"7vprstb64q.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080413200500.GA5464@mithlond.arda.local","subject":"Re: [PATCH] Add examples section to 'git fetch' manual","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-14T01:02:45Z","receivedAt":"2008-04-14T01:02:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Teemu Likonen writes:\n\n> ... I still feel that refspecs need more\n> explaining ...\n\nPerhaps. The basic syntax is \"src colon dst\" and they are used to copy\nwhat's in src to dst, and that is pretty much what's there to it. Some\ndetails such as how the wildcard matching works may be missing from the\ndescription part of the manual, and filling them in would be a good idea.\n\nI however strongly suspect that what new people need to get explained may\nnot be what the mechanism does (e.g. copies the object name recorded as\nthe src ref to the dst ref), nor the syntax you use to tell the mechanism\nwhat to copy where (e.g. src is LHS, dst is RHS, copying \"emptyness\" into\ndst means deleting dst). I actually think that is an easier part.\n\nWhat is more important is the basic concepts like what a ref is, how they\ncan be used and what you can do with them --- understanding of which would\nbe essential in being able to decide when and how you maywant to keep a\ncopy of ref you get from elsewhere and under what name. I think tutorial\nis the best place, and then the description section of the manual the\nsecond best one, to document that kind of things.\n"},{"id":"74409","messageId":"buoabjvrepx.fsf@dhapc248.dev.necel.com","threadId":"13037","inReplyTo":"20080411190816.GA17277@mithlond","subject":"Re: [PATCH] When a remote is added but not fetched, tell the user.","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2008-04-15T03:15:06Z","receivedAt":"2008-04-15T03:15:06Z","isPatch":true,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Teemu Likonen writes:\n> Hmm, I'm quite newbie but I have never expected \"git remote add\" to\n> fetch anything. I wouldn't want it to do it automatically.\n\nI agree.\n\nAn automatic fetch would be ... surprising.\n\n-Miles\n\n-- \n\"Don't just question authority,\nDon't forget to question me.\"\n-- Jello Biafra\n"},{"id":"74497","messageId":"20080416034823.GA11727@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080413093102.GC12107@mithlond.arda.local","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-16T03:48:23Z","receivedAt":"2008-04-16T03:48:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 13, 2008 at 12:31:02PM +0300, Teemu Likonen wrote:\n\n> There is still one thing (at least) that I don't quite understand. It's\n> about \"git push\". When I do\n> \n> $ git push \n> \n> the refs/heads/ is updated or created on the remote side. But if\n> I do\n> \n> $ git push :\n> \n> the refs/heads/ is not automatically created. Why there is need\n> to say \":refs/heads/\" to make it work if \n> does not exist? The 'git push' manual says something vague about branch\n> not matching (?). What does it mean?\n\nThis happens because \"git push \" is expanded locally to\n\"git push :\", but is first expanded\ninto refs/heads/.\n\nThe latter uses the explicit refspec which doesn't get\nexpanded, since it doesn't exist at all, and so we can't deduce the type\n(e.g., refs/heads versus refs/tags).\n\nISTR some discussion in the past few months about using the type of\n to guess the type of , but it seems not to have gone\nanywhere.\n\nDaniel, were you working on this?\n\n-Peff\n"},{"id":"74519","messageId":"20080416042514.GA22179@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080416034823.GA11727@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-16T04:25:14Z","receivedAt":"2008-04-16T04:25:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 15, 2008 at 11:48:23PM -0400, Jeff King wrote:\n\n> ISTR some discussion in the past few months about using the type of\n> to guess the type of , but it seems not to have gone\n> anywhere.\n> \n> Daniel, were you working on this?\n\nHmm. Here is a quick patch I worked up, but it causes t5516:14 (push\nwith ambiguity) to fail. However, I'm not sure the test is right: it\nlooks like it's trying to find ambiguity between remotes/origin/master\nand remotes/frotz/master, but in fact matches _neither_ of them. So it\nwas failing before as we expected, but for the wrong reason.\n\n---\n remote.c | 23 +++++++++++++++++++----\n t/t5516-fetch-push.sh | 8 ++++++++\n 2 files changed, 27 insertions(+), 4 deletions(-)\n\ndiff --git a/remote.c b/remote.c\nindex 08af7f9..2f5d062 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -851,10 +851,25 @@ static int match_explicit(struct ref *src, struct ref *dst,\n \tcase 0:\n \t\tif (!memcmp(dst_value, \"refs/\", 5))\n \t\t\tmatched_dst = make_linked_ref(dst_value, dst_tail);\n-\t\telse\n-\t\t\terror(\"dst refspec %s does not match any \"\n-\t\t\t \"existing ref on the remote and does \"\n-\t\t\t \"not start with refs/.\", dst_value);\n+\t\telse {\n+\t\t\t/*\n+\t\t\t * We don't have a full ref name for the dst and\n+\t\t\t * it doesn't exist, so let's assume it's the same\n+\t\t\t * type as our src.\n+\t\t\t */\n+\t\t\tstruct strbuf tmp = STRBUF_INIT;\n+\t\t\tconst char *c;\n+\t\t\tint slashes;\n+\t\t\tfor (c = matched_src->name, slashes = 0;\n+\t\t\t\t\t*c && slashes < 2; c++) {\n+\t\t\t\tstrbuf_addch(&tmp, *c);\n+\t\t\t\tif (*c == '/')\n+\t\t\t\t\tslashes++;\n+\t\t\t}\n+\t\t\tstrbuf_addstr(&tmp, dst_value);\n+\t\t\tdst_value = strbuf_detach(&tmp, NULL);\n+\t\t\tmatched_dst = make_linked_ref(dst_value, dst_tail);\n+\t\t}\n \t\tbreak;\n \tdefault:\n \t\tmatched_dst = NULL;\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 793ffc6..370f79a 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -285,6 +285,14 @@ test_expect_success 'push with colon-less refspec (4)' '\n \n '\n \n+test_expect_success 'push with non-existant, incomplete dest' '\n+\n+\tmk_test &&\n+\tgit push testrepo master:brandnewbranch &&\n+\tcheck_push_result $the_commit heads/brandnewbranch\n+\n+'\n+\n test_expect_success 'push with HEAD' '\n \n \tmk_test heads/master &&\n-- \n1.5.5.64.geecd2.dirty\n"},{"id":"74515","messageId":"7vabjuv2c2.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080416034823.GA11727@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-16T04:41:17Z","receivedAt":"2008-04-16T04:41:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sun, Apr 13, 2008 at 12:31:02PM +0300, Teemu Likonen wrote:\n>\n>> There is still one thing (at least) that I don't quite understand. It's\n>> about \"git push\". When I do\n>> \n>> $ git push \n>> \n>> the refs/heads/ is updated or created on the remote side. But if\n>> I do\n>> \n>> $ git push :\n>> \n>> the refs/heads/ is not automatically created.\n\nEh, there is no way unless you force an assumption of a particular\nworkflow to everybody else.\n\nWhat you would say on the second command is not literally \"\" but\nsomething like \"work-in-progress\", or \"crap\". Even an AI would not be\nable to guess if you wanted to create a branch on the other side, or\nwanted to put a lightweight tag to let people know where you are (possibly\nwith the intention of removing it once you are done), and git is not an AI.\n"},{"id":"74517","messageId":"20080416044726.GA831@sigill.intra.peff.net","threadId":"13037","inReplyTo":"7vabjuv2c2.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-16T04:47:26Z","receivedAt":"2008-04-16T04:47:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 15, 2008 at 09:41:17PM -0700, Junio C Hamano wrote:\n\n> What you would say on the second command is not literally \"\" but\n> something like \"work-in-progress\", or \"crap\". Even an AI would not be\n> able to guess if you wanted to create a branch on the other side, or\n> wanted to put a lightweight tag to let people know where you are (possibly\n> with the intention of removing it once you are done), and git is not an AI.\n\nOf course it can't guess all cases. But right now you have the option\nof:\n\n 1. specifying the full destination manually\n 2. having git complain, and then doing (1)\n\nI think changing (2) to \"having git make a reasonable guess\" is a better\nbehavior. And I think it is a reasonable guess to use the _same_ type,\njust as we do with \"git push \".\n\n-Peff\n"},{"id":"74561","messageId":"alpine.LNX.1.00.0804161126280.19665@iabervon.org","threadId":"13037","inReplyTo":"20080416034823.GA11727@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-04-16T15:42:42Z","receivedAt":"2008-04-16T15:42:42Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 15 Apr 2008, Jeff King wrote:\n\n> On Sun, Apr 13, 2008 at 12:31:02PM +0300, Teemu Likonen wrote:\n> \n> > There is still one thing (at least) that I don't quite understand. It's\n> > about \"git push\". When I do\n> > \n> > $ git push \n> > \n> > the refs/heads/ is updated or created on the remote side. But if\n> > I do\n> > \n> > $ git push :\n> > \n> > the refs/heads/ is not automatically created. Why there is need\n> > to say \":refs/heads/\" to make it work if \n> > does not exist? The 'git push' manual says something vague about branch\n> > not matching (?). What does it mean?\n> \n> This happens because \"git push \" is expanded locally to\n> \"git push :\", but is first expanded\n> into refs/heads/.\n> \n> The latter uses the explicit refspec which doesn't get\n> expanded, since it doesn't exist at all, and so we can't deduce the type\n> (e.g., refs/heads versus refs/tags).\n> \n> ISTR some discussion in the past few months about using the type of\n> to guess the type of , but it seems not to have gone\n> anywhere.\n> \n> Daniel, were you working on this?\n\nI was only working on making \"HEAD\" expand to HEAD:. I \nthink that the matching type is only most likely what you want, not \ncertainly enough to just do it. I'd say that push should suggest it, but \nnot actually do it automatically, or possibly require -f to do it without \nthe full name.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"74584","messageId":"7vod89pnxx.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"alpine.LNX.1.00.0804161126280.19665@iabervon.org","subject":"Re: Friendly refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-16T20:03:22Z","receivedAt":"2008-04-16T20:03:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> I was only working on making \"HEAD\" expand to HEAD:. I \n> think that the matching type is only most likely what you want, not \n> certainly enough to just do it. I'd say that push should suggest it, but \n> not actually do it automatically, or possibly require -f to do it without \n> the full name.\n\nHmm. `-f` means \"I know there are the ones that do not fast forward but I\nwant them updated\", which is quite a different thing. I'd say either we\nshould just do it, or we don't, and keep `-f` orthogonal to the ref\ndwimming.\n"},{"id":"74944","messageId":"20080422105658.GA11238@sigill.intra.peff.net","threadId":"13037","inReplyTo":"7vod89pnxx.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T10:56:58Z","receivedAt":"2008-04-22T10:56:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 16, 2008 at 01:03:22PM -0700, Junio C Hamano wrote:\n\n> > I was only working on making \"HEAD\" expand to HEAD:. I \n> > think that the matching type is only most likely what you want, not \n> > certainly enough to just do it. I'd say that push should suggest it, but \n> > not actually do it automatically, or possibly require -f to do it without \n> > the full name.\n> \n> Hmm. `-f` means \"I know there are the ones that do not fast forward but I\n> want them updated\", which is quite a different thing. I'd say either we\n> should just do it, or we don't, and keep `-f` orthogonal to the ref\n> dwimming.\n\nHmm. I was kind of hoping other people would chime in with opinions on\nthe dwimmery, but clearly they didn't.\n\nI agree that \"-f\" is a terrible idea here. Not only is it overloading\nwhat \"-f\" does, but it's totally unnecessary. If we want to send a\nmessage to the user to retry with different parameters, we can already\nsay: \"try again with refs/heads/$foo\".\n\nThe \"refs/heads/\" dwimmery makes sense to me, because:\n\n 1. it changes a behavior which is currently an error condition, so\n we're not hurting anyone's existing workflow\n\n 2. In my usage, pushing a branch to a tag (or vice versa) is the\n exception, so I don't mind favoring pushing like types to like\n types.\n\nBut I recognize that (2) is based on my own workflow, so if people\ndisagree, I guess it isn't so for everyone.\n\nWe should probably at least improve the message. Something like this is\nperhaps a bit better, or it could even customize the suggestion based\non the source ref's type (i.e., implement the dwimmery, but don't\nsurprise anyone by doing it automatically).\n\n-Peff\n\n---\ndiff --git a/remote.c b/remote.c\nindex 06ad156..2151829 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -867,9 +867,12 @@ static int match_explicit(struct ref *src, struct ref *dst,\n \t\tif (!memcmp(dst_value, \"refs/\", 5))\n \t\t\tmatched_dst = make_linked_ref(dst_value, dst_tail);\n \t\telse\n-\t\t\terror(\"dst refspec %s does not match any \"\n-\t\t\t \"existing ref on the remote and does \"\n-\t\t\t \"not start with refs/.\", dst_value);\n+\t\t\terror(\"The destination refspec does not match any \"\n+\t\t\t \"existing ref on the remote,\\n\"\n+\t\t\t \"and it does not specify a full refname; \"\n+\t\t\t \"did you mean one of:\\n\"\n+\t\t\t \" refs/heads/%s\\n\"\n+\t\t\t \" refs/tags/%s\\n\", dst_value, dst_value);\n \t\tbreak;\n \tdefault:\n \t\tmatched_dst = NULL;\n"},{"id":"74981","messageId":"7v63u9zva9.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080422105658.GA11238@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-22T16:52:46Z","receivedAt":"2008-04-22T16:52:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The \"refs/heads/\" dwimmery makes sense to me, because:\n>\n> 1. it changes a behavior which is currently an error condition, so\n> we're not hurting anyone's existing workflow\n>\n> 2. In my usage, pushing a branch to a tag (or vice versa) is the\n> exception, so I don't mind favoring pushing like types to like\n> types.\n>\n> But I recognize that (2) is based on my own workflow, so if people\n> disagree, I guess it isn't so for everyone.\n\nSo the proposal is:\n\n\t\"git push $there $commit:$name\", when $name does not begin with\n\trefs/, is interpreted as \"git push $there $commit:refs/heads/$name\"\n\nright? I think that makes sense, at least to me.\n"},{"id":"74990","messageId":"alpine.LNX.1.00.0804221259180.19665@iabervon.org","threadId":"13037","inReplyTo":"7v63u9zva9.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-04-22T17:19:35Z","receivedAt":"2008-04-22T17:19:35Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 22 Apr 2008, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > The \"refs/heads/\" dwimmery makes sense to me, because:\n> >\n> > 1. it changes a behavior which is currently an error condition, so\n> > we're not hurting anyone's existing workflow\n> >\n> > 2. In my usage, pushing a branch to a tag (or vice versa) is the\n> > exception, so I don't mind favoring pushing like types to like\n> > types.\n> >\n> > But I recognize that (2) is based on my own workflow, so if people\n> > disagree, I guess it isn't so for everyone.\n> \n> So the proposal is:\n> \n> \t\"git push $there $commit:$name\", when $name does not begin with\n> \trefs/, is interpreted as \"git push $there $commit:refs/heads/$name\"\n> \n> right? I think that makes sense, at least to me.\n\nThat's no good for people who make lightweight tags, since those will be \ncommits, and \"git push tag:tag\" would push refs/tags/tag to \nrefs/heads/tag.\n\nBut I think the proposal was for \"git push $there $name:$name\", where name \ngets expanded locally to refs/heads/$name, which I think should probably \nwork. I think it should require $name to be unambiguous locally, though, \nbecause it wouldn't be too unusual for people to end up with the same name \nfor a branch and a lightweight tag, and then try pushing that name, \nexpecting one or the other to get pushed.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"75007","messageId":"20080422200550.GB29313@sigill.intra.peff.net","threadId":"13037","inReplyTo":"7v63u9zva9.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T20:05:50Z","receivedAt":"2008-04-22T20:05:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 09:52:46AM -0700, Junio C Hamano wrote:\n\n> > 2. In my usage, pushing a branch to a tag (or vice versa) is the\n> > exception, so I don't mind favoring pushing like types to like\n> > types.\n> >\n> > But I recognize that (2) is based on my own workflow, so if people\n> > disagree, I guess it isn't so for everyone.\n> \n> So the proposal is:\n> \n> \t\"git push $there $commit:$name\", when $name does not begin with\n> \trefs/, is interpreted as \"git push $there $commit:refs/heads/$name\"\n> \n> right? I think that makes sense, at least to me.\n\nNo, the proposal is:\n\n \"git push $there $commit:$name\", when $name does not begin with\n refs/, is interpreted as \"git push $there\n $commit:$prefix/$name\", where $prefix is determined by resolving\n $commit and pulling off its first two directories.\n\n(or maybe this should just be picky and DWIM only for refs/heads and\nrefs/tags). So \"git push v1.0\" is the same as \"git push v1.0:v1.0\",\nwhich is the same as \"git push refs/tags/v1.0:refs/tags/v1.0\".\n\n-Peff\n"},{"id":"75008","messageId":"20080422201222.GC29313@sigill.intra.peff.net","threadId":"13037","inReplyTo":"alpine.LNX.1.00.0804221259180.19665@iabervon.org","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T20:12:22Z","receivedAt":"2008-04-22T20:12:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 01:19:35PM -0400, Daniel Barkalow wrote:\n\n> That's no good for people who make lightweight tags, since those will be \n> commits, and \"git push tag:tag\" would push refs/tags/tag to \n> refs/heads/tag.\n\nYes.\n\n> But I think the proposal was for \"git push $there $name:$name\", where name \n> gets expanded locally to refs/heads/$name, which I think should probably \n> work. I think it should require $name to be unambiguous locally, though, \n> because it wouldn't be too unusual for people to end up with the same name \n> for a branch and a lightweight tag, and then try pushing that name, \n> expecting one or the other to get pushed.\n\nAmbiguity is already handled when we resolve the left-hand side of the\nrefspec:\n\n $ git branch foo\n $ git tag foo\n $ git push origin foo\n error: src refspec foo matches more than one.\n fatal: The remote end hung up unexpectedly\n error: failed to push some refs to '/home/peff/foo/parent/.git'\n\nI guess you could say something like:\n\n $ git branch dest\n $ git tag dest\n $ git push origin master:dest\n\nand the \"dest\" here will become a branch. But that is because it has\nnothing to do with your local refs called \"dest\": the right-hand side is\npurely a remote matter. If the remote has an ambiguous \"dest\", then we\nalready handle that case:\n\n $ cd ../parent && git branch dest && git tag dest\n $ cd ../child && git push origin master:dest\n error: dst refspec dest matches more than one.\n fatal: The remote end hung up unexpectedly\n error: failed to push some refs to '/home/peff/foo/parent/.git'\n\n-Peff\n"},{"id":"75010","messageId":"7vd4ohy5ym.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080422200550.GB29313@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-22T20:45:05Z","receivedAt":"2008-04-22T20:45:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> No, the proposal is:\n>\n> \"git push $there $commit:$name\", when $name does not begin with\n> refs/, is interpreted as \"git push $there\n> $commit:$prefix/$name\", where $prefix is determined by resolving\n> $commit and pulling off its first two directories.\n>\n> (or maybe this should just be picky and DWIM only for refs/heads and\n> refs/tags). So \"git push v1.0\" is the same as \"git push v1.0:v1.0\",\n> which is the same as \"git push refs/tags/v1.0:refs/tags/v1.0\".\n\nWhere is $there in your example?\n\nFunny but I recall recently running \"git push ko v1.5.5.1\" and it all\nworked as expected...\n\nI thought the original poster's example was\n\n\tgit push $there $commit:branch2\n\nwhere $commit happened to be \"branch1\". Would we dwim\n\n\tgit push $there branch1~4:this_is_known_ok\n\nto refs/heads/?\n"},{"id":"75013","messageId":"20080422215239.GB30770@sigill.intra.peff.net","threadId":"13037","inReplyTo":"7vd4ohy5ym.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-22T21:52:39Z","receivedAt":"2008-04-22T21:52:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 01:45:05PM -0700, Junio C Hamano wrote:\n\n> > \"git push $there $commit:$name\", when $name does not begin with\n> > refs/, is interpreted as \"git push $there\n> > $commit:$prefix/$name\", where $prefix is determined by resolving\n> > $commit and pulling off its first two directories.\n> >\n> > (or maybe this should just be picky and DWIM only for refs/heads and\n> > refs/tags). So \"git push v1.0\" is the same as \"git push v1.0:v1.0\",\n> > which is the same as \"git push refs/tags/v1.0:refs/tags/v1.0\".\n> \n> Where is $there in your example?\n\nHeh, sorry. s/git push/& $there/g.\n\n> Funny but I recall recently running \"git push ko v1.5.5.1\" and it all\n> worked as expected...\n\nI'm not sure what you mean here. Yes, we already special case \"git push\n$there $ref\" into \"git push $there $ref:$ref\", except we use the\nfully-qualified ref name for the right-hand side. I mention it because I\nthink of this as simply extending that dwimmery to $commit:branch2. That\nis, there is a complete and unambiguous refspec like\n\"refs/heads/branch1:refs/heads/branch2\", and the others are logical DWIM\nshorthands that expand into such a refspec.\n\n> I thought the original poster's example was\n> \n> \tgit push $there $commit:branch2\n> \n> where $commit happened to be \"branch1\". Would we dwim\n> \n> \tgit push $there branch1~4:this_is_known_ok\n> \n> to refs/heads/?\n\nI'm not sure what you mean by \"this_is_known_ok\". Do you mean the remote\nalready has such a ref? I think the dwim is:\n\n 1. if the destination ref is fully qualified, use that\n 2. if the destination ref is not fully qualified, but resolves\n unambiguously to a ref on the remote, use that\n 3. otherwise, do the dwim we are talking about, which is to qualify it\n using the same type as the source ref\n\nSo if you meant \"the remote has such a ref\", then no, I think we stick\nwith the current behavior (2).\n\nBut I think what you were getting at is: \"what is the source type of\nbranch~4\"? I am inclined to say \"the same as the source type of branch\",\nbut I can see how one might think that is getting a little crazy.\nRelated is the question of \"what is the source type of \". In that\ncase, we should almost certainly give an error as we do now. Putting\n\"branch~4\" into that category (or HEAD if it is detached) makes some\nsense to me.\n\n-Peff\n"},{"id":"75030","messageId":"20080423042433.GA3291@mithlond.arda.local","threadId":"13037","inReplyTo":"7vd4ohy5ym.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-23T04:24:33Z","receivedAt":"2008-04-23T04:24:33Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Junio C Hamano wrote (2008-04-22 13:45 -0700):\n\n> I thought the original poster's example was\n> \n> \tgit push $there $commit:branch2\n> \n> where $commit happened to be \"branch1\". Would we dwim\n> \n> \tgit push $there branch1~4:this_is_known_ok\n> \n> to refs/heads/?\n\nI guess this is what I meant. My original question was about\ninconsistent user interface: \"git push $there branch1\" creates branch1\non the remote side (if it does not exist) but \"git push $there\nbranch1:branch2\" gives an error if branch2 does not exist\n(branch1:refs/heads/branch2 is required).\n\nThe case has become much more complicated since, so I just speak aloud\nmy hope that need for refs/ paths in common situations would be reduced\nto minimum.\n"},{"id":"75033","messageId":"7v1w4xuni1.fsf@gitster.siamese.dyndns.org","threadId":"13037","inReplyTo":"20080423042433.GA3291@mithlond.arda.local","subject":"Re: Friendly refspecs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-23T05:52:06Z","receivedAt":"2008-04-23T05:52:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Teemu Likonen writes:\n\n> Junio C Hamano wrote (2008-04-22 13:45 -0700):\n>\n>> I thought the original poster's example was\n>> \n>> \tgit push $there $commit:branch2\n>> \n>> where $commit happened to be \"branch1\". Would we dwim\n>> \n>> \tgit push $there branch1~4:this_is_known_ok\n>> \n>> to refs/heads/?\n>\n> I guess this is what I meant. My original question was about\n> inconsistent user interface: \"git push $there branch1\" creates branch1\n> on the remote side (if it does not exist) but \"git push $there\n> branch1:branch2\" gives an error if branch2 does not exist\n> (branch1:refs/heads/branch2 is required).\n>\n> The case has become much more complicated since, so I just speak aloud\n> my hope that need for refs/ paths in common situations would be reduced\n> to minimum.\n\nI think everybody involved in this discussion understands _that_. The\nissue is that you would not have said \"branch2\" in real life, but used\nsome word that is _not_ \"branch\" to name the thing, and there is no way\nfor git to guess correctly if you meant to create a branch or a\nlight-weight tag.\n\nThere is no inconsistency. \"push $branch1\" has a special case logic to\nfavor \"the same name\". You invoked \"src:dst\" syntax that is general\npurpose which does not dwim.\n\nHistorically we did not favor one way or another for the general purpose\nsyntax. I think Jeff's proposed heuristics to favor branch if a branch\ntip is pushed and tag if a tag is pushed makes sense.\n"},{"id":"75036","messageId":"480ED60D.7050708@op5.se","threadId":"13037","inReplyTo":"7v1w4xuni1.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-04-23T06:24:13Z","receivedAt":"2008-04-23T06:24:13Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Teemu Likonen writes:\n> \n>> Junio C Hamano wrote (2008-04-22 13:45 -0700):\n>>\n>>> I thought the original poster's example was\n>>>\n>>> \tgit push $there $commit:branch2\n>>>\n>>> where $commit happened to be \"branch1\". Would we dwim\n>>>\n>>> \tgit push $there branch1~4:this_is_known_ok\n>>>\n>>> to refs/heads/?\n>> I guess this is what I meant. My original question was about\n>> inconsistent user interface: \"git push $there branch1\" creates branch1\n>> on the remote side (if it does not exist) but \"git push $there\n>> branch1:branch2\" gives an error if branch2 does not exist\n>> (branch1:refs/heads/branch2 is required).\n>>\n>> The case has become much more complicated since, so I just speak aloud\n>> my hope that need for refs/ paths in common situations would be reduced\n>> to minimum.\n> \n> I think everybody involved in this discussion understands _that_. The\n> issue is that you would not have said \"branch2\" in real life, but used\n> some word that is _not_ \"branch\" to name the thing, and there is no way\n> for git to guess correctly if you meant to create a branch or a\n> light-weight tag.\n> \n\nIf the src ref is not a commit sha1, the user will almost certainly want\nto create the same *type* of ref on the remote side, so\n\ngit tag foo\ngit branch boo\ngit push $there foo:wip\ngit push $there boo:wip-2008-04-24\n\nwould, on the remote side, create the branch \"wip\" and the tag \"wip-2008-04-24\"\n\nI for one would certainly like that, and I don't think very many will be\nsurprised at that behaviour.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"75047","messageId":"20080423091606.GC11935@sigill.intra.peff.net","threadId":"13037","inReplyTo":"7v1w4xuni1.fsf@gitster.siamese.dyndns.org","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-23T09:16:06Z","receivedAt":"2008-04-23T09:16:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 22, 2008 at 10:52:06PM -0700, Junio C Hamano wrote:\n\n> Historically we did not favor one way or another for the general purpose\n> syntax. I think Jeff's proposed heuristics to favor branch if a branch\n> tip is pushed and tag if a tag is pushed makes sense.\n\nOK, here is a cleaned up patch with tests.\n\n-- >8 --\npush: allow unqualified dest refspecs to DWIM\n\nPreviously, a push like:\n\n git push remote src:dst\n\nwould go through the following steps:\n\n 1. check for an unambiguous 'dst' on the remote; if it\n exists, then push to that ref\n 2. otherwise, check if 'dst' begins with 'refs/'; if it\n does, create a new ref\n 3. otherwise, complain because we don't know where in the\n refs hierarchy to put 'dst'\n\nHowever, in some cases, we can guess about the ref type of\n'dst' based on the ref type of 'src'. Specifically, before\ncomplaining we now check:\n\n 2.5. if 'src' resolves to a ref starting with refs/heads\n or refs/tags, then prepend that to 'dst'\n\nSo now this creates a new branch on the remote, whereas it\npreviously failed with an error message:\n\n git push master:newbranch\n\nNote that, by design, we limit this DWIM behavior only to\nsource refs which resolve exactly (including symrefs which\nresolve to existing refs). We still complain on a partial\ndestination refspec if the source is a raw sha1, or a ref\nexpression such as 'master~10'.\n\nSigned-off-by: Jeff King \n---\n remote.c | 32 +++++++++++++++++++++++++++++---\n t/t5516-fetch-push.sh | 40 ++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 69 insertions(+), 3 deletions(-)\n\ndiff --git a/remote.c b/remote.c\nindex 06ad156..2d9af40 100644\n--- a/remote.c\n+++ b/remote.c\n@@ -812,6 +812,26 @@ static struct ref *make_linked_ref(const char *name, struct ref ***tail)\n \treturn ret;\n }\n \n+static char *guess_ref(const char *name, struct ref *peer)\n+{\n+\tstruct strbuf buf = STRBUF_INIT;\n+\tunsigned char sha1[20];\n+\n+\tconst char *r = resolve_ref(peer->name, sha1, 1, NULL);\n+\tif (!r)\n+\t\treturn NULL;\n+\n+\tif (!prefixcmp(r, \"refs/heads/\"))\n+\t\tstrbuf_addstr(&buf, \"refs/heads/\");\n+\telse if (!prefixcmp(r, \"refs/tags/\"))\n+\t\tstrbuf_addstr(&buf, \"refs/tags/\");\n+\telse\n+\t\treturn NULL;\n+\n+\tstrbuf_addstr(&buf, name);\n+\treturn strbuf_detach(&buf, NULL);\n+}\n+\n static int match_explicit(struct ref *src, struct ref *dst,\n \t\t\t struct ref ***dst_tail,\n \t\t\t struct refspec *rs,\n@@ -820,6 +840,7 @@ static int match_explicit(struct ref *src, struct ref *dst,\n \tstruct ref *matched_src, *matched_dst;\n \n \tconst char *dst_value = rs->dst;\n+\tchar *dst_guess;\n \n \tif (rs->pattern)\n \t\treturn errs;\n@@ -866,10 +887,15 @@ static int match_explicit(struct ref *src, struct ref *dst,\n \tcase 0:\n \t\tif (!memcmp(dst_value, \"refs/\", 5))\n \t\t\tmatched_dst = make_linked_ref(dst_value, dst_tail);\n+\t\telse if((dst_guess = guess_ref(dst_value, matched_src)))\n+\t\t\tmatched_dst = make_linked_ref(dst_guess, dst_tail);\n \t\telse\n-\t\t\terror(\"dst refspec %s does not match any \"\n-\t\t\t \"existing ref on the remote and does \"\n-\t\t\t \"not start with refs/.\", dst_value);\n+\t\t\terror(\"unable to push to unqualified destination: %s\\n\"\n+\t\t\t \"The destination refspec neither matches an \"\n+\t\t\t \"existing ref on the remote nor\\n\"\n+\t\t\t \"begins with refs/, and we are unable to \"\n+\t\t\t \"guess a prefix based on the source ref.\",\n+\t\t\t dst_value);\n \t\tbreak;\n \tdefault:\n \t\tmatched_dst = NULL;\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex f93a100..0a757d5 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -273,6 +273,37 @@ test_expect_success 'push with colon-less refspec (4)' '\n \n '\n \n+test_expect_success 'push head with non-existant, incomplete dest' '\n+\n+\tmk_test &&\n+\tgit push testrepo master:branch &&\n+\tcheck_push_result $the_commit heads/branch\n+\n+'\n+\n+test_expect_success 'push tag with non-existant, incomplete dest' '\n+\n+\tmk_test &&\n+\tgit tag -f v1.0 &&\n+\tgit push testrepo v1.0:tag &&\n+\tcheck_push_result $the_commit tags/tag\n+\n+'\n+\n+test_expect_success 'push sha1 with non-existant, incomplete dest' '\n+\n+\tmk_test &&\n+\ttest_must_fail git push testrepo `git rev-parse master`:foo\n+\n+'\n+\n+test_expect_success 'push ref expression with non-existant, incomplete dest' '\n+\n+\tmk_test &&\n+\ttest_must_fail git push testrepo master^:branch\n+\n+'\n+\n test_expect_success 'push with HEAD' '\n \n \tmk_test heads/master &&\n@@ -311,6 +342,15 @@ test_expect_success 'push with +HEAD' '\n \n '\n \n+test_expect_success 'push HEAD with non-existant, incomplete dest' '\n+\n+\tmk_test &&\n+\tgit checkout master &&\n+\tgit push testrepo HEAD:branch &&\n+\tcheck_push_result $the_commit heads/branch\n+\n+'\n+\n test_expect_success 'push with config remote.*.push = HEAD' '\n \n \tmk_test heads/local &&\n-- \n1.5.5.1.69.g9c889.dirty\n"},{"id":"75049","messageId":"20080423092144.GA11368@sigill.intra.peff.net","threadId":"13037","inReplyTo":"20080423091606.GC11935@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-23T09:21:45Z","receivedAt":"2008-04-23T09:21:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 23, 2008 at 05:16:06AM -0400, Jeff King wrote:\n\n> > Historically we did not favor one way or another for the general purpose\n> > syntax. I think Jeff's proposed heuristics to favor branch if a branch\n> > tip is pushed and tag if a tag is pushed makes sense.\n> \n> OK, here is a cleaned up patch with tests.\n\nOops, I forgot to mention: there is a broken test in t5516 that is\nrevealed by this change. The patch below should be applied before the\nDWIM one.\n\n-- >8 --\nt5516: remove ambiguity test (1)\n\nThis test tried to push into a remote with ambiguous refs in\nremotes/$x/master and remotes/$y/master. However, the remote\nnever actually tells us about the refs/remotes hierarchy, so\nwe don't even see this ambiguity.\n\nThe test happened to pass because we were simply looking for\nfailure, and the test fails for another reason: the dst\nrefspec does not exist and does not begin with refs/, making\nit invalid.\n\nSigned-off-by: Jeff King \n---\n t/t5516-fetch-push.sh | 14 +-------------\n 1 files changed, 1 insertions(+), 13 deletions(-)\n\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 6d7e738..f93a100 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -209,19 +209,7 @@ test_expect_success 'push with weak ambiguity (2)' '\n \n '\n \n-test_expect_success 'push with ambiguity (1)' '\n-\n-\tmk_test remotes/origin/master remotes/frotz/master &&\n-\tif git push testrepo master:master\n-\tthen\n-\t\techo \"Oops, should have failed\"\n-\t\tfalse\n-\telse\n-\t\tcheck_push_result $the_first_commit remotes/origin/master remotes/frotz/master\n-\tfi\n-'\n-\n-test_expect_success 'push with ambiguity (2)' '\n+test_expect_success 'push with ambiguity' '\n \n \tmk_test heads/frotz tags/frotz &&\n \tif git push testrepo master:frotz\n-- \n1.5.5.1.69.g9c889.dirty\n"},{"id":"75056","messageId":"20080423111556.GB3291@mithlond.arda.local","threadId":"13037","inReplyTo":"20080423092144.GA11368@sigill.intra.peff.net","subject":"Re: Friendly refspecs","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-04-23T11:15:56Z","receivedAt":"2008-04-23T11:15:56Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Jeff King wrote (2008-04-23 05:21 -0400):\n\n> On Wed, Apr 23, 2008 at 05:16:06AM -0400, Jeff King wrote:\n> \n> > > Historically we did not favor one way or another for the general\n> > > purpose syntax. I think Jeff's proposed heuristics to favor\n> > > branch if a branch tip is pushed and tag if a tag is pushed makes\n> > > sense.\n> > \n> > OK, here is a cleaned up patch with tests.\n> \n> Oops, I forgot to mention: there is a broken test in t5516 that is\n> revealed by this change. The patch below should be applied before the\n> DWIM one.\n\nI did some testing and your patches seem to work. I think push refspecs\nare frendlier now. :) It's great to see you guys taking users seriously\nand working on possible problems. Thanks!\n"}]}