Ævar Arnfjörð Bjarmason [off-list ref] 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.
On Wed, May 30 2018, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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?