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 [1] in design doc.).
Done. http://svn.apache.org/r1806552 > * Output should be verbose and clear about what is happening. http://svn.apache.org/r1806587 ... > * The prototype should not delete patch files when unshelving, in case > it goes wrong; instead rename/move them. Done. http://svn.apache.org/r1806583 Now instead of deleting it renames to NAME.patch.bak (overwriting any previous .bak). > * 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). Done. http://svn.apache.org/r1806619 > * 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) ... - Julian
