Information
Having a good method of tracking what's finished and what needs to be done is crucial once a project grows large enough. Of course, for team-driven development having a full-featured issue tracker such as GitHub or similar is preferable, but for solo-developers GitHub can feel like an over-engineered solution to a simple problem.
My goal with Glida was to create an opinionated issue tracker that is portable between machines and requires no setup, configuration files, special folders, or a specific development environment.
(The name "Glida" is derived from the swedish saying "bra koll" - if someone is living their life with structure and purpose, a swedish person may say they have "bra koll".)
The idea for this project was inspired directly by this video.
Install
Usage
Adding a new issue
The core philosophy of Glida is that issues are opened, closed and edited inside the codebase itself. Issues live in the codebase and are not dependent on an internet-connection, or you having to pay a subscription fee at the end of every month. When you want to add something to your issue list you simply type it out in your project, perhaps next to relevant code (tip: create a snippet for this; for example "issue").
// *glida - d: fix typo in debug print, p: 10, t: debug, s: closed
- d: description of the issue (obligatory)
- p: priority from 0 to infinity where the highest number takes priority (optional - fallback: 0)
- t: tag (optional - fallback: n/a)
- s: status [ (op)en | (pr)ogress | (cl)osed ] (optional - fallback: open)
The status value can also take abbreviations (op, pr & cl).
[!IMPORTANT]
- An issue line is any line containing the prefix "*glida".
- Everything before the prefix on an issue line is ignored by the parser.
- Everything after the prefix is parsed as metadata.
- Multiple tags are not supported - this is by design, to force clarity when opening issues!
Workflow integration
Here's a way to integrate Glida into your neovim config using luasnip:
local ls = require
local s = ls.
local t = ls.
local i = ls.
return
Here's a way to integrate Glida into git using a bash alias:
My development workflow with Glida looks like this:
- Create a new issue within the codebase.
- When I want to work on the issue, I set its status to "in progress" either directly in the code or through the CLI.
- Finish working on the issue.
- Run command
glida(with relevant filter flags if necessary) to find its id number. - Run bash script
commit <id>to close the issue and commit it to git. - Run command
glida summaryevery once in a while to track my progress. - Rinse and repeat.
Subcommands and flags
All the issues listed, sorted by priority and status (the current directory is scanned recursively by default):
glida
An optional target path can be added (works alongside other flags):
glida <relative path>
Filter issues by tag:
glida -t <tag>
Filter issues by status:
glida -s <status>
Filter issues by description:
glida -d <keyword>
Limit scan to shallow depth (i.e. no recursion):
glida -r
Summary of all issues:
glida summary
Copy issue details to clipboard with formatting: "tag (file:line): desc".
This is to reduce the friction of writing git commit messages manually.
glida copy <id>
glida cp <id>
Close issue through CLI:
glida closed <id>
glida close <id>
glida cl <id>
Open issue through CLI:
glida open <id>
glida op <id>
Progress issue through CLI:
glida prog <id>
glida pr <id>
glida progress <id>
Display help and version information:
glida help
License
This project is licensed under the MIT License.