Chris Rorvick <ch...@rorvick.com> writes: > Minor changes since from v2 set. Reposting primarily because I mucked > up the Cc: list (again) and hoping to route feedback to the appropriate > audience. > > This patch set can be divided into two sets: > > 1. Provide useful advice for rejected tag references. > > push: return reject reasons via a mask > push: add advice for rejected tag reference > > Recommending a merge to resolve a rejected tag update seems > nonsensical since the tag does not come along for the ride. These > patches change the advice for rejected tags to suggest using > "push -f".
Below, I take that you mean by "tag reference" everything under refs/tags/ (not limited to "annotated tag objects", but also lightweight tags). Given that the second point below is to strongly discourage updating of existing any tag, it might be even better to advise *not* to push tags in the first place, instead of destructive "push -f", no? > 2. Require force when updating tag references, even on a fast-forward. > > push: flag updates > push: flag updates that require force > push: update remote tags only with force > > An email thread initiated by Angelo Borsotti did not come to a > consensus on how push should behave with regard to tag references. I think the original motivation of allowing fast-forward updates to tags was for people who wanted to have "today's recommended version" tag that can float from day to day. I tend to think that was a misguided notion and it is better implemented with a tip of a branch (iow, I personally am OK with the change to forbid tag updates altogether, without --force). > I think a key point is that you currently cannot be sure your push > will not clobber a tag (lightweight or not) in the remote. "Do not update, only add new" may be a good feature, but at the same time I have this suspicion that its usefulness may not necessarily be limited to refs/tags/* hierarchy. I dunno. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
