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

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

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