On Aug 13, 7:37 pm, David Doria <daviddo...@gmail.com> wrote: > Ah, so fetch is an operation on the entire repository and merge is an > operation on a specific branch? So you're say that 'pull'ing each > branch is not necessary because the 'fetch' in 'pull's fetch+merge is > redundant. Is that correct? It's a bit more involved: git-fetch can be used to fetch specific objects from a remote repository, but in the most common case it's used without any refspecs on the command line, and in this case Git's behaviour is governed by a special configuration parameter. This parameter is named "fetch", and it is autocreated for each remote when you do $ git remote add ... or $ git clone That parameter is set for you to something like "+refs/heads/*:refs/ remotes/origin/*" ("origin" is the name of the remote here) which means "fetch all remote branches and forcibly update the same-named local branches pertaining to that remote". This default setup makes "git fetch <remotename>" bring everything applicable from the specified remote. Of course, you're free to tweak this option to suit your needs but in the general case it just does the right thing.
> I also don't understand why this is a deficient approach? If each > branch is for a bug fix, then wouldn't it make sense to want to be > able to work with a branch that has ALL of the bugs fixed? I meant something different. Or course, it's perfectly sensible to merge back to a "common" branch any bugfixes pertaining to it, but I can't get such "accumulate and apply all at once" approach. It seems like a quite contrived approach, whch is invented just because it could be invented, and not from a real need. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.