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

From: Junio C Hamano <junkio@cox.net>
Date: Jan 5, 2007, 23:20 UTC
Message-ID: <7vvejlcb6z.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <826.67287.qm@web31809.mail.mud.yahoo.com>

Luben Tuikov <ltuikov@yahoo.com> writes:

Show 21 quoted lines

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

        [remote "origin"]
                url = http://blah/blah.git
                fetch = refs/heads/master

is also fine. The point is that you do not have to use tracking branches. ", and when you get it here, ..." part is optional.

Show 13 quoted lines

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

Obviously fetch needs to handle the remote part because that is the only name it exists at the remote. branch.*.merge is used by pull, not fetch, and fetch communicates with pull by using the remote name, because use of local tracking branches is optional.