Junio C Hamano <gitster@xxxxxxxxx> writes: > Mike Hommey <mh@xxxxxxxxxxxx> writes: > >> BTW, shouldn't fetch be deprecated in favour of git remote update ? > > Why? People will then be confused because half of them would expect > "remote update" to somehow affect their working tree, and some others > would expect their working tree reset to one of the branches from the > remote, and it won't solve anything. Oh, and it will irritate people who > are used to type "git fetch", too. I think the above comment needs to be clarified, so that I will not discourage you or other people who would want to pursue the part I omitted from my quote too much, which was: > (this may require adding some features to git remote update, but you get > the idea) Now, I _personally_ think "git remote update" was a half-baked UI experiment that failed, but as the maintainer I'll still give it benefit of doubt for a bit longer and let interested parties resurrect and perfect it, just in case it might turn out to be a good thing. In the rest, when I say "I think", pretend as if I said _personally_ (i.e. not speaking as the maintainer who already has given up on it). I think the original "git remote add" was a good interface, similar to "git config", as the management interface to the remote system used by the everyday commands "fetch/pull/push". The everyday commands use the remote nicknames and their associated data stored in the configuration file. While you can edit your configuration file directly to manage the remotes, some people (and recipe book writers) prefer to have a specialized management command. "git remote add" is such a management interface that you use once and then you can forget about it. Once you get your remote configured, the everyday commands will use the data in the configuration file, and the commands you interract with your remotes will be these everyday commands, not "git remote". 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*]. After reading Björn's excerpts, it was clear to me that the names of the commands have much less to do with the confusion [*2*] than I originally feared [*3*]. As long as the user needs the same kind of understanding of what the command does, I do not think changing the command name between "git remote update" vs "git fetch" and calling everything that has something to do with remote repositories "remote" would solve anything. The users also need to understand how to make what these commands do an integrated part in a larger workflow they use, so that they know what to do next, which is much more important issue, and at that point the name of the command is secondary---the concepts counts much more. "git remote update" even has a slight downside in the "push moves from here to there, pull moves from there to here" sense. If you never have seen git, "git remote update $there" may look like you are asking git to update the remote called $there, presumably with what you have. That is quite opposite direction from how it actually move things. [Footnote] *1* The only thing "git remote update" does that "git fetch" does not is that it can serve as "fetch from everywhere" shorthand. But that is something we could have added to "git fetch". So in that sense, I think it may make even more sense to deprecate "remote update" and teach "fetch" how to do that. *2* Granted, if our "pull" were named "push", the natural meaning of the word "push" that moves things from here to there (as opposed to there to here) may even confuse people, but both "pull" and "fetch" mean moving things from farther to closer (and nothing more in the natural meaning), and the confusion expressed in the thread were not of that kind---nobody expected us to do anything that involves moving something we have to the remote, but the confusion was about what happens _after_ something was moved from there to here. *3* In a sense I somehow was hoping that the confusion was only about the push/pull asymmetry as some people claimed. If it were, the problem would have been very easy to fix; you just do not let pull affect the work tree. But the confused users were expecting the changes to be reflected to their work trees, and the confusion was about how that is done. Some wanted their local changes blown away, some wanted their local histories also get blown away, some wanted the changes integrated. -- 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