3 ms·
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 tryin
by bironran 5y ago
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.
- lvass 5y agoSee git tag -f. Sometimes it's reasonable to consider a tag immutable, though you should always checksum if you do.
- kubanczyk 5y agoWithout 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 5y agoIt'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 5y agoAs 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.