[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: Michael Welsh Duggan
Subject: Re: Obscure error/warning/information message from git pull
Date: Sat, 15 Nov 2014 10:57:27 -0500
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/25.0.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> Alan Mackenzie <address@hidden> writes:
>> 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".
> No.  Your copy is a complete copy of everything you ask for.  If you
> don't clone a particular branch, for example, by using a single-branch
> clone, that branch will not magically be in your repository.

I think I may understand the disconnect here, but I am a git novice, so
Dave, please jump in and correct any inaccuracies.  I honestly think the
term that is causing the most difficulty right now is the word "local."
Read on.

>> 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.
> It depends on what you cloned.  It will clone exactly what you asked it
> to clone.  If you chose not to clone some branches, they will not be in
> your repository.

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

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

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

Michael Welsh Duggan

reply via email to

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