Re: [PATCH] Contribute a fairly paranoid update hook

["Shawn O. Pearce" <spearce@spearce.org>]

Jakub Narebski <jnareb@gmail.com> wrote:
> Shawn O. Pearce wrote:
> 
> > I also recently hacked some semi-useful features into gitweb.cgi.
...
> If I can ask: what features? 

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.

-- 
Shawn.