nachoparker / git-rebasetags Goto Github PK

It's pretty common in our workflow that we need to rebase a branch and then, after the rebase we need to manually move all the branches that were left behind on the no the old commits. Is it possible to change this script to rebase branches also, the same as it rebases tags?

I'm running Ubuntu 18.04 inside WSL and the rebase itself works fine, but moving the tags fails.

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]

While updating the large library, I found that several tags were misapplied due to having the same commit message.

In my case, I had added tags to 'go fmt'.

A lot of times, while hacking on Go code, I'll incrementally commit my changes, and when I'm ready to tag it, I'll run:

$ go fmt
$ git commit -a -m"go fmt"
$ git tag 1.2.3

I do it this way, as the prior commit shows just specifically the changes I made, where when 'go fmt' is run it can adjust a lot of non-related code with formatting changes.

Unfortunately, this will cause problems for git-rebasetags. My ideas is to also use Author and AuthorDate as matching criteria as that shouldn't change during rebases.

$ git log --pretty=fuller

What do you think about this and possibly other seldom-to-change items from the commit message? I know Author* items can be changed in history, but for the most part it would add an extra level of matching criteria that should increase the success rate.