[bironran]

afaik, the commit a tag points to is immutable unless you delete and recreate (and then nothing is immutable really).

re "ride" - that's exactly what I'm trying to avoid. It's an additional concept that isn't needed to understand Git. You need to understand the model. The "ride" is an emergent property of the model and commands that you eventually understand, but not a core part.

[kubanczyk]

Without the concept of "riding", terms "tag" and "branch" would become exact synonyms. In that case you can just remove point 2 (consider it just a syntactic sugar) and thus simplify your list.

If a tag has any attempt at immutability at the data structure level, I know nothing of it.

[mercutio2]

It's all about how other clients treat branches and tags.

Once you've pushed a tag, no other clients will be willing to update their definition of that tag unless the users on those other devices force the issue.

So operationally, "tags are immutable once pushed" is a pretty reasonable way to look at things.

Remotely pushed branches of course also won't allow you to do anything but append without forcing on remote clients, so mutable and immutable isn't quite right, here.

So I guess I agree with your original contention, branches are mutable-and-you-can-ride where ride means "the remote client's porcelain will be happy with append mutations".

[nemetroid]

As far as I know, tags don't have an identity beyond their name. The CLI tries to steer you away from replacing tags (by naming the option --force rather than, e.g., --modify), but that doesn't make them immutable.

[lvass]

See git tag -f.

Sometimes it's reasonable to consider a tag immutable, though you should always checksum if you do.