-The TODO list until 1.0:
-
-- patch revisions support (including a log command)
-- better handling of file renaming
-- use same configuration file as GIT
-- debian package support
-- man page
-- code execution allowed from templates
+The TODO list before 1.0:
+
- more regression tests
-- stg help should probably pipe through the $PAGER
+
+- Convert the remaining commands to the new infrastructure.
+
+- Go through the design of the UI and make sure there's nothing hard
+ to change in there that we'll regret later.
+
+- Write a user guide. I'm thinking a document on the order of 10-30
+ pages that'll explain why one would want to use StGit, and how.
+
+- Make sure the rest of the documentation is in good shape.
+
+- use a separate index for some commands (refresh, fold etc.) so that
+ files already added/removed are not automatically checked in
+
+ + This is easily done with the new infrastructure. refresh now
+ uses a separate index when appropriate. fold has not yet been
+ converted.
+
- release 1.0
-The future, when time allows or if someone else does it:
+The future, when time allows or if someone else does them:
- patch dependency tracking
- multiple heads in a patch - useful for forking a patch,
synchronising with other patches (diff format or in other
repositories)
-- write bash-completion script for the StGIT commands
-- support for branches with / in names
- (ml: "Handle branch names with slashes")
-- "pull" argument should default to a sane value, "origin" is wrong in
- many cases
-
-Bugs:
-
-- the following commands break in subdirs:
- - refresh (ml: "Running StGIT in subdirectories")
-- "stg show" on empty patch shows previous patch
-- "stg add" is accepted when no patch is applied, then any push says
- one must refresh first, which is obviously wrong
-- "stg add" on files already added should print a notice, so that the
- user can catch a possible typo
+- numeric shortcuts for naming patches near top (eg. +1, -2)
+- (config?) parameter for number of patches included by "series -s"