On Mon, Feb 07, 2011 at 12:18:39PM -0600, Norbert Thiebaud <nthiebaud@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.)
Attachment:
pgpKPYrLqYfVE.pgp
Description: PGP signature