On Mon, Feb 7, 2011 at 11:10 AM, Miklos Vajna <vmik...@frugalware.org> wrote: > 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).
The problem of the tinderbox approach is the coarse granularity (it is not uncommon to have 1/2 a dozen or more of independent commit between 2 build, the reliability (tinderbox sometime are down and this is not necessarily detected quickly). furthermore if you only record 'good' tinderbox run, you may have a few days of commit in one interval. if you don't then you are in the same case than the scenario above (it doesn't build because of interdependent commit); One thing that we could do is that the pus-hook could do a commit amend if the committer is the same that the very last one. presumably linked commit on multiple repo are pushed 'together' so if a push on repos A is immediately followed by a push on repo B then the hook would do a git commit --amend instead of creating a new version. that ways you usually fold all theses change into one 'list-head' Of course you could have a race between two committer... but that is _really_ rare. Norbert >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. > _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice