On Wed, May 30 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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?
