On Mon, Feb 07, 2011 at 09:38:14AM -0600, Norbert Thiebaud <nthieb...@gmail.com> wrote: > 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.
You mean when g commit && g push creates / pushes multiple commits? For example when you rename a function in a repo and fix the build in 3 other ones. It would be really nice not to try to test the 3 ones where the build will obviously fail (and the tinbuild approach provides this). OTOH of course that's possible - provided that those hooks still push the state to a githeads.git? > 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) Sure - I don't have an idea either how to not count a merge as a single step with split repos.
pgpPIPOn65vtw.pgp
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
