Dear everybody,

We are just starting to use git-bug. It's really awesome. I'd like to request a new feature:

support hooks for comment and title messages

git has a lot of hooks. Among them, there is the commit-msg hook that one can use to audit/verify COMMIT_EDITMSG.

For example, commitlint provides a very convenient and standardized commit message rule set and helps improve the commit message quality for many projects such as Angular.

I'd like to be able to have the option to enforce commit message rules as I could with commit-msg hooks in vanilla git.

Thanks a lot for your work and attention.

Zhongming

Interesting idea :-)

The underlying question is, should we be able to configure the bug tracker for a project. Another example would be to define a set of valid labels.

Out of curiosity, how are you using git-bug ?

Hi,

Apology for the late reply.

Thanks for the questions. Please allow me to start with our situation with git-bug:

I am imagining git-bug to become the source of truth for bug/track/issue threads and communications internally at our company.

Moreover, I found the idea of storing text-based information as git objects particular interesting in use cases where close interaction with git commits/branches/tags is required. This could include gerrit, git-bug, jenkins, kubernetes, etc. (details omitted for brevity, would like to expatiate upon request).

Currently two main blockers with going all-in with git-bug:

1. Lack of formatting and linting tools such as formatters, linters, and templates. Otherwise we have no guarantee
2. git-bug commits got garbage collected on GitHub. We host our own internal git server. Either way, there has to be some level of support from the server side to correctly identify commit objects managed by git-bug and not to delete them.

I like the idea of using command line + git objects to share and track bugs and issues. As of this writing, we are ready to use git-bug (already secretly deployed to every developer's desktop under $PATH), provided that the above two issues are resolved.

git-bug commits got garbage collected on GitHub

Could you detail that ?

I like the idea of using command line + git objects to share and track bugs and issues. As of this writing, we are ready to use git-bug (already secretly deployed to every developer's desktop under $PATH), provided that the above two issues are resolved.

Haha, this is awesome. That said, please be careful as it will be most likely more incompatible changes in the data model before git-bug reach version 1.0 (mainly https://github.com/MichaelMure/git-bug/issues/55).

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/rotten 11 months ago

github-actions (github-actions) removed label lifecycle/stale 11 months ago

sudoforge removed label lifecycle/dormant 7 months ago