On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote: > Some people thought that throwing everything that does something to remote > under "git remote" was a good idea, and "git remote update" was invented. > It is a thin wrapper around "fetch" and does what "fetch" does. You need > to understand "fetch" (i.e. downloads the history and necessary objects, > and updates the remote tracking branches, without ever touching the work > tree) to understand "git remote update" anyway, and more importantly, you > need to understand what they do not do. > > It is not even a typesaver. "git fetch" updates from the default remote, > so does "git remote update". Personally I think the people who invented > "git remote update" were misguided, and that is why I say it was a failed > UI experiment that failed, but that is hindsight talking [*1*]. Declaring it a failure depends on what you consider the goal of "git remote update" to be. I find it very useful as a shorthand for "fetch from _all_ remotes"[1]. Which does save typing over $ for i in `git remote`; do git fetch $i; done And of course, there is "git remote" again, saving us a few keystrokes over: $ git config --get-regexp 'remote..*.url' | cut -d. -f2 [1]: And I think this is a useful operation. When collaborating with developers in multiple repositories, it is nice to see an overview of what all other people are working on. We have other tools to actually compare the refs, but the first step is obviously getting those refs up to date locally. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html