{"thread":{"id":"22115","subject":"[PATCH] Documentation: do not advertise --all in git-pull(1)","startedAt":"2010-01-07T16:09:33Z","lastAt":"2010-01-07T18:25:15Z","messageCount":2,"participants":["Thomas Rast","Zing"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"131005","messageId":"a6112d286c5deeb4cc2ccfb1a90ff384440c1341.1262880109.git.trast@student.ethz.ch","threadId":"22115","inReplyTo":"hi2mu8ob@ger.gmane.org","subject":"[PATCH] Documentation: do not advertise --all in git-pull(1)","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-01-07T16:09:33Z","receivedAt":"2010-01-07T16:09:33Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Since 9c4a036 (Teach the --all option to 'git fetch', 2009-11-09), we\ndocument git-fetch's option --all in fetch-options.txt. However, that\nfile is also included by git-pull.txt, where the option makes no\nsense.\n\nWrap the option with ifdef so that it does not appear on the git-pull\nmanpage.\n\nSigned-off-by: Thomas Rast \n---\n\nZing wrote:\n> In 1.6.6, if I do:\n> \n> $ git pull --all\n> Fetching origin\n> Fetching gnome\n> You asked to pull from the remote '--all', but did not specify\n> a branch. Because this is not the default configured remote\n> for your current branch, you must specify a branch on the command line.\n\nThis one fixes the documentation problem, but I think there's a deeper\nmisunderstanding. What did you hope to do with 'git pull --all'? I\nsuspect most people on this list would take it to mean \"fetch all\nbranches from all remotes, and merge them into HEAD\". I cannot\nimagine a use-case where that would make any sense. (And it wouldn't\nwork, because the current implementation of 'git fetch --all' leaves\nonly the last remote's branches in FETCH_HEAD.)\n\n>From earlier discussions on the non-intuitiveness of git-pull, I kind\nof suspect you wanted to fetch all remotes, and then \"update\" all\nlocal branches that track some remote with their corresponding\nremote-tracking branches. In which case the question is: why do you\nuse local branches if you have them \"blindly\" track the upstream?\n\n\n Documentation/fetch-options.txt | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex ab6419f..6271615 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -1,5 +1,7 @@\n+ifndef::git-pull[]\n --all::\n \tFetch all remotes.\n+endif::git-pull[]\n \n -a::\n --append::\n-- \n1.6.6.202.gdf32a\n"},{"id":"131031","messageId":"hi58ub$c0l$1@ger.gmane.org","threadId":"22115","inReplyTo":"a6112d286c5deeb4cc2ccfb1a90ff384440c1341.1262880109.git.trast@student.ethz.ch","subject":"Re: [PATCH] Documentation: do not advertise --all in git-pull(1)","fromName":"Zing","fromEmail":"zing@fastmail.fm","sentAt":"2010-01-07T18:25:15Z","receivedAt":"2010-01-07T18:25:15Z","isPatch":true,"sender":{"key":"zing@fastmail.fm","avatar":null},"body":"On Thu, 07 Jan 2010 17:09:33 +0100, Thomas Rast wrote:\n\n> This one fixes the documentation problem, but I think there's a deeper\n> misunderstanding. What did you hope to do with 'git pull --all'? I\n> suspect most people on this list would take it to mean \"fetch all\n> branches from all remotes, and merge them into HEAD\". I cannot imagine\n> a use-case where that would make any sense. (And it wouldn't work,\n> because the current implementation of 'git fetch --all' leaves only the\n> last remote's branches in FETCH_HEAD.)\n> \n> From earlier discussions on the non-intuitiveness of git-pull, I kind of\n> suspect you wanted to fetch all remotes, and then \"update\" all local\n> branches that track some remote with their corresponding remote-tracking\n> branches. In which case the question is: why do you use local branches\n> if you have them \"blindly\" track the upstream?\n\nLet me just state first that I'm a casual git user and I would have \nmissed those earlier discussions.... sorry if this old news:\n\nI do basically just use git to just \"blindly\" track upstream repos/\nprojects using local branches. I realize this is \"dumb\" in a sense,\nbecause it's basically just a copy of the remote branch that needs to be\nfast-forwarded all the time; but it's just a handy lazy way for me to\nremember which remote branches I want to \"watch\" with just a 'git branch' \ncommand, plus it's easier and shorter to just type the local branch names \nI specify than to type for example \"origin/something\" or \"myotherremote/\nsomething\".\n\nWhat I thought 'git pull --all' would do is just pass down the --all flag \nto fetch and that's it:\n\n1. do a 'git fetch --all'\n2. then do a 'git merge ', basically, in my case, just fast-forwarding my current local \nbranch if need be.\n\nI didn't think that 'git pull --all' would \"update\" all local branches \nthat needed to be fast-forwarded. It would be too, how to say, \"messy\" \nin the output, and not really what 'git pull' alone was doing before. I \ndid think it could be a possibility, so, really, I was trying it out to \nsee what would happen.\n\nThe other possibility you mentioned about fetching all branches and then \nmerging all of them to HEAD, didn't occur to me at all. I can see now \nhow it could make more intuitive sense from the perspective of a more \n\"experienced\" git person. Personally, I don't think I'd ever need \nsomething like that. HTH.\n"}]}