On Fri, May 22, 2009 at 05:29:41PM +0000, Eric Raible wrote: > Jeff King <peff <at> peff.net> writes: > > > I think doing a "git merge origin/master" is perfectly normal for some > > workflows. For example: > > > > $ git fetch origin ;# grab it > > $ gitk origin/master...master ;# check if it is good to merge > > $ git merge origin/master ;# and merge it > > > > The final step _could_ be a pull, but there is no point in repeating the > > fetch (which might be costly). > > My understanding is that if the objects already exist > locally then this is not going to be costly at all. > The negotiation of what is needed is cheap, isn't it? No, it is not terribly expensive. But you do have to talk to the server, which may mean making an ssh connection, or the server may be overloaded and slow. So it can take a few seconds instead of a few microseconds. There is actually another reason not to pull, though: you just inspected what is in origin/master, so that is what you are expecting to merge. If there is new stuff on the remote, you probably don't want to merge it without similarly inspecting it. -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