[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: Eli Zaretskii
Subject: Re: Obscure error/warning/information message from git pull
Date: Sat, 15 Nov 2014 11:53:22 +0200

> From: David Kastrup <address@hidden>
> Cc: address@hidden
> Date: Sat, 15 Nov 2014 10:12:37 +0100
> >> git log --all --source
> >
> > This has the disadvantage of showing the branches in the obscure
> > refs/foo/bar/branch format.  Its advantage (AFAIK) is that it will
> > also show commits on remote branches that are not (yet) tracked by the
> > repo (please correct me if I'm wrong).
> 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".  I didn't see that explained in detail anywhere.

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"?

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?

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.  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?

> You are probably thinking of git showing remote-tracking branches
> (those are always destructively updated from the remote reference
> when fetching) as well as local branches (which may or may not have
> a remote upstream).

I was talking about local branches that track remote ones.  (And
"remote-tracking", btw, is a term that should have not been there,
because it unnecessarily muddies the water.  I suggest to refrain from
using it.)

reply via email to

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