This should probably be a Ponder question (See Support Resources).

What are you trying to do with those git tags? Why do you want them? What do you expect them to do?

git tags are bound to commit hashes, which change when the commit message is changed (For example, because you're adding a Differential Revision line).

We'd like to use them to tag releases.

In that case, you should create the tag when you release, and only release from code that was already pushed, not from code that is "about to be pushed".

You can push a single tag using git push origin tag <tagname>.

T10329 is likely also related if you really want to do what you've been doing so far.

That's what we've tried to do so far, but the git push tag command is being
blocked by our Herald rule because there is no approved differential
revision associated with that push.

If that herald is blocking your push, it means you're pushing new commits, not only new tags.

That might be what you want to do, but in that case you need to allow such commits (Possibly limiting them from going into master, for example).

Your usage of italic makes me think that perhaps tagging practices like
this are to be discouraged. Is this the case?

In T11121#179831, @julioromano wrote:

Your usage of italic makes me think that perhaps tagging practices like
this are to be discouraged. Is this the case?

I agree with @avivey

create the tag when you release, and only release from code that was already pushed, not from code that is "about to be pushed".

I do discourage it, but I was using italics to highlight the difference, which is pretty delicate.

In git, tags and branches are both called "refs"; Refs are almost literally a "named pointer to a commit hash".
a "Commit Hash" is a hash that's made of the commit content, it's history and it's message, which includes dates, author information, etc. If you change any of these things, you get a new hash, which in git terminology means it's a new commit object (Even if it's the same content and only adds some extra line to the commit message).

There's also another object called "annotated tag", which a ref may point to; That object has a commit hash, plus a comment and a signature. You create one using git tag -a.

When you push a ref - either a branch or a tag - you upload 2 things to the server:

• The ref
• All the commits leading up to the commit leading up to the ref

When you talk about "release tags", you're interested in a name (something like v12.4) that symbolizes some code+history; "Code + history" is a commit.

If your release process involves changing the code[1], then you're getting a new commit, and you're trying to push that commit when you push the tag.
It's right of you to want to push the changed code as the tag, because that's the code that was actually released; However, that code change doesn't have a revision attached, and you put in place a policy to prevent changes that have no revisions.

Some things you could do:

• Relax that herald rule, to allow (Some users) to push code to (tags, but not branches) without a revision.
• Change your release process, such that it doesn't require changing code; Then you won't be generating new commits, only new tags to existing commits.
• Split your release process, and do the "change code" part of it in a regular revision, while keeping the rest of it as is. This way you do generate a new commit, but it has a revision, so it's works anyway.

[1] This is the part I'm against.

Thank you guys, your explanations really made the difference. We are now happily tagging our releases. :)