While I really like git's rebase ability, it falls down when dealing with existing tags and this has bugged me since I started using git a few years ago. Tonight I had to refactor a large library and move some branches/files/folders around. This repo had a lot of version tags and I really didn't want to suffer the pain of manually retagging the commits like I've done in the past.
Anyhow, I tried several different scripts I've found, and git-rebasetags was the only one that had the most success. Unfortunately, it got to the 1 yard line, but didn't make it into the endzone.
To illustrate, I will keep this as simple as possible:
$ mkdir foo
$ cd foo
$ git init
$ git config alias.brga log --graph --pretty=oneline --abbrev-commit --decorate --all --date-order
$ git commit --allow-empty -m"epoch"
$ z=a; echo $z>$z; git add $z; git commit -m$z; git tag t${z}
$ git checkout -b z
$ z=n; echo $z>$z; git add $z; git commit -m$z; git tag t${z}
$ z=o; echo $z>$z; git add $z; git commit -m$z; git tag t${z}
$ git checkout master
$ z=b; echo $z>$z; git add $z; git commit -m$z; git tag t${z}
**Now look at the overall commit tree
$ git brga
**Now we want to rebase branch z and bring it current to master
$ git checkout z
$ git-rebasetags master
**It should say that tag 'tn' was remapped and a warning that 3tags without a match
**Look at commit tree again
$ git brga
At this point, you will find that tag 'tn' was handled correctly, however tag 'to' is still on tip of dangling branch and was not applied to the tip of branch 'z'
Your thoughts on this would be appreciated.
[rant] Why this isn't an optional ability that git rebase (proper) has is beyond me, because that is the most opportune time to shift tags is when the old=>new sha1 mappings list is currently in play [/rant]