16

I have committed a few source files to my git repository and tagged it as a new version of my software. But I saw a mistake I had just made and used the "amend" feature to commit the corrected files.

Now, I see that the tag was not transferred to the new commit (the one made with the "amend" feature). But I can also see that the tag still exists...

I would like to know what happened to the tag. Is this behavior a bug? Is the tag linked to a commit which doesn't exist anymore ?

I know I can force the creation of the same tag on the new commit, but I believe there should be a better way (like a command line parameter on the commit using "amend").

Benjamin W.
  • 46,058
  • 19
  • 106
  • 116
Joan Rieu
  • 999
  • 8
  • 19
  • There is no such parameter to `commit --amend` because tags are intended to mark a given commit; you do not in general want to move them around whenever you mess with commits. – Cascabel Jun 29 '10 at 18:56

1 Answers1

15

This is by design. Git tracks commits, tags, blobs and trees as SHA-1 hashes of their contents. They are simply pointers to the objects. The object that the tag points to is still there. This is the version of the commit before you amended it. Just delete the tag and create it again. Ensure that you let others that are using the repository know what you did if they started anything from that commit.

To get a good background of how git works, take a look at Scott Chacon's Rails Conference talk about git on gitcasts.com. Also, read the short book on git: progit.org/book.

user229044
  • 232,980
  • 40
  • 330
  • 338
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Thanks. I knew Git used SHA-1 but I thought the amend feature had simply removed the previous commit and that therefore, the tag had nothing to point to anymore. – Joan Rieu Jun 29 '10 at 18:35
  • 1
    @Fififox, that's one of the nice things about git, you can't ever lose something as long as you've got a reference to it somewhere. – kubi Jun 29 '10 at 18:41