Re: [PATCH] Documentation: update git-pull.txt for clone's new default behavior

[Luben Tuikov <ltuikov@yahoo.com>]

--- Junio C Hamano <junkio@cox.net> wrote:
> 
> Because [remote] is NOT about mapping.  It asks the fetch
> mechanism to fetch from that remote, so the primary thing you
> should look at is .url, not RHS of colon on .fetch lines.  Use
> of tracking branches is strictly optional.

Remote
------

Please help me understand.  Here is a sample remote from
an actual repo (actual names changed):

[remote "origin"]
        url = http://blah/bleah.git
        fetch = +refs/heads/*:refs/remotes/origin/*

This basically says: "Get it" from such and such url, where
on the repo at that url, i.e. the remote side, you will
find stuff in "refs/heads/", and when you get it here, locally,
put it in refs/remotes/origin/.

Now if this isn't a mapping, then please can someone
explain to me what a "mapping" is?

The "fetch = <remote>:<local>" is inherently a mapping,
its syntax dictates it, as does the actual actions
it performs: "fetch" from "remote" and "put in local <local>".

Branch
------

Here is an actual example:

[branch "branchA"]
        remote = origin
        merge = refs/heads/branchA

Yeah, but by default "refs/heads/branchA" doesn't exist (see
my previous email).  It doesn't have to, since it specifies
the "remote part", but that has already been handled by
"[remote]".

Unless of course "[branch "..."]" specifies the _remote_ branch
being tracked in refs/remotes/origin.  Is this the case.

Does "[branch]" apply to local branches too?  If so,
then what happens when refs/heads/branchA does exist and is
the same as the one it describes -- i.e. completely old behavior.

Thanks,
    Luben