On Mon, Feb 07, 2011 at 09:38:14AM -0600, Norbert Thiebaud <nthiebaud@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.
Attachment:
pgp47fhzNybdr.pgp
Description: PGP signature