3 ms·

Nope. A tag is just a file in the .git directory. Delete the file, delete the tag. $ rm .git/refs/tags/v1.0 or in git syntax $ git tag -d v1.0 For this reas

Nope. A tag is just a file in the .git directory. Delete the file, delete the tag. $ rm .git/refs/tags/v1.0 or in git syntax $ git tag -d v1.0 For this reason one should never use tags when pulling code from untrusted repos, instead use the SHA1 hash which is much harder to forge.

avgcorrection 4y ago
Um okay. That is not what anyone means when they talk about immutable objects or refs in Git. I can delete a commit from `.git` but they are still considered immutable. A branch is mutable since you can push it forward without `--force` as long as the current commit becomes an ancestor of the next tip. Can you change a remote tag without `--force`? I don't know off the top of my head. But I doubt it.
- TobTobXX 4y ago
  Checked it for you: To /tmp/foo1/ ! [rejected] ddd -> ddd (already exists) error: failed to push some refs to '/tmp/foo1/' hint: Updates were rejected because the tag already exists in the remote. I think any ref is 'mutable' by these standards, and any hash is immutable (that's the entire point of a hash).
- colonwqbang 4y ago
  If you don't know, maybe you could give me the benefit of the doubt? In any case, the syntax to delete a remote tag is just e.g. $ git push origin :mytag After that you are free to push a new tag to replace the old, with no warnings or --force flags. When we use a tag to specify the version of a dependency, we trust the maintainer not to do this. If we don't have that level of trust we can use SHA1's instead. We should not pretend that there is anything in git that tries to prevent a tag from being rewritten by someone who wants to.
  - deleted 4y ago
    [deleted]
- Groxx 4y ago
  You can delete a random commit, but if anyone references it transitively, it'll immediately detect that breakage. E.g. you can't modify or remove commits "in the past" on your main branch. And "moving" a commit creates a new commit, with a different sha. Tags do not do that. Moving or removing a tag retains no history about the move, nor is the old value left hanging around somewhere (after pruning), nor will anyone who had not yet pulled the tag notice the removal, as with branches. Most configs will complain about the tag disappearing or moving, as with branches, but that depends on your config and the command you ran. (annotated tags do have their own sha and creation date and whatnot, which is great, but next to nothing references them. and removing them from a commit leaves no evidence that it ever was on that commit, as the commit is unmodified)
  - avgcorrection 4y ago
    > Most configs will complain about the tag disappearing or moving, as with branches, but that depends on your config and the command you ran. Needing `--force` with a default setup is literally all I meant by "immutable", apparently a cursed word in this context (the tip of a branch is supposed to be able to move in that common-history sense of movement). Gawd.

avgcorrection 4y ago

Um okay. That is not what anyone means when they talk about immutable objects or refs in Git. I can delete a commit from `.git` but they are still considered immutable. A branch is mutable since you can push it forward without `--force` as long as the current commit becomes an ancestor of the next tip. Can you change a remote tag without `--force`? I don't know off the top of my head. But I doubt it.

TobTobXX 4y ago
Checked it for you: To /tmp/foo1/ ! [rejected] ddd -> ddd (already exists) error: failed to push some refs to '/tmp/foo1/' hint: Updates were rejected because the tag already exists in the remote. I think any ref is 'mutable' by these standards, and any hash is immutable (that's the entire point of a hash).
colonwqbang 4y ago
If you don't know, maybe you could give me the benefit of the doubt? In any case, the syntax to delete a remote tag is just e.g. $ git push origin :mytag After that you are free to push a new tag to replace the old, with no warnings or --force flags. When we use a tag to specify the version of a dependency, we trust the maintainer not to do this. If we don't have that level of trust we can use SHA1's instead. We should not pretend that there is anything in git that tries to prevent a tag from being rewritten by someone who wants to.
- deleted 4y ago
  [deleted]
Groxx 4y ago
You can delete a random commit, but if anyone references it transitively, it'll immediately detect that breakage. E.g. you can't modify or remove commits "in the past" on your main branch. And "moving" a commit creates a new commit, with a different sha. Tags do not do that. Moving or removing a tag retains no history about the move, nor is the old value left hanging around somewhere (after pruning), nor will anyone who had not yet pulled the tag notice the removal, as with branches. Most configs will complain about the tag disappearing or moving, as with branches, but that depends on your config and the command you ran. (annotated tags do have their own sha and creation date and whatnot, which is great, but next to nothing references them. and removing them from a commit leaves no evidence that it ever was on that commit, as the commit is unmodified)
- avgcorrection 4y ago
  > Most configs will complain about the tag disappearing or moving, as with branches, but that depends on your config and the command you ran. Needing `--force` with a default setup is literally all I meant by "immutable", apparently a cursed word in this context (the tip of a branch is supposed to be able to move in that common-history sense of movement). Gawd.