Re: [PATCH] Contribute a fairly paranoid update hook

Jakub Narebski <jnareb@gmail.com> wrote:

...

I added a "pending" action and link in the top navigation bar. This page shows all of the topic branches that:

 - match a particular prefix string
   (e.g. "heads/test/pending/");
 - has commits not reachable through refs matching another prefix
   (e.g. "heads/test/approved/")
 - has commits not reachable through another specific ref
   (e.g. "heads/test/current").

These branches are sorted by name and show under their title a shortlog of the "new commits" that aren't reachable by the latter two sets of refs.

Sometimes branches fully contain another; these are identified under both branches. When this happens commits are only shown under one of the two listings.

Here's a rough ASCII approximation of the pending page:

  fix1:

    Also bundled within:
    
      * set-of-fixes

    Shawn Pearce      don't be stupid, delete temp files

  fix2:

    Also bundled within:

      * set-of-fixes

    Shawn Pearce      don't leak printer handles

  set-of-fixes:

    Includes topics:

      * fix1:
      * fix2:

    Stewie Griffin    Merge 'tiny-fix1'
    Stewie Griffin    Merge 'tiny-fix2'
    Glenn Quagmire    Improve performance by sucking less

Each topic branch also has an "approve" link, which uses an "approve" action to copy the branch (err, create a new branch with update-ref) into the "heads/test/approved/" namespace. This causes them to fall out of the "pending" page when it reloads.

The approved page shows topics matching the "heads/test/approved/" page, but that have commits not in "heads/test/current". It looks exactly like the pending page above, but has an "unapprove" link to delete the ref from the "heads/test/approved/" directory.

Why?

Managers and testers want to choose the topic branches they will be including into the next release, and they don't make that decision until just before they ask the build manager to start creating the build. This gitweb interface lets them see the topics that are ready for building, and make their selections.

The build manager can then sweep the entire "heads/test/approved/" directory and merge everything not already merged into the current branch. Of course if a merge fails, or a compile fails, the build manager stops and throws the mess back at the development team.

Bad merges or build failures happen less often than you might expect, as we do have fairly good isolation between our topic branches. During some periods of the year we don't think twice about using the octopus driver to merge topics, and will merge 30+ topics at a clip in just a minute or two, because they are all unrelated and isolated changes that management has asked to go into a single release.

Most of the above code is actually fairly well isolated in gitweb.cgi. It turns out it was quite easy to add what I needed, and to reuse a lot of the existing code. I'll probably be able to clean it up well enough to submit a patch. Might take a few weeks.