[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Harald Meland
Subject: Re: [Gnu-arch-users] Re: Having two precommit hooks
Date: Mon, 11 Oct 2004 12:20:37 +0200
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

[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

>    (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]