Closed TerraTech closed 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.
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
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.
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.
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. :(
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
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 ;)
Thank you for the explanation, much appreciated.
welcome!
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:
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]