Re: New way of tracking remote branches -- question

From: Junio C Hamano <junkio@cox.net>
Date: Jan 5, 2007, 23:39 UTC
Message-ID: <7vmz4xcacr.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vzm8xcbcp.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 13 quoted lines

> Luben Tuikov <ltuikov@yahoo.com> writes:
>
>> I can see that the remote heads are where they are supposed to be
>> but no local tracking heads are created (by default).  I had
>> to do this manually.
>>
>> Old behavior was that git did that for you automatically.
>> So I suppose this is another newbie protection.
>
> A very fuzzily stated question which is hard to answer, but I do
> not think it is another newbie protection, if it apparently is
> actively hurting you.  Also the documentation may need to be
> updated to teach you enough about how to achieve what you want.

Can you state the problem you observed about the recent git in a way that is easier to debug?

For example, you could state:

	With older git (I verified that v1.3.0 still works like
	this), I used to be able to just say:

		$ git fetch

	(this is the exact command line -- I am not giving a URL
	nor even "origin" after "git fetch").  When the upstream
	created a new branch 'blah', the above command created a
	new local branch 'blah' automatically for me.  With the
	tip of 'master' (e27e609), this does not happen anymore.

	My configuration is that I have .git/remotes/origin file
	whose contents is ....  I do not have any remote.*.url,
	remote.*.fetch, nor branch.*.remote configuration variables.

to be more helpful.

I am not dismissing your message as whining. You probably have hit a regression while we adopted the BCP to encourage separate remote layout, and I would like to understand the issue.