From: "Fredrik Gustafsson" <iveqy@xxxxxxxxx>
On Sat, Aug 10, 2013 at 11:29:45PM +0100, Kristian Freed wrote:
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.
I was going to say simply use `git describe --contains <sha1>` and check
the result is <tag>^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.
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 neighbouring tags?
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?
I can see that in many commercial environments that this would be
considered "best practice" (which actually equates to common practice,
rather than good practice). Obviously in a FOSS environment the
developers are willing to use the 'rebase until ready' approaches until
their patches are acceptable. In a large corporate it can be that the
fixes are locally good but globally bad, hence the extra tagging step.
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 alphabtic 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.
--
Med vänliga hälsningar
Fredrik Gustafsson
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html