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
Thank you, that make sense (even if it's really sad to have such
> > 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
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