Re: [PATCH v2 06/10] push doc: correct lies about how push refspecs work

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 30, 2018, 15:23 UTC
Message-ID: <xmqqh8jb7uax.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <87o9djdi0c.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I.e. the non-refs/{tags,heads}/* update logic treats all updates to
> tags/commits as branch updates. We just look at the tag v2.18.0, see you
> want to replace it with the commit v2.19.0-rc0^{} and see "oh, that's a
> fast-forward".

In my old message you are responding to, I asked what you meant by "will be treated as branches", and after seeing "as branch updates" above, I think I know what you want the phrase to mean, namely, that old-to-new transition requires new to be a descendant of old. But I think that is weaker than what other people (including me) thinks of rules to update refs/heads/* hierarchy (i.e. "branch update").

You are allowing to store an object that is not a commit in refs/blah/my-tag in your example, so it clearly does not protect the ref with an extra rule that applies to "branches", namely, "it has to be a commit."

> Arguably that should be changed, but I won't do that in this series.

OK.