nachoparker / git-rebasetags

Perform a git rebase operation, restoring original tags
https://ownyourbits.com/2017/08/14/rebasing-in-git-without-losing-tags/
GNU General Public License v3.0
30 stars 5 forks source link

Does not transfer all relevant tags after a rebase #1

Closed TerraTech closed 7 years ago

TerraTech commented 7 years ago

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]

TerraTech commented 7 years ago

Also, I keep seeing a lot of chatter that git filter-branch --tag-name-filter cat, is supposed to fix tags after a rebase, but I have yet to figure out how to make it work.

TerraTech commented 7 years ago

In regards to my earlier rant, it appears an attempt was made to add git rebase --preserve-tags, but I guess it never made it into the codebase. I haven't been able to find a reason why it wasn't accepted. https://www.spinics.net/lists/git/msg63672.html

nachoparker commented 7 years ago

Hi,

The only information that this has to map the tags from the old to the new commits is the commit description. If it changes or there are duplicated identical descriptions not all the tags will be restored successfully. You will have to do that manually for those tags.

I explain this things in the post where I published git rebasetags

About git filter-branch, I wrote about it in the post where I explain git rebasetags.

You can do something like this,

git filter-branch --tag-name-filter cat --index-filter "git rm --cached --ignore-unmatch file.blob"

but that kind of example is insufficient because it does not support interactive rebasing. That's why I wrote this.

nachoparker commented 7 years ago

In regards to my earlier rant, it appears an attempt was made to add git rebase --preserve-tags, but I guess it never made it into the codebase. I haven't been able to find a reason why it wasn't accepted. https://www.spinics.net/lists/git/msg63672.html

Well, it seems like they do not want tags to be used as immutable commits and they want to discourage history rewriting, according to what I read.

TerraTech commented 7 years ago

git filter-branch --tag-name-filter cat --index-filter "git rm --cached --ignore-unmatch file.blob" I tried to run that on the library I was working on as well as the example/test repo for this issue, but it didn't do anything useful. :(

nachoparker commented 7 years ago

I tried to run that on the library I was working on as well as the example/test repo for this issue, but it didn't do anything useful. :(

That removes a file named file.blob from the whole history of the repo. Obviously you need to have that file in the repo :)

It was only an example

nachoparker commented 7 years ago

I'll close because I do not see any way around the fact that I use commit descriptions to do the matching, so with changed descriptions or duplicated descriptions things will no go perfect.

Ideas are welcome ;)

TerraTech commented 7 years ago

Thank you for the explanation, much appreciated.

nachoparker commented 7 years ago

welcome!