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

[David Kastrup <dak@gnu.org>]

Michael Welsh Duggan <mwd@md5i.com> writes:

> When you clone a repo without giving it any special arguments (i.e.,
> just the location of the remote repository and possible the name of
> the directory you wish to clone into) you get a copy of the whole
> remote repository; all branches, the whole DAG, and all blobs
> referenced by the DAG.

Looks like it.  At some previous time, the default was to only clone the
default branch I think.  More often than not, that was a total nuisance.
At any rate, the behavior can be changed by editing .git/config, in
particular the [remote "origin"] section.

> Each branch in your on-disk copy of the clone is called a "remote
> branch", since it is a branch from a remote source.  (That last
> sentence is shaky, and perhaps incorrect, but bear with me.)

Not more shaky and perhaps incorrect than the normal Git documentation.
It's your local notion of the remote branches, also called
"remote-tracking branches".

> Now, you do not normally check-out these "remote branches", and by
> check-out I mean specifically generate a working directory from them.

Yes and no.  Remote-tracking branches are _not_ actually branches one
can check out.  If you check out such a "branch", you actually just
check out its current state as a "detached HEAD".  Whatever you commit
to such a detached HEAD will get _lost_ if you change branches without
creating a local branch or a tag for those commits.  The remote-tracking
branch cannot be associated with your new commits (unless you _push_
them) since it keeps mirroring the remote (in the last known form).

> Rather you work with a "local branch" which is usually "linked" to the
> "remote branch".  (The "link" is what the --track option to the branch
> command handles, I believe.)  When you initially clone a repo, you (by
> default) get a "local branch" named "master" which is linked to
> (tracks) the remote master branch.

According to your terminology.  I think it diverges more than necessary
for the purpose of arriving at something sane and consistent from the
Git terminology.

> One of the fundamental confusing bits is that the word "local" in
> local branch does not mean "on local disk".  It is on local disk.  But
> so are the repositories copies of the "remote branches".  When you do
> a "git fetch --all", it will sync up the on-disk representation of the
> "remote branches" with an actual remote repository.  When you do a
> "git merge" from a working directory (local branch), you merge the
> differences from the linked (tracked) "remote branch" (on your local
> disk!) into your local branch.  "git pull" does both the fetch,
> updating your on-disk representation of the "remote branch",

Of _all_ remote branches.

> and the merge (updating your "local branch").

> I apologize if any of this is incorrect, but I agree with Alan and Eli
> that much of this is confusing.  I'm not entirely certain I have a
> correct understanding of this myself.

As I stated already: in Git's documentation "remote-tracking" is not
treated sanely, at least as far as I remember it.  I haven't checked
recently.

-- 
David Kastrup