[Top][All Lists]

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

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

From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: give us a hand with arch
Date: Sat, 27 Sep 2003 09:47:26 -0700 (PDT)

    > 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 
    > 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 
    > return code from arch_run_hook() that allows you to return an error code 
    > aborts the commit operation.  Pass at least the log file name to the 
    > 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".


reply via email to

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