Matthias Beyer wrote: > Why is this software so special? Because it uses an alternative approach to > issue tracking in git: We do _not_ check files into the repository, but use > the > git plumbing functionality to create empty commits (empty as in "no patch > involved") for the issue messages. > > [1]: https://github.com/neithernut/git-dit
Using empty commits for this is an interesting, and AFAIK novel idea. Can the empty commits be made to eg the master git branch? The man page seems to say so, but other documentation talks about refs/dit/<issue-hash>/head branches. I em envisioning this workflow: * There's a bug in master, so I use git-dit to add an empty commit to master describing the bug. * I push my changes to origin. I may not be able to normally push changes to origin/master, but since no files in the tree are changed, a hook allows the push. * A new version is released, unfortunately it does not fix my bug. It gets shipped by some distributions. * The maintainer creates a bugfix branch and fixes my bug in there, or so they think. They use git-dit to mark it as probably fixed. * I can pull that branch, test that it fixes the bug, use git-dit to close the bug, and push to origin/bugfix. * The maintainer merges bugfix into master, and so git-dit can tell us that the bug is fixed there. * git-dit can also tell is that the bug is still open in the version that was released after I filed the bug report. BTW, your use of messages that correspond to emails reminds me of Lars Wirzenius's http://distix.eu/ , which actually integrates with email and stores the data in git as text files in a branch. I feel that there might be an opportunity to combine the two. -- see shy jo
signature.asc
Description: PGP signature
_______________________________________________ dist-bugs mailing list [email protected] https://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
