Re: [Gnu-arch-users] Re: Having two precommit hooks

[Harald Meland]

[Matthieu Moy]

> Thomas Lord <address@hidden> writes:
>
>> I can't imagine not wanting to re-run tree-lint after a tree-modifying
>> hook ran.  What's wrong with (in essense):
>>
>>
>>      #!/bin/sh
>>
>>         tla tree-lint
>>         run-hook
>>         tla commit
>
> This will work when you call it, off course, but this seems to me to
> be a dangerous solution if the correctness of your archive really
> depends on "run-hook":
>
> 1) It is easy to forget about the wrapper script, and run "tla commit"
>    by mistake.

If "the correctness of your archive" can be determined from a hook,
use tla's precommit hook to abort non-wrapped commits.

> 2) front-ends to xtla won't be aware of the the wrapper script, and
>    will run "tla commit" anyway.

These will then also be aborted by tla's precommit hook.

>    For someone using, say, sometimes xtla and sometimes fai, this
>    requires a painfull customization.

Sure.  I think this is a natural consequence of using multiple
non-cooperating tools: keeping customization consistent will be more
painful.

>    (currently, xtla has no precommit hook, so, the user will have to
>    write some elisp to achieve that)

... or override tla-tla-executable to point to their wrapper script.

> So, your solution works, but I think this is much simpler and safer
> for the user to have a pre-precommit hook.

I think that increasing the number of hooks in tla (for no other
reason than perceived convenience) will make it *harder* to learn, and
hence not at all "simpler".  And, as the current precommit hook can be
used to abort non-conforming commits, I'm unconvinced of the "safer"
part as well.

> By the way, is there a particular reason why there's a post-commit
> hook ?

At least automatic near-instant updating of mirrors and post-commit
email notifications comes to mind.
-- 
Harald