files, loosely similar to https://github.com/driusan/PoormanIssueTracker,
from which I borrowed idea of replacing spaces with dashes in issue names.
-Issues are kept in the issues/ directory. Each issue can be a part of
-projects hierarchy: main-project/sub-proj/issue-name. Directory's name
-is the issue's brief name. Dashes should be interpreted as spaces and
-n > 1 dashes should be interpreted as n-1 dashes when converting the
-directory name to a human readable issue title, as PoormanIssueTracker
-suggests. The "about" file contains the description of the issue. The
-"result" (initially empty) contains the closed issue resolution
-information.
-
-The "created" issue's file contains the datetime it was created. It is
-used to help sort issues by date. Unfortunately Git does not keep and
-restore mtimes, which would probably eliminate the need of separate
-files with the timestamps.
+Issues are kept in the issues/ directory. Directory's name is the
+issue's brief name, prepended with datetime for sorting purposes. Dashes
+should be interpreted as spaces and n > 1 dashes should be interpreted
+as n-1 dashes when converting the directory name to a human readable
+issue title, as PoormanIssueTracker suggests. The "about" file contains
+the description of the issue. The "result" (initially empty) contains
+the closed issue resolution information.
Each issue can have attached tags. For keeping their set in consistent
well-defined state, the tags/ directory above the issues/ contains
issues in done state? for i (issues/**/tags/status:done) print $i:h:h.
This kind of information are all just enumerations.
+Project's name is expected to be "proj:NAME" tag for example.
+
The deps/ subdirectory in each issue can contain symbolic links to
another issues, referencing it. Create another kind of links between
them as you wish.
the issue. By committing it you automatically accompany it with your
(commit's author) name and the time it was added.
- $ cat > issues/issues-name/comment <<EOF
+ $ cat >issues/issues-name/comment <<EOF
Here are my thoughts:
* bla bla bla
EOF
$ hash -d s=~/work/schwabrak
$ cd my/issues
- $ ~s/add proj/issue name to create
+ $ ~s/add issue name to create
-To ease the creation of the new issue's directory structure, you can
-use "add" command as seen above. And yes, it is intended that
-"proj/issue" and "name", "to", "create" can be passed as separate
-arguments, but proj/issue-name-to-create will be created as expected.
+To ease the creation of the new issue's directory structure, you can use
+"add" command as seen above. And yes, it is intended that "issue" and
+"name", "to", "create" can be passed as separate arguments, but
+proj/issue-name-to-create will be created as expected.
All utilities strip off possible "issues/" prefix from the issues
name, so you can easily complete issue names with something like fzf.
"tag-add issue [tags/]tag" adds a tag, as was noticed before.
"dep-add issue-dst issue-src" will link issue-src in issues-dst's deps/.
"show issue" shows most of issue's information in human friendly way.
+"comment" allows you to conveniently add comment.
comment-list, recfile-export and recfile-export-all produces
recutils'es compatible recfile output, which is machine friendlier.