On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson <iv...@iveqy.com> wrote:
> 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?
For better or worse, the current state includes a lot of noisy "fixing
tests" type commits which I
would like to automatically skip over when hunting bugs. This is not
great and is being addressed,
but I am trying to make the most of the historical data we have today
- which does contain tags
for all builds that passed automated testing etc but does not have
only good commits on the related
> 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.
I can see how this would work, but only for future builds. I would
need something like it but loop
over all existing tags as this is a problem with historical data.
Could you please be more specific
as to the steps required to automatically form a commit that
represents the change between
two commits (i.e. tags)?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html