Re: How can I automatically create a GIT branch that represents a sequence of tags?

From: Philip Oakley <philipoakley@iee.org>
Date: Aug 11, 2013, 07:49 UTC
Message-ID: <A728793F48D242F3BF93ACAA9D9F0F83@PhilipOakley>
In-Reply-To: <20130810232026.GF25779@paksenarrion.iveqy.com>

From: "Fredrik Gustafsson" <iveqy@iveqy.com>

Show 9 quoted lines

> 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.

Show 11 quoted lines

>>
>> 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.

Show 27 quoted lines

> 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