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 ...
$ 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 
For more options, visit this group at 

Reply via email to