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

2 messages, 2 authors, 2018-08-30 · open the first message on its own page

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

From: Junio C Hamano <hidden>
Date: 2018-08-30 15:23:07

Ævar Arnfjörð Bjarmason [off-list ref] 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.

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

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2018-08-30 16:59:48

On Thu, Aug 30, 2018 at 5:23 PM Junio C Hamano [off-list ref] wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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."
Indeed. This was all confusing. I've reworded in something I'll send
shortly, which should address this confusion.
quoted
Arguably that should be changed, but I won't do that in this series.
OK.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help