Re: Is origin/HEAD only being created on clone a bug? #leftoverbits

From: Jeff King <peff@peff.net>
Date: Jun 1, 2018, 06:51 UTC
Message-ID: <20180601065121.GA15578@sigill.intra.peff.net>
In-Reply-To: <xmqqbmcxg8sn.fsf@gitster-ct.c.googlers.com>

On Wed, May 30, 2018 at 11:46:16AM +0900, Junio C Hamano wrote:

Show 15 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
> >  - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> >    if the protocol notices that their HEAD today is pointing to a
> >    branch different from what our side has, should we repoint ours
> >    to match?  
> >
> >    I am leaning against doing this, but mostly out of superstition.
> > ...
> >    interested in".  But once fetch starts messing with where
> >    origin/HEAD points at, that would no longer be the case, which is
> >    why I am against doing something magical like that.
> 
> Well, I shouldn't say "I am against" on the last line; rather, "I
> feel uneasy".

I didn't bother to dig up the past discussions, but I am pretty sure we intentionally avoided updating origin/HEAD without an explicit action from the user. Because what the other side considers "the default branch" and what you consider "the default branch" when dealing with the remote are not necessarily the same thing. If we auto-adjust the symref on fetch, we might be undoing the user's previous "git remote set-head" operation.

I don't have any real problem with creating it if it _doesn't_ exist, though. (I think ideally it would get created by "remote add", but that command does not always talk to the remote, so this kind of delayed-create is probably the best we can do).

-Peff