On Sun, Aug 11, 2013 at 12:20 AM, Fredrik Gustafsson <iveqy@xxxxxxxxx> 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 branch. > 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)? Thanks, Kristian -- 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