Ævar Arnfjörð Bjarmason <[email protected]> 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.
