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

[David Kastrup]

Achim Gratz <address@hidden> writes:

> Alan Mackenzie writes:
>> After a "git clone", the copy is not the same as the original.
>
> If you really want an exact copy of your local repository, then just
> make a plain copy or do a mirror clone, THis implies making it "bare"
> (without a work tree), so you'd then have to move things around so that
> you can have your work tree checked out.  But you can do that, it's just
> that this is almost never what you want.
>
>> In particular, branches are not preserved.  I don't know, as yet, what else
>> fails to be copied, but I have no great confidence in the documentation
>> to tell me.
>
> You don't want second generation clone of the Savannah repository, you
> want another first generation one.  Again, the most efficient way to do
> this is to reference your already existing clone when doing it so that
> the actual objects are not transferred again over the net, but taken
> from the "master" clone.
>
> […]
>> This is confusing.  Is it the case that branches labelled
>> "remotes/origin/..." are completely contained within the same repository?
>
> No, they are labels pointing to the (heads of the) corresponding
> branches in the upstream repository.

Git fetches all information sitting behind such labels whenever it
fetches a label, so that "No" is either used in some extremely
misleading manner or just mistaken.

_Every_ branch in Git, remote-tracking or local, is just a label
pointing to some object.  Both upstream repository and local repository
are object stores, and any object having the same SHA1 is the _same_
object.  There is no such thing as "corresponding branch in the upstream
repository".  Object ids mean exactly the same in upstream and clones.
It is one namespace.  I can manually set a label without getting the
information, local or remote.  Then the repository is incomplete (git
fsck would complain).  I can fill in the missing objects in any way
I like: by fetching them, or by using

    git hash-object -w

on a file with suitable content.

> A branch is nothing more than a label in Git, all you really need to
> know is the SHA1 for the branch head to (re-)create it.

Not really: you need the objects behind it as well.  When deleting a
branch, the object store of Git keeps them around for a few weeks and
will clean them out then on the next garbage collection.  If you
recreate the branch head any time before that, this will work without
problem.  If you recreate it afterwards, the repository will be
incomplete.  Fetching branches is more reliable than creating references
and hoping that the objects will happen to be around.

-- 
David Kastrup