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

From: Brandon Williams <bmwill@google.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
Date: Tue, 29 May 2018 12:17:25 -0700	[thread overview]
Message-ID: <20180529191725.GA259827@google.com> (raw)
In-Reply-To: <87bmcyfh67.fsf@evledraar.gmail.com>

On 05/29, Ævar Arnfjörð Bjarmason wrote:
> Here's some more #leftoverbits where we have a clone/fetch feature
> discrepancy and where clone is magical in ways that "fetch" isn't.
> 
> If you make an initial commit and push to a remote repo "origin", you
> don't get a remote origin/HEAD reference, and a "fetch" won't create it
> either.
> 
> You will get it if you subseuqently "clone" the repo, but not if you use
> "git init / remote add / fetch / git checkout -t" which should otherwise
> be equivalent.
> 
> If you push to "master" (or whatever HEAD is) from the clone the
> origin/HEAD will be updated accordingly, but from the repo you pushed
> from & the one you did init+fetch instead of clone you'll never see it.
> 
> Some code spelunking reveals remote_head_points_at, guess_remote_head()
> etc. in builtin/clone.c. I.e. this is special-cased as part of the
> "clone".
> 
> Can anyone thing of a reason for why this shouldn't be fixed as a bug?
> I've tried searching the archives but "origin/HEAD" comes up with too
> many
> results. https://public-inbox.org/git/alpine.LSU.1.00.0803020556380.22527@racer.site/#t
> seems to be the patch that initially added it, but it is not discussed
> why this should be a clone-only special case that doesn't apply to
> "fetch".

I believe the issue has to deal with how symrefs are handled.  I don't
think any of the fetch code path does anything special with symrefs.
Symref info does get sent over the wire for the HEAD symref but i think
its just ignored.  You'll see updates for origin/HEAD when you
subsequently fetch most likely because its recorded as a symref locally
which points at origin/master. This means that when you fetch
origin/master, origin/HEAD will also but updated just because its
locally a pointer to origin/master.

With that said, yes we should probably fix this issue with fetch because
I added symref support to protocol v2 so now symref information for refs
other than HEAD can be sent across the wire but the client just throws
that info away at the moment.

-- 
Brandon Williams