The most successful company I worked for used two systems. There was an "external" user-friendly one, where customers could file issues and track changes and tie them back to contractual requirements and such, and there was an "internal" developer-friendly one, where programmers could talk about what line of the source code forgot to add one and which changeset hash introduced the bug.
Our partners wanted to file issues at the level of "I need to have some way to be able to do XYZ", and they shouldn't have visibility into source code and programmer assignments and internal roadmaps. Our programmers broke these into "Write a function to do X()" and "Add a database table for Y" and "Z.c crashes when you leave the title field blank", and they shouldn't be exposed to customer data that was part of the request.
It worked tremendously well, and I'm surprised this split approach isn't more popular. git-bug looks like it could be a great solution for the internal one.
[1] https://en.wikipedia.org/wiki/IBM_Configuration_Management_V...
The population you desire to be able to update tickets is... shall we say, "larger" ? ;) than the population you desire to be able to update code.
For any project where the bug-updaters and the code-updaters are plausibly the same set, this could be a useful thing.
But even for modest projects I'm doing for customers, it'd be awkward.
I also think the type of data your bug-updaters or bug-reporters would generate would be very different. Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
My kneejerk is that the bug metadata is a different _kind_ of data than the source, and trying to shoehorn them into the same container will be stuffy in most cases.
A really good point. I'd say you should use something like this for internal bug tracking, and link to external bug reports instead.
Whether you accept an external bug report as an actual bug is a question in itself, which should be dealt with beforehand. I'd say this is good for notetaking for the team and for seeing which bugs are resolved in which version.
Yes! It's much better than having them linked from some image hoster that inevitably goes belly-up at some point.
The problem of not necessarily wanting to pull them after they've been lying around for 10 years can also be solved, see git-lfs.
I don't see your point about the permission model.
You will have access permission for the code as you normally do for your git remote as well as an extra user for the web UI that will store bug edits as one of the "public" user with whatever external authentication system you want.
There's a whole bunch of ways to handle large files in git nowadays without bloating the size of the repo. Hopefully the distributed bug tracker would work with those...
That said, as a developer I'd love it if I could track my more technical thoughts & needs without having to go to my enterprise tools where BA's run wild & confused. The trade-off of course being more dissonance and potentially a failure to advocate for this work in planning, unless you synchronize data somehow.