Re: [Gnu-arch-users] Re: give us a hand with arch

[Tom Lord]

    > From: "Mark A. Flacy" <address@hidden>

    > I'm afraid that it's unclear to me how an option to a commit-like command
    > is more user-friendly to a differently named commit-like command that
    > invokes an editor.  On second thought, don't answer that; I don't really
    > want to see a thread spin off on that topic.  You're the architect and
    > that's your decision to make.

(The option is only needed when combining other options that can
specify all or part of a log message with the user's desire to fire up
the editor anyway.)


    > Tom>    So it doesn't seem to ridiculous to me to add an
    > Tom>    `arch_ensure_log_is_ready()' function and call that in the
    > Tom>    `main'-like functions that implement several commands.  It will 
fit
    > Tom>    in with the existing argument processing very nicely; it has 0
    > Tom>    impact on any of the core functionality; it provides the desired
    > Tom>    features; it avoids the drawbacks illustrated by walters' script.

    > You could also add a pre-commit hook to ~/.arch-params/hook that checks 
the
    > return code from arch_run_hook() that allows you to return an error code 
that
    > aborts the commit operation.  Pass at least the log file name to the 
hook[1],
    > and Bob's your uncle.

    > (Somebody's going to want that functionality anyways.  Almost any
    > commercial shop will.)

That's true but mostly beside the point -- wouldn't such a hook be
more for some form of acceptance testing than for log editting?

The issue that's unique to log editting is that, generally, the exit
status of the editor is not determined in a way that allows a user to
use that status to signal the intention "never mind".

-t