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

[Alan Mackenzie <acm@muc.de>]

Hello, David.

On Sat, Nov 15, 2014 at 11:28:11AM +0100, David Kastrup wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: David Kastrup <dak@gnu.org>
> >> Cc: emacs-devel@gnu.org
> >> 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".

> All the references you fetched/cloned and everything they point to.

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

> The manual is clear about that.

I second Eli's comment on this.

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

So "git clone" is defined in terms of "clone".  Looks like a recursive
"definition" to me - part of what "git clone" does is to "clone[s] a
repository".  There then follows an incoherent list of the form "does A,
then does B, then does C, ...".

What is missing is a definition of "clone".  It would appear to mean
"make a partial copy of".  This is in contrast to the word's uses in all
other contexts where it means "duplicate".

Please correct me if I'm mistaken here, but I think my "git clone"ing of
the repository at savannah only partially copied that repository, thus I
have an incomplete copy of it.

So git's concept of "distributed vcs" is that the repository is
collectively stored across many computers, as contrasted with bzr's and
hg's model where the complete repository is stored on each participating
computer.

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

> git-clone does not create more _local_ branches than the one it creates
> and checks out from the currently active branch of the remote
> repository.

And a subsequent git checkout will require access, possibly net access,
to the repository from which the current one was copied, yes?

[ .... ]

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).