Julian Foad wrote:
> Hardening before being safe to use:
> * Help text should contain a short introduction to how to use; set the
> user's expectations; state the limitations (see "Extensions / Not
> Supported Initially" section  in design doc.).
> * Output should be verbose and clear about what is happening.
> * The prototype should not delete patch files when unshelving, in case
> it goes wrong; instead rename/move them.
Now instead of deleting it renames to NAME.patch.bak (overwriting any
> * Must handle unsupported scenarios gracefully (e.g. kinds of changes
> that we can't yet save and restore in a patch file).
> * If applying a patch fails in any way, or produces conflicts, it
> should notify the user and keep the patch (moved somewhere is OK).
> * When 'unshelve' would touch an already modified file, consider
> aborting instead of patching. Maybe only patch it if '--force' given.
> Some easy UI improvements for a better first impression:
> * Let 'unshelve' choose the most recent shelved patch by default (like
> 'git stash pop' does).
> * Let 'shelve' default to 'this working directory' and an automatic
> name, so that command-line arguments are not required.
http://svn.apache.org/r1806614 (default to this working directory)
> * Tidy up the '--list' output. e.g. show age as minutes/hours/days;
> remove file size in bytes.
http://svn.apache.org/r1806618 (sort by date)
Received on 2017-08-31 10:47:47 CEST