-The TODO list for the short term:
+The TODO list before 1.0:
-- tag (snapshot) command
-- log command (it should also show the log per single patch)
-- clone command
-- import command to import a series of patches or a single patch or a
- patch from a different branch in the same tree
-- better help for commands
-- tutorial
-- bug reporting tool
+- more regression tests
+- Convert the remaining commands to the new infrastructure.
-Other things after the list above is completed:
+- 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.
-- fold command (to merge 2 patches into one)
-- regression tests
- release 1.0
-The future, when time allows or someone else does it:
+The future, when time allows or if someone else does them:
-- patches command to show the patches modifying a file
- patch dependency tracking
- multiple heads in a patch - useful for forking a patch,
synchronising with other patches (diff format or in other
repositories)
-- remove the old base of the patch if there are no references to it
-- write bash-completion script for the StGIT commands
+- numeric shortcuts for naming patches near top (eg. +1, -2)
+- (config?) parameter for number of patches included by "series -s"