Feature Request: Support issue dependencies in `bit issue`

[toshiki-higa]

Thank you very much for building such a wonderful tool.

Feature Request

bit issue already covers local issues, parent/child trees, issue/PR links, and metadata sync. It would be very useful to also support a minimal GitHub-style dependency model: blocked by / blocking.

I do not have strong opinions about the exact CLI or UX. The examples below are only meant to illustrate the kind of workflow I have in mind, loosely inspired by beads. See https://github.com/gastownhall/beads.

Suggested commands:

• bit issue dep add <blocked-issue-id> <blocking-issue-id>
• bit issue dep remove <blocked-issue-id> <blocking-issue-id>
• bit issue dep list <issue-id>

Example:

• bit issue dep add 12 7
• meaning: issue 12 is blocked by issue 7
• meaning: issue 7 blocks issue 12

But,

Motivation

I would like to fully migrate from beads to bit for day-to-day issue management.

At the moment, one of the main missing pieces for that migration is a lightweight way to express issue dependencies such as blocked by / blocking.

What I like about bit is its simple, local GitHub-style issue/PR mental model. I do not want a full task-graph or workflow engine here. However, having minimal dependency management would cover an important use case that I currently rely on in beads, and would make it much easier to use bit as my primary tool.

More specifically, I would like to manage issues as a coarse-grained DAG, where parent/child expresses hierarchy and blocked by / blocking expresses execution order between issues.

In short, this feature would help make bit a practical replacement for beads in my workflow, while still keeping bit simple.

Why this helps

• expresses coarse execution order between issues
• makes it possible to manage issues as a lightweight DAG
• keeps the mental model simple and GitHub-style, similar to issues/PRs

See also:
https://docs.github.com/ja/issues/tracking-your-work-with-issues/using-issues/creating-issue-dependencies

I think this would be a very natural complement to the existing parent/child hierarchy.