[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obscure error/warning/information message from git pull

From: David Kastrup
Subject: Re: Obscure error/warning/information message from git pull
Date: Sat, 15 Nov 2014 19:17:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> Take a look in your .git/config file.  You'll find a section
>> [remote "origin"] containing, among other things, a fetch specification.
> That says "fetch = +refs/heads/*:refs/remotes/origin/*", which I guess
> means everything, and is probably the default (since I never said
> anything about that).

Apparently.  Good thing they got rid of the old default.  It was a

> So I guess I can now forget everything about partial DAG being
> fetched, because in my case, as in every default case, the entire DAG
> will be updated by "git pull".  Is that correct?

Yes.  I actually don't ever use "git pull" myself as I don't like the
automatic merging action: if I want a merge, I do it myself.  "git
fetch" is sufficient for the update and does not involve the current
branch or checkout or work directory at all, and git pull does it as its
first step anyway.  I often want to see what happened upstream _without_
having it automatically integrated into what I am currently working on.

>> For a typical repository containing all branches (whether that is the
>> case depends on the fetch specification), the complete DAG is
>> available.  git pull updates _all_ fetched remote-tracking branches.
>> But it only merges the currently checked-out _local_ branch with the
>> remote-tracking branch for the corresponding remote branch.
> So the suggestion to pull, displayed by Git when I checkout another
> branch immediately after a pull, actually boils down to do the merge
> for that other branch?  If so, why does it suggest a pull?

Because it has no notion of "immediately after a pull" would be one
reason.  Another reason might be that the branch might be set to rebase
on pull rather than merge, and the default suggestion does not want to
differentiate the two cases.

Also it might be that when you specify arguments, indeed only _some_
references are fetched rather than all.  The man page says:

       git pull [options] [<repository> [<refspec>...]]

       Incorporates changes from a remote repository into the current branch.
       In its default mode, git pull is shorthand for git fetch followed by
       git merge FETCH_HEAD.

       More precisely, git pull runs git fetch with the given parameters and
       calls git merge to merge the retrieved branch heads into the current
       branch. With --rebase, it runs git rebase instead of git merge.

So you can pull in other branches as well.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]