How can I automatically create a GIT branch that represents a sequence of tags? [CLOSED]

Question

In our current setup, we have automatic tagging in git of all successful release builds. This makes it easy to go back to stable points in history and compare functionality, check when bugs were introduced etc.

To help with this process further, it would be useful to be able to use git bisect, but as these are just a sequence of tags, not commits on a branch, git bisect will not work as is.

Is there any tooling for automatically recreating a branch from a sequence of tags, where each generated commit is the calculated delta between each two neighboring tags?

Comments

git bisect takes arbitrary revisions, there is no restriction on using tags as bounds.

Answer 1

I don't understand, why is it better to find between which tags a error was found and not in what commit. It's much easier to find a bug introduced in a commit than in a tag/release. It sounds like you're doing the bug hunting harder. Could you explain this further?

It would be very hard to do a tool such as you describe, the reason is that there's no sane way to order your tags. Git today show tags alphabetically, all versions does not have a alphabatic order. You could argue that it should be in the order of the tagged commits commit date, however the commits are not ordered by date, an older commit can have a younger commit as a parent. You could say that the tag order is the order you find the tags if you go from a branch and backwards in the history, however how do you then choose which path to take when you find a merge?

My suggestion if you want to do this, is to have your buildtool to checkout a special branch (let's call it tag_branch) do a git reset to get the worktree from the newly tagged commit and commit on that branch once for each tag it's creating, when it creates the tag.

It would be quite easy to make a script that create such branch for you, if you only can sort the tags somehow.

Answer 2

GNU sort has a nice option that can sort this way:
-V, --version-sort
Sort by version name and number. It behaves like a standard sort, except that each sequence of decimal digits is treated numerically as an index/version number.

Comments

That's a nice feature. It works well with git.git version numbers but won't be useful in this case for git.git since git.git has other tags too (like the gitgui version tags). However if you've a nice namespace for the tags where you only tags versions, it might be an alternative.

Answer 3

I was going to say simply use git describe --contains and check the result is ^0 first and then either skip the commit (git bisect skip) or test it.

Unfortunately I think it will conflict with the binary search style (i.e. a too sparse history with good tags). In such case it may be useful to have an alternate search style but that would be a code update.