RFC: Fix for issue 1827 (v2)

[Sune Foldager]

On 16-02-2010 02:43, Greg Ward wrote:
> On Mon, Feb 15, 2010 at 6:46 PM, Benoit Boissinot
> <benoit.boissinot at ens-lyon.org> wrote:
>> I see. So we assume nobody who calls commitctx() directly assumes hooks
>> will be fired?
> 
> Eeek.  I for one don't currently rely on this property, but IMHO it's
> a good one that's worth keeping.  Calling all commit-related hooks
> from the same level feels deeply right to me.

Sure, but commitctx could also be considered internal... the uses I
found were hgext's overriding it do do some more stuff. They didn't rely
on hooks.

>> Do we want to keep some sort of symmetry and move precommit up too?
> 
> I vote conservative here: keep calling the hooks from commitctx().  If
> that means pain moving wlock stuff around, so be it.  (Well, depending
> on the degree of pain... ;-)

I don't think we can do that, short of merging the two functions more or
less completely. Moving the precommit hook up can't be done, since we
need data which is only made available during commitctx's execution
(i.e. 'ret') :-/.

/Sune