Re: git fetch documentation problem or bug

From: Drew Northup <n1xim.email@gmail.com>
Date: Oct 21, 2012, 12:15 UTC
Message-ID: <CAM9Z-nnKTq0C9wPA=JKZ3qzTmL3NVisfy=rbjjq1yKEVrN53FQ@mail.gmail.com>
In-Reply-To: <7vpq4silou.fsf@alter.siamese.dyndns.org>

On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> In other words, you can do this from the command line if you want
>> to do the update.
>>
>>   $ git fetch origin master:refs/remotes/origin/master
>
> Now having said all that, we should probably revisit this and
> possibly other issues and for the ones we can reach concensus, start
> coding after 1.8.0 final.

Show 14 quoted lines

>  * "git fetch $from $branch..." to update tracking branches
>
>    This is the topic in this thread.
>
> I personally do not think the downside of breaking backward
> compatibility is too bad.  If we do this only when we already are
> configured to keep remote tracking branch for branch $branch from
> remote $from (it has to be given as a nickname, not URL that happens
> to have an entry in the configuration), then a promiscuous fetch
> that grabs from a URL (or a nickname that is configured not to keep
> tracking branches) will not change any behaviour, and when you want
> to keep your remote tracking branch intact while doing one-shot
> fetch for whatever reason, you can say "git fetch $from $branch:" to
> explicitly decline copying.

How are we supposed to remember those are different?

"git fetch $from $branch..." VS "git fetch $from $branch:"

I strongly prefer EXPLICITLY setting tracking than expecting some extreme syntactic nuance to quietly do it for me now and confuse the heck out of me later.

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59