Re: git fetch documentation problem or bug

[Junio C Hamano <gitster@pobox.com>]

Drew Northup <n1xim.email@gmail.com> writes:

> On Mon, Oct 8, 2012 at 7:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>> 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 do not know what you meant by the three dots, but you are supposed
to know what you meant by $branch... whatever it is.  It is what you
wrote, not I did ;-)

Let me clarify what is in the message you are responding to.

	git fetch $from $branch

(no colon in $branch part anywhere) traditionally meant a short-hand
of saying

	git fetch $from $branch:

I.e. "fetch $branch and store in FETCH_HEAD but not anywhere else".

The hypothesized change is to make it a short-hand of saying

	git fetch $from $branch:refs/remotes/$from/$branch

when "git fetch $from" is already configured to store the result
there. 

Without [remote "$from"] fetch = refs/heads/*:refs/remotes/$from/*
configured, it will still mean "git fetch $from $branch:".

And for the record, I am *not* enthused about such a change.  I am
only saying that, seeing that many new people seem to wish the
command behaved that way, such a change would not hurt existing
users too much.  Switching the meaning of shorthand (i.e. a piece of
refspec that does not have any colon) from "just fetch but do not
store" from "fetch and store in the remote tracking ref if it is
configured to do so without command override" is still a backward
incompatible change.

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

This is not about your preference.  This is about what happens when
you say something on the command line to override your explicit
setting you have in $GIT_DIR/config

	[remote "$from"] fetch = ...