issue: update issues

1 files changed, 8 insertions, 44 deletions

diff --git a/app/Main.hs b/app/Main.hs
index 1b06a0d..ebba131 100644
--- a/app/Main.hs
+++ b/app/Main.hs
@@ -155,8 +155,9 @@
 -- # @id some-title
 -- ```
 --
--- @topic ids
 -- @backlog
+-- @depends-on add-anissue-lint
+-- @topic ids
 --
 -- COMMENT Can you elaborate on why this would be useful? I am expecting us to
 -- do some renaming detection regarding provenance. After that, will it be
@@ -230,6 +231,9 @@
 --
 -- @topic dependencies
 -- @backlog
+--
+-- COMMENT I suggest first adding a command `anissue tree @blocker` which
+-- generates the suggested forest of issues.
 
 -- TODO Display issue type in list and show views
 --
@@ -266,47 +270,6 @@
 -- allow that). The first marker should have priority in case we have to pick
 -- one.
 
--- TODO Add command for (re)generating the cache
---
--- When running `anissue cache generate`, we will only generated the
--- issue cache, starting from the initial commit.  This will not
--- re-generate already existing cache entries.  To delete the old cache
--- first, one has to add `--clean`.
---
--- By adding `--first-commit <commit-hash>` the cache will only
--- generated starting at the specified commit.
---
--- By adding `--full` the cache will be generated for **all** commits in
--- the repository.
---
--- When running `anissue cache clean`, the local cache will be deleted.
---
--- @topic options
--- @topic cache
--- @backlog
---
--- COMMENT What is the point of this command? Can't caches be handled
--- transparently to the user?
---
--- COMMENT Hm, I think I don't exactly know, what you mean by
--- transparently. ':)  So cache invalidation would be like how e.g. elm
--- does it with the elm-stuff folder?
---
--- The idea for the cache generation command could be e.g. used in
--- environment setup scripts.  And then the first-commit option would
--- make it possible to use very old repostories without a too long
--- initial delay.
---
--- COMMENT The caching works *transparently* for the user if the user is not
--- aware of the cache at all. If there are cache commands (or options), then it
--- is not transparent.
---
--- I get that we want to limit provenance generation somewhat, and that will
--- have to be solved in an intransparent manner.. but I am not fully
--- understanding the proposal.
---
--- Maybe you could walk me through it in our next session?
-
 -- TODO Add global option for specifying first considered commit
 --
 -- Every command offers the option `--first-commit <commit-hash>`, which
@@ -315,9 +278,10 @@
 -- this will also happen when the provided commit is not in the history
 -- of HEAD.
 --
--- @topic options
--- @topic cache
 -- @backlog
+-- @depends-on compute-history-from-the-top
+-- @topic cache
+-- @topic options
 
 -- TODO Add format option (Text, JSON, ...)
 --