Jeff King <peff <at> peff.net> writes: > 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 I wasn't trying to argue that a pull would be a good idea, but more that it's not that expensive because of the content-addressable nature of git's object store. And saying that is "might be costly" could be misleading to people who haven't groked how a commit is a commit is a commit. - Eric -- 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