On Sun, Aug 11, 2013 at 12:13:18PM +0100, Kristian Freed wrote: > 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 > branch.
Thank you, that make sense (even if it's really sad to have such history). > > > 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)? > Create an orphan branch: git checkout --orphan tag_branch Now for every tag, t: git checkout t git reset --soft tag_branch git add . git commit -m "t" -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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
