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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, May 30 2018, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> 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.
>> ...
>> 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".
>
> Correct.  Originally, there was *no* way in the protocol to carry
> the information, so the code always had to guess.  The point of
> setting origin/HEAD was mostly so that you can say "log origin.."
> and rely on it getting dwimmed down to "refs/remotes/%s/HEAD..",
> and it wasn't a common practice to interact with multiple remotes
> with remote tracking branches (integrator interacting with dozens
> of remotes, responding to pull requests using explicit URL but
> without configured remotes was not uncommon), so it was sufficient
> for "git clone" to create it, and "git remote add" did not exist
> back then anyway.
>
> There are two aspects in my answer to your question.
>
>  - If we create additional remote (that is, other than the one we
>    get when we create a repository via "clone", so if your "origin"
>    is from "git init there && cd there && git remote add origin", it
>    does count in this category), should we get a remote-tracking
>    symref $name/HEAD so that we can say "log $name.."?
>
>    We absolutely should.  We (eh, rather, those who added "remote
>    add"; this was not my itch and I am using "royal we" in this
>    sentence) just did not bother to and I think it is a bug that you
>    cannot say "log $name.."  Of course, it is just a "git symbolic-ref"
>    away to make it possible locally, so it is understandable if
>    "remote add" did not bother to.
>
>  - 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.
>    Namely, I feel uneasy about the fact that the meaning of "log
>    ..origin" changes across a fetch in this sequence:
>
>      log ..origin && fetch origin && log ..origin
>
>    Without repointing origin/HEAD, two occurrences of "log ..origin"
>    both means "how much ahead the primary branch we have been
>    interested in from this remote is, relative to our effort?".
>    Even though we fully expect that two "log ..origin" would report
>    different results (after all, that is the whole point of doing
>    another one after "fetch" in such a sequence like this example),
>    our question is about the same "primary branch we have been
>    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.

We already have to deal with this special case of origin/HEAD being
re-pointed in a repository that we "clone", so we would just do whatever
happens to a repository that's cloned.

I.e. the "clone" sets the origin/HEAD up as a one-off, and then keeps
updating it on the basis of updating existing refs. We'd similarly set
it up as a one-off if we ever "fetch" and notice that the ref doesn't
exist yet, and then we'd update it in the same way we update it now.

So this seems like a non-issue to me as far as me coming up with some
patch to one-off write the origin/HEAD on the first "fetch", or am I
missing something?