Before we start, you must go to the jgit directory, where we made the original clone for this post.
We should start by tagging the commit that is ten commits behind origin/stable-2.3 and is not a merge. In order to find that commit, we will use the git log command.
Step 1 : Find the commit as follows:
Step 2 : Now that we have found the 60d538f commit, we should make it a lightweight tag. Use the git tag command to give a meaningful release name:
Step 3 : To see whether the tag is available, use the git tag command:
Step 4 : Our tag is available, but all it really says is that we have a tag in the repository with the name v2.3.0.201302061315rc1, and if you are using git show v2.3.0.201302061315rc1, you will see that the output is the same as git show ea060dd:
Step 5 : There will also be a lot of file diff information in the output, but it is exactly the same output. So, in order to add more information, we should use an annotated tag. An annotated tag is a tag where you have to add some information to the tag. To create an annotated tag, we use the --annotate tag for the git tag command:
Step 6 : The -m flag is the same as --message, as we want to give the tag a message. If you leave out the -m flag, Git will open the configured editor and you can write a full release note into the annotation of the tag. We can check the tag information with git show:
Step 7 : Tags are very powerful as they can add valuable information to the repository, and since tags should be considered official releases in the repository, we should be very careful when working with them. You can push the tags to a remote area, and contributors to the repository would fetch those tags. If you change a tag that you have already pushed to point to another commit hash, then those developers who have already fetched the tag will not get the new tag unless they delete the tag locally
Step 8: To prove the dangers of not getting a new tag, we will try to delete a tag and recreate it to point to another commit hash:
Step 9 : Now that we have deleted the tag, we are ready to recreate the tag again to point to HEAD:
Step 10 :We have recreated the tag, and it points to HEAD because we did not specify a commit hash at the end of the command. Now, execute git fetch to see whether you can get the tag overwritten from the remote repository:
Step 11 : Since there is no output, the tag was probably not overwritten. Let's verify with git show
Step 12 : As you can see from the output, it is still our locally created tag. To get the tag from the remote again, we need to delete the local tag and do a git fetch. To delete a tag, you need to apply the -d flag:
Step 13 : As you can see, Git has fetched the tag from the server again. We can verify with git show:
So, as you can see, we have the correct tag again, but it should also be a warning. Once you have pushed a tag to a remote repository, you should never change it, since the developers who are fetching from the repository may never know about the changes unless they clone again or delete the tags locally and fetch them again.