Jeff King <peff@xxxxxxxx> writes:
> Hmm. It seems like the symbolic ref is the culprit, not just HEAD. The
> HEAD thing is the most likely, of course, but I could do something like:
>
> git symbolic-ref refs/remotes/origin/convenient-alias \
> refs/remotes/origin/some-name-you-dont-like
Isn't it already wrong to do the above locally, in the sense that it is
equally wrong to do this?
git update-ref refs/remotes/origin/no-such-thing-exists-over-there
refs/heads/master
I agree that the symbolic ref is the real source of confusion in Stephen's
case (I admit that I was scratching my head chasing a non-existent bug in
transport_update_tracking_ref() before I realized what was happening), but
the usual (and the only) way for refs/remotes hierarchy to get a symbolic
ref is via a normal clone, and HEAD is the only name that can cause this
conflict. Creating a branch called HEAD (or FETCH_HEAD for that matter)
is infinitely more likely to be a mistake than being clever, I think.
> ... Maybe we should not follow symbolic
> refs during fetch. So if we are fetching the refspec "foo:bar", and the
> RHS "bar" is a symref, we should _not_ follow it, but instead just
> overwrite the symref with a regular ref.
>
> For pushing, one rule could be to allow pushing from a named symref, but
> not allow the matching rules to use a symref as a source....
I personally like this line of thought, especially as a thought experiment
to see what corner cases we could find, but I doubt I will be able to say
we covered all the corner cases with confidence without thinking long and
very hard. For now, I do not find this issue worth spending that kind of
deep thinking, especially when a lot simpler and easier to explain
workaround is available, but others may disagree and perfect your idea.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html