title: Using hooks vs. wrapping commands in mercurial
body: <p>What are the relative pros and cons for using hooks vs. using an extension that wraps a command for a particular task?</p>
  
  <p>In other words, what are the criteria for deciding whether to use hooks or wrap a command?</p>
  
  <p>Please also list the cases where one approach is the only option. One case I can think of is to add new arguments for existing commands. You could also change/remove arguments, for example I default <code>log</code> to <code>log -g</code> but <code>graphlog</code> aborts in the presence of some "incompatible" arguments (see <code>graphlog.check_unsupported_flags</code>), so I added a <code>log</code> wrapper to remove <code>-g</code> in those cases, because forced abortion is a crime against humanity.</p>
  
  <p>It feels like hooks are more clean-cut. Python hooks run in the hg process so there's no performance issue. And while it's easy to use <code>extensions.wrapcommand</code> to create command wrappers, it's trivial to create/disable hooks, and to adjust the order in which they are applied (they should be self-contained in the first place).</p>
  
  <p>And here's a quote from <a href="http://www.selenic.com/mercurial/hgrc.5.html#hooks" rel="nofollow">hgrc doc</a> that recommends standard hooks over pre/post command hooks, but it also applies to hooks over wrapper:</p>
  
  <blockquote>
    <p>... hooks like "commit" will be called in all contexts that generate a commit (e.g. tag) and not just the commit command.</p>
  </blockquote>
  
  <p>Also I guess that hooks are not subjected to GPL (or are they?), whereas command wrappers in <a href="http://mercurial.selenic.com/wiki/License#What_is_a_.22derived_work.22.3F_Is_an_extension_a_derived_work.3F" rel="nofollow">extensions are</a>.</p>
  
  <p>(I hope a 1.5k+ user can create a <code>mercurialhooks</code> tag. Git fan boys have beaten us with <code>githooks</code>.)</p>