Labels: lifecycle/rotten
Kind of like how it works in GitHub where you can references an issue # (or maybe short hash, but a number would be easier to remember) in a commit message and that reference displays a link/reference in the issue timeline (and closes the issue if you put something like Closes #1?).
Reference bugs in commit messages to Reference bugs in commit messages
We can't have numbers (see https://github.com/MichaelMure/git-bug/blob/master/doc/model.md#you-cant-have-a-simple-consecutive-index-for-your-bugs) but we can use the shorter hash.
The tricky part is that git-bug is entirely decoupled from the normal code workflow (by design). Having this kind of feature would require git-bug to track changes in the normal branches and edit bugs accordingly.
Maybe git-bug could install a hook to spy on the normal workflow and trigger these changes ? The problem is that every single commiter of the repo would need to have git-bug installed or some of these events would be missed.
Ah, of course, that makes sense. I'll dig more into the documentation.
Installing a commit hook sounds like a good idea to me. I'm okay with some of these events being missed if contributors don't have git-bug installed because I feel like even if teams don't buy into this fully, it would still be helpful to those on the team that are using it (especially if conveniences are added like the automatic bug closing feature I mentioned).
This opens up the opportunity for a lot of features though and it's probably a good idea to think about an extension/plugin system early on so that the project is less burdensome to maintain. Personally, I am really excited about the idea of using a git-bug extension to generate a CHANGELOG because I think it would be a lot smoother than alternatives like commitizen.
This could be both a git hook to "notify" git-bug of the commit-message, and git-bug could also be automatically at startup check whether all commit messages have already been parsed, and then apply the "actions" starting from the oldest "unseen" commit
I'm very interested in such feature. First let me introduce myself a little bit. I'm working for an Aerospace Company and have 15 years background in industrial and critical software engineering. So to master changes with such software we have two strong requirement for the configuration management:
This is required for validation and understand why the software behave unexpectedly: did we really the change as we planned? Did we break something by making the change? Concretely for most SCM we used, we simply insert the issue number in the commit message and we have implemented hooks to make such reference mandatory. Currently more and more projects are managed using the atlassian suite and Jira+Fisheye provide the traceability storage and navigation interface by processiong the commit messages. This provide the expected feature to users but requires quite huge infrastructure and potential out-of-sync issues. It's a pity to rely on additional relational database to manage issues and traceability to change when we already have with the SCM a convenient storage system able to track change on items. So git-bug seems to me a must cleaver way of doing a have good potential to do this job well. Anyway it shell become soon much better than my own attempt to do something similar with subversion. See:
I made a little experiment yesterday to hack the prepare-commit-msg in my own git local repository and it is already enough to help me fill my commit messages. prepare-commit-msg.txt
It fills the message with the issue number already set with git bug select <xxxxxx> or set comment with the list of open issue to ease to pick on (my comment char is configured to ';' to let me use hash for the issue number).
Then I just need a browser to follow links from commits to issues and from issues to change sets. So may be it's more a termui or webui issue than anything else related to the data model of git-bug.
@seeduvax on a related note, I would very much like to have a global flag like --enc=json to change the behavior of commands to output a format easier to use for scripting tools, may it be JSON or something else. You would not need to use sed or have scripts break each time the formatting change.
Yes you're right. It is now so common to me to play with sed I even didn't check there was any option to extract the only information I need! A few additional flags for the show command can also be helpful to fetch a few particular fields.
If some kind of integration were built in that would be nice, but I would be slightly concerned about configuration complexity if the integration between commit messages and bugs were entirely automatic (what if bugs are in a separate repo, what if a bug repo tracks more than one code repo, what if the local repository includes commits that close bugs which aren't pushed to the canonical repository, etc). Personally, I would prefer something more modular. Here is a python program I'm using to close bugs based on commit messages. I supposed one could add it as a post-merge to do this automatically which would complete the integration I think. I choose to do this manually for now.
The program assumes a rebase workflow, so you might need to adapt it if you use a merge workflow.
Example commit message:
[json] Delete old streaming API, cleanup some of the new code
* Use SerializeOpts inside StreamDumper to pretty-print (ish)
* convert json_gen to generate code for the new registry-based
streaming API and update stream_gen_test to use it
* change stream_macros.h to generate code for the new registry-based
streaming API and update stream_test to use it.
* add kCompactOpts to json.h/cc (for unpretty-printing)
* add documentation for the new streaming API and some general docs
* delete old streaming API
Change-Id: I490b08fa3520ba51704fa2507e3230dcb68f4eb3
Closes: 0b8adce 1941a38 6da4db9 704ae96 ab101b1 bab7e6d d0f291f
ecbaf88 f6f98d4
Example execution:
josh@cookie:/data/deleteme/coderepo$ python -B /tmp/close_git_bugs.py --log-level info -g ../bugrepo
[INFO] Closing 0b8adce
[INFO] Closing 1941a38
[INFO] Closing 6da4db9
[INFO] Closing 704ae96
[INFO] Closing ab101b1
[INFO] Closing bab7e6d
[INFO] Closing d0f291f
[INFO] Closing 0f7c7c3
[INFO] Closing 12fc493
[INFO] Closing 5fa508d
[INFO] Closing 71ac52e
[INFO] Closing 92c0d89
[INFO] Closing cda90c0
sudoforge removed label lifecycle/dormant