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

[Harald Meland]

[Thomas Lord]

> As long as hooks are created for points during commands that are well
> defined as part of Arch-in-the-abstract rather than points during
> computations which exist only as artifacts of a particular
> implementation there should be little cost to adding and maintaining
> them.

Sure -- you're the one who ought to know which "points during commands
that are well defined as part of Arch-in-the-abstract"; I'm only
guessing. :-)

> But really, tla should do every reasonable thing it can to encourage
> people to invent and implement "higher level" revision control
> policies and procedures, using arch just as the low-level primitives
> for implementing the higher level operations.   Liberal sprinklings of
> hooks, just so long as they have a well-defined and stable meaning, is
> not a bad idea, especially if new hooks are added "on demand" rather
> than just trying to hunt arround and anticipate where people will
> actually want them.   No?

Even with well-defined and stable meaning, liberal sprinklings of
hooks are likely to complicate debugging-by-mailinglist from time to
time.

Maybe tla should grow a mechanism for being more verbose about when it
invokes hooks, what parameters the hook is invoked with, and maybe
even how long the hook takes to execute?  Of course, this could be
done in ~/.arch-params/hook, but would then have to be implemented in
whatever language the hook script is written in.

> I think Matthieu's point was that if I was going to reject a
> commit-start hook because it could be done with:
>
>       % run-hook && tla commit
>
> then i ought to have rejected a post-commit hook because it can be
> done with:
>
>       % tla commit && run-hook

Well, yeah, but I *use* the post-commit hook. ;-)
-- 
Harald