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

[Eli Zaretskii <eliz@gnu.org>]

> From: David Kastrup <dak@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 15 Nov 2014 11:28:11 +0100
> 
> >> git cannot magically show anything that isn't in the repo.
> >
> > It is unclear to me, at my current level of knowledge, what exactly
> > "is in the repo".
> 
> All the references you fetched/cloned and everything they point to.

Thanks, but that explains nothing.

> > For example, "git clone" is advertised as "clone a repository", but
> > that evidently only "fully" clones the master branch; other branches
> > won't even be updated by the following "git pull"s unless you say
> > "git checkout BRANCH" once (or give some other command that has the
> > same effect).  Then what exactly is brought downstream by 'clone', and
> > why is it called "repository" rather than "branch"?
> 
> The manual is clear about that.

"Clear", right.

>        Clones a repository into a newly created directory, creates
>        remote-tracking branches for each branch in the cloned repository
>        (visible using git branch -r), and creates and checks out an initial
>        branch that is forked from the cloned repository\u2019s currently active
>        branch.
> 
>        After the clone, a plain git fetch without arguments will update all
>        the remote-tracking branches, and a git pull without arguments will in
>        addition merge the remote master branch into the current master branch,
>        if any (this is untrue when "--single-branch" is given; see below).
> 
>        This default configuration is achieved by creating references to the
>        remote branch heads under refs/remotes/origin and by initializing
>        remote.origin.url and remote.origin.fetch configuration variables.

Sorry, but that's a bunch of gobbledygook.  What does "create
remote-tracking branches" mean, and how is it different from "creates
the initial branch"?  What does "update" in "update the
remote-tracking branches" means, and how is it different from what is
described after that for the master branch?  Sorry, but this old
curmudgeon cannot grok that; I'd very much prefer your own words.

> > Furthermore, even if you have other branches tracked, "git pull"
> > evidently won't update them as it does with the current branch, since
> > switching to another branch after a pull will cheerfully tell you that
> > you are behind the branch tip and need another "git pull" to fix that.
> > Then what exactly does "branch tracking" mean, by default?
> 
> It means that Git tracks the remote branches: it knows what's there and
> can show you even when offline (of course, it shows the state since the
> last fetch).

Does that include updating their parts of the DAG?  Below you seem to
say it doesn't; but in that case, how would Git "know what's there"
and show that to me while offline?

> git-pull merges (or rebases) _one_ local branch.  The one that is
> checked out.  But it updates all remote-tracking branches.

"Updates" how?  Does it update their part of the DAG?  Does it do
something else?

> > These and other similar complexities stand in the way of my
> > understanding of what exactly do I have in my clone of the repository,
> > and what I don't have.
> 
> git branch -a should tell you.

It shows the list of the branches, where I know how to discern a
branch I call "tracking", i.e. the one for which I did a checkout at
some point, and those for which I didn't.  What else should it tell
me?

> > It is all the more perplexing, since (AFAIU) the repo met-data is (or
> > includes) the history DAG, where (AFAIK) branches are all interwoven
> > in a single graph.  So how come a 'pull' doesn't update the whole DAG,
> > and if it does, why do I need to do something in addition to have all
> > my branches updated?
> 
> A pull updates those parts of the DAG that can be reached from the
> references you have in your "fetch" specification.

What is my "fetch specification", and how did I specify that?

Thanks for taking time to explain this.