On Mon, Feb 7, 2011 at 9:02 AM, Miklos Vajna <vmik...@frugalware.org> wrote: > On Sun, Feb 06, 2011 at 05:44:03AM -0600, Norbert Thiebaud > <nthieb...@gmail.com> wrote: >> humm... what build.git ? :-) on master I do not even clone build.git >> anymore... > > Then bootstrap.git, you get it. :)
;-) > > > (I mean tinbuild would push the contents of git-heads.txt to a > githeads.git, then 'g bisect' would call 'git bisect' in githeads.git and > after the working directory is updated there, it would check out the > commits in the repos based on git-heads.txt so that it's possible to do > the actual testing. That's not so hard to implement for bisect > start/good/bad/reset.) How about having a after-push git-hook in the master branch in our git.fdi/git/libreoffice/* git repos that generate the list of HEAD-sha1 that was you should be able to almost-completely bisect. sure in some cases the fact that 2 commit in two git are interdependent would throw off the bisection. but that is not that common. Another problem would be merge of feature branches, which would be counted as just one bisect step for the whole branch.... (but that is true even with the tinderbuild based solution) Norbert _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
