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

[Thomas Lord]

    > From: Harald Meland <address@hidden>

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

Well, yeah, to the degree that most users need to know about and use
them.   But I don't see that as being the case yet.

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.

I'm sort of whith you -- you saw my initial reaction was against a
commit-starting hook just on general k.i.s.s. principles.   

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?

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

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

-t