On Mon, Feb 07, 2011 at 12:18:39PM -0600, Norbert Thiebaud <nthieb...@gmail.com> wrote: > 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);
Hm, OK. > 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. Automatic git commit --amend is really dangerous, I would not do it. It's not an accident non-fastforwards are rejected while pushing. So - in case post-receive hooks on the freedesktop servers are allowed (CIA is not notified from such a hook at the moment), we could create a githeads.git which is updated after every push and git bisect could run there. Given that there is a githeads.txt in that repo, the g wrapper could update the repos accordingly. Does this sound acceptable? (And there could be multiple branches in githeads.git, just like in the repos.)
pgpJhHrvup0ci.pgp
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
