[RFC] Hook for branch nicknames?

[Martin Pool]

I think adding a hook for this would be reasonable.  Aaron is right
that you can always monkey patch it, but I think it is useful to have
a bit more structure and a bit more of a guarantee the interface will
be stable.

> My concern is when bzr-colo or another plugin registers a different
> hook for 'automatic_nick', then Branch.hooks['automatic_nick'] is now
> a list of two or more possibilities.  Should we always use the first
> hook in that list (presumably the most recently registered)?  Is there
> a way to use the hook infrastructure for situations where we wish to
> override behavior?  In bzr-colo's hook I can thunk back to the default
> hook explicitly by name, but that doesn't seem to be right because the
> order in which plugins are loaded seems fairly arbitrary.  I know that
> we have had similar problems with command overrides, but with such an
> extensible infrastructure as ours, I'm not sure how this ought to
> work.  Can I get some feedback on the appropriate design for such an
> idea?

Splitting out the default implementation, so it can still be reached,
sounds good.

How to cope with multiple hooks really depends on what we think the
situation might be like when several are registered.  Possibly they
want to decorate each other (though then the order matters), or
possibly some hooks only have an opinion about some branches and want
to return None for no opinion.  We don't have a concept of controlling
the order.  I am not sure how that ought to be controlled.

In the lack of any opinion just having a hook that can't be stacked is
probably better than none at all.

m