{"thread":{"id":"43251","subject":"git-{fetch,pull} default behaviours (was Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone)","startedAt":"2006-12-08T09:03:47Z","lastAt":"2006-12-08T09:03:47Z","messageCount":1,"participants":["Francis Moreau"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"294138","messageId":"38b2ab8a0612080103h14387513ta53e71fe715441f4@mail.gmail.com","threadId":"43251","inReplyTo":null,"subject":"git-{fetch,pull} default behaviours (was Re: [PATCH] Explicitly add the default \"git pull\" behaviour to .git/config on clone)","fromName":"Francis Moreau","fromEmail":"francis.moro@gmail.com","sentAt":"2006-12-08T09:03:47Z","receivedAt":"2006-12-08T09:03:47Z","isPatch":true,"sender":{"key":"francis.moro@gmail.com","avatar":null},"body":"Andy Parkins wrote:\n> Without any specification in the .git/config file, git-pull will execute\n> \"git-pull origin\"; which in turn defaults to pull from the first \"pull\"\n> definition for the remote, \"origin\".\n>\n> This is a difficult set of defaults to track for a new user, and it's\n> difficult to see what tells git to do this (especially when it is\n> actually hard-coded behaviour).  To ameliorate this slightly, this patch\n> explicitly specifies the default behaviour during a clone using the\n> \"branch\" section of the config.\n>\n> For example, a clone of a typical repository would create a .git/config\n> containing:\n>   [remote \"origin\"]\n>   url = proto://host/repo.git\n>   fetch = refs/heads/master:refs/remotes/origin/master\n>   [branch \"master\"]\n>   remote = origin\n>   merge = refs/heads/master\n>\n> The [branch \"master\"] section is such that there is no change to the\n> functionality of git-pull, but that functionality is now explicitly\n> documented.\n>\n> Signed-off-by: Andy Parkins <andyparkins@gmail.com>\n> ---\n> This is really to help newbies.  By explicitly documenting the default\n> behaviour, it makes it clearer what is going on.  It also means no routing\n> through documentation to find out what config option needs changing.\n>\n\nWell I would say that if you want newbies (like me) to understand\ngit-pull and git-fetch default behaviour, we should first fix their\ndocumentations. I dunno if it's me but I really find it terrible to\nread. A lot information are spread all across the doc and I haven't\nfound a logical organisation in it.\n\nJust reading the synopsis of these two command at first glance does\nnot give a good view of the commands:\n\n\tgit-fetch <options> <repository> <refspec> ...\n\nFor example, it doesn't say that all arguments are optional at first\nlook, does it ? How does it say that I can run 'git-fetch origin' ?\n\nWhen reading git-fetch doc, you find some specific git-pull\ndocumentation which is confusing. The same is true when reading\ngit-pull doc. Why not removing all remote stuffs from git-pull doc and\njust give a link to git-fetch for example ? Why not stopping using\ngit-pull word in git-fetch doc ?\n\nI'm not sure that putting the default behaviour documentation in git's\nconfig file will help the very newbie that I am. I expect to understand\nhow a command works in its documentation not by reading some git's\ninternal config file. And my first feeling when reading them is \"whoa\nthis command seems really complex to use...\"\n\nHowever maybe explaining the default behaviour by giving some examples\nwould make things much more easier to understand. For example\n\nExamples\n--------\n\tRunning 'git-fetch' (without any arguments):\n\tThis is equivalent to run \"git-fetch origin\"....\n\n\tRunning 'git-fetch <repository>':\n\t...\n\n\tRunning 'git-fetch <repository> <refspec>':\n\t....\n\n\tRunning 'git-fetch <refspec>' (if possible):\n\t...\n\n-- \n"}]}