- You should post this to the Git mailing list. We don't bite, and a lot of people would be interested in the details of how it works there.
- If you haven't you should check out git-annex. It solves an entirely different problem, but much of the distributed custom merging of histories, using git for ad-hoc metadata etc. is the same problem you're solving.
- You should be aware if you aren't that the design of having a ref per bug has some drawbacks, some operations in git are O(n) the number of refs.
- It would be really interesting to see some write-up on how the format you're using compares to the format Fossil uses for its bugs. I think some of what Fossil does wouldn't be possible to do in git due to its simpler data model, but still, such a comparison would be educational.
I have always wanted something like this without having to move away from Git (to Fossil).
A bug tracker like this allows the bug history to be tracked and remain with the source code which is much better than keeping the bugs in a web based service because every 5 years you need to migrate it (Bugzilla to Trac to JIRA) and in every migration, some context or formatting is lost.
For something like this to be successful in enterprises, the tool should be management-friendly. Right now JIRA leads because it allows management to pull pretty reports out of it. Is there anything planned in git-bug to appease these management type people so that it has a good chance of taking off in the enterprise world too?
Are there any active Fossil instances available for free/open source projects? I found Chisel, but am not sure whether many of the projects are active.
Also, the design of Fossil and Chisel is s bit difficult to read on mobile.
If you click through Chisel you can find a few active projects. You're right about discoverability though; It's not great.
Fossil's neat because it really tries hard to be decentralized. Because of that the repo is really all you need. Hosting isn't so important when code, bugs, forums, and wiki can be moved by copying one file. The downside is that there's no FossilHub with thousands of projects using similar UIs and conventions.
I think one issue is that it's really easy to set up a public Fossil instance. It takes about two minutes to get it running if you've got a web server with CGI support.
> Also, the design of Fossil and Chisel is s bit difficult to read on mobile.
That's just the default. You can easily change the CSS, though it would be nice if you could select from themes created by others, particularly to get one that's friendlier for mobile users.
mkdir Notes/
vim Notes/index.wiki
git add Notes/index.wiki
See ":help vimwiki-temporary-wiki" for details, but basically, it recognizes the Notes directory as the root of a wiki upon opening the file.
Since it's just tracked as a normal part of the repo, it gets branched and merged along with the code. So for example if I make an experiments branch, any wiki changes regarding the experiment won't sit around polluting the wiki if I decide to drop the branch. Similarly, any changes relevant to the branch I am working on get merged together along with the code merge.
One of the more interesting projects now a days is ForgeFed (https://github.com/forgefed/forgefed) which would allow for projects to use ActivityPub for pull requests, forking, etc.
This is important because so much of the value add of Github isn't in the git hosting (which one can do with Gitea or Gitlab) but in the collaboration.
This is also important because many Github extensions work through their API to glue functionality such as test suites and linting through monitoring a PR.
The problem with this approach is that usually your work computer is not reachable from internet, so ActivityPub won't work here. It might be used to create a federated GitHub though, but it's outside of the scope of git-bug for now. The project is just one month old ;)
I love this because I started building a small utility to help me consistently track issues inside my project files like tickets/{folders}/{file
}.md inside my projects, because I do not need an enterprise level management system, and I also really like the idea of tickets moving and closing as a part of merges, IMO it provides a better context when looking through history.
This is clearly more elegant, though it adds a new dependency, which is OK.
>I also really like the idea of tickets moving and closing as a part of merges
I really like that, too, I wish we'd track our requirements in git instead of having an IBM enterprise solution which is slow, has a terrible web interface and no ability to diff requirements properly.
The more information is versioned in the same system, the better the coherence of the information.
> I also really like the idea of tickets moving and closing as a part of merges
So does that mean that bug reports are tied to branches? (I.e. depending on which branch you've checked out, you see a different list of bugs?) I wouldn't like that idea at all because how would you keep track of bugs (and related discussions) across branches? (For instance, having 10 branches would imply that you suddenly have 10 versions of the same bug discussion, too.)
I see more value in it for clear technical tasks with technical descriptions, and not so much for discussions. Then proposals can be peer-reviewed before accepted as work that needs to be done (as a merge request to master, for example).
Then another problem that comes along with that, especially for golang users, is that your master branch is getting bombarded with issue updates, causing what looks like releases, when there's no effective change.
With the rise of static sites I'm not sure why something like this isn't much more common. Would love to see more options like this. Maybe eventually (not holding my breath) different git hosting providers will allow exporting to formats and importing to ticketing formats, so you can go from cloud to local instance or vice versa, or store tickets for mirror purposes.
Maybe someday git projects will have a /tickets folder or branch? Tickets per branch... hmmm... Maybe ignore the ones not in Master
Bugs are "retroactive" - you discover a bug, and then go on to determine the earliest point it was present.
Given that, I am looking for an extremely niche but vital feature: the ability to keep track of which branches a bug has been fixed in. Is this something git-bug can or does enable?
If you have the commit hash of the commit(s) introducing the bug, the it's a simple matter of seeing if that commit is an ancestor of any commit (or branch) you're interested in. Similarly, once fixed, it's just a matter of seeing if the fix is an ancestor of the interested branch/tag/commit. (Not saying that this tool couldn't or shouldn't, just simply that this should be very doable within git, I think.)
I imagine the most difficult part of this is just getting the data collected. Even with git-bisect, I very rarely find myself looking for the point of introduction, and instead just fixing the bug.
Not yet, but that might be a good feature. Also, the goal is to have an extensible data model where you can store whatever metadata you want to support arbitrary external bug tracker.
It would be nice to have a way to automatically update a bug's status when a commit claims to fix it. Presumably that could be done with a (server-side) hook.
It uses a dedicated "bugs" branch checked out to a .bugs directory in the current working directory. To use, copy it to a git repository which has a master branch and a remote for this master branch an run it.
Very bare-bones, but so far sufficient and without external dependencies (but probably lots of security problems…).
This looks great! I'll very much consider using it for my next project, if only for the warm feeling in the stomach that my bugs are close to the project itself. Huge kudos to the author.
The one thing that I'm not sure about is the separate `git bug push/pull` commands. I guess it makes sense, but I'd prefer ordinary `git pull/push/fetch/merge` to seamlessly handle syncing bugs around.
git-bug store the data in separate references that are not in `refs/head`, so they are not recognized as branches. This is meant to not pollute the normal code workflow.
git push/pull doesn't touch references outside of branches and git-bug has special code in the push/pull commands to merge bugs when needed.
`git gc` will also garbage collect any ref that isn't used by a current branch/tag (under refs/heads and refs/tags), the index (staging), originals from filter-branch (refs/originals), and reflogs.
The question isn't whether the data will be garbage collected, but how the active data AVOIDS being garbage collected - git gc only targets a pretty small amount of refs to preserve.
I'm not the author (he'll probably comment here in a sec), but if this is a problem, perhaps this project could become a patch to git itself.
I'd be fine running a patched git that knows about bugs. Of course, then I'd want to make it a little more generic, and not care whether I was dealing with an issue tracker, a wiki, etc.
You are wrong about the semantics of git-gc. It will consider for garbage collection all objects that are not referenced, and a reference is everything under refs/*, in addition to the other things you mentioned (index, reflogs etc.).
This is really nice. I think this would work really well as a GitLab integration i.e. Use GitLab's UI when online, but store the issues in your repository so it's available offline etc.
That's my main issue with GitLab, there is so much interesting innovation that they could do w.r.t. tooling but instead they play it safe by copying Github or providing integrated services that are already possible in Github.
I genuinely feel this is not the case. GitLab is so much more - it encompasses the full DevOps Lifecycle in a single application. If you haven't checked out our homepage recently, it might be interesting for you to rediscover what GitLab offers - https://about.gitlab.com/
Full disclosure: I work for GitLab, but what I stated above has nothing to do with the fact, it's how I personally see GitLab as a product.
> GitLab is so much more - it encompasses the full DevOps Lifecycle in a single application
That's what I meant by "integrated services already possible with Github". I guess you are familiar with Github Marketplace.
I don't mean to offend GitLab, it's a great service, I just mean that it could be much more if it worked on low level things too, like storage of issues as git objects, or federated instances. These are hard problems that won't make GitLab easy sell to a manager but definitely interesting things that would get developers attention.
We have some low-level stuff on our roadmap (e.g. federated Merge Requests [1], federated GitLab instances [2], cross-platform mentions [3] - i.e. mentioning GitHub users). These didn't get prioritized yet, but it's only a matter of time. We have limited resources so we have to prioritize and scope out releases in a such a way that it advances both our vision and satisfies customer requests.
A really interesting low-level component that we created and use in production is gitaly [4] (which is a git RPC component that aims to completely remove GitLab's dependency on NFS for repository access - and replace it with gitaly itself).
Honest question: how does it compare to bugs everywhere?
http://bugseverywhere.org/ has been around for a long time but services like GitHub and GitLab refuse to support its format, effectively blocking the adoption of the tool.
Bugs Everywhere:
- bug are stored as files alongside the normal code, which is different than the vast majorities of bug tracker operate, and also rely on git to merge properly the bug's files in a correct state. In git-bug, merge is simply rebasing commit, there is no conflict.
- last commit was in 2013
As far as I understand, the data model of git-bug is much closer than what github does internally. If you look at githug's API, you will find the same timeline of edit operation, so it might help them to pick up the idea.
Awesome for personal projects or those startups with teams composed primarily of developers. But I wonder if the nature of embedding the bug reports in the repo makes it largely inaccessible to your typical QA and support personnel who tend to open the most tickets at larger organizations?
There are two sets of people who want to track programmer tasks, and they're quite different already.
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.
IBM's old PMR system was their front-end, and they used CMVC as the back-end until it got replaced [1]. The two combined did what you described, and was the earliest example I know of as a commercial offering of version control tightly bound to bug reports. Very satisfying to see this concept get more traction with git and various bug trackers. I wish a public open interchange standard would evolve so the different integration combinations wouldn't be so brittle, though.
The web UI is designed to, in the future, be used as a public interface as well. It would need to have some kind of authentication to identify users though.
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.
Each bug is stored independently and in particular independently of the source code, so older bugs could be archived or simply left on the git remote.
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.
>Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
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.
> Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
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...
IMO It should be feasible to build data bridges for integrating or syncing with related systems.
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.
Would be nice if there was a tracker done in all shell, or just plain text, so that we don't need to rely on go, or another program.
Maybe it could work to develop a core protocol and data structures that are usable by others, with your own go implementation to work with those structures and protocol.
I really like this. However, I'd like to know if there is something like git-bug status to see what new bugs/comments were added and git-bug reset (or checkout) to revert recent changes that were not pushed.
Personally I've had great success with http://mrzv.org/software/artemis for the past few years. Issues are stored in a `.issues` directory as maildirs, so it does "leak out" into the file tree, unlike this which seems to build on Git's existing metadata storage.
I went through this thought process with SIT[1] -- it started out with issue tracking hard-coded into it but it has been later extracted into a separate model and the data & process models are being refined to make them much more generic and support other use cases.
The same idea for the storage and merge can certainly be applied to other use cases. A wiki would probably be kinda tricky because you would need a an edit operation for each change in the text but that's probably doable.
huge fan of this model. i started my own proof of concept of it a while ago, tho didn't take it this far. i assume you can track the status of the bug independently per branch?
Bugs storage and management is entirely disconnected from the regular code and branches. That said, it probably make sense to be able to tag a bug with the branches that are affected.
ah, bummer. yeah, "closing" a bug in a branch / PR, and then having that status automatically tracked across all merges into master / other branches is i think a huge win for this kind of idea. (vs. manually tracking it per branch, which is a good feature but no one ever seems to use, i believe because it's just to labor intensive.)
That helps you track the location of one fix, but not of all the other places the bug still resides (other release trains, for instance.) I feel like maybe there are several release models that would benefit from different types of bug trackers.
agreed. to be clear i like this project a lot. we desperately need innovation in this area. this current github+jira duopoly on issue tracking is annoying.
Shameless plug: if you like this, I'm looking for a remote job. My email is on my Github profile and my resume is here: http://pellelatarte.fr/dl/resume.pdf .
Sorry for turning this comment thread into an AMA but I have a question for you as the author :)
Reading over this page https://github.com/MichaelMure/git-bug/blob/master/doc/model... gives me the impression that you’re reproducing some of Git’s functionality. Can you elaborate on why Git’s merge model is insufficient and why the “Operation/OperationPack” serves the distributed-edits problem better than Git itself? Or alternatively, explain what I’m missing about how this doesn’t step on Git’s toes? Congrats on building this and shipping it!
There is manual merging code in git-bug [0] only because git doesn't provide a low-level command to rebase a branch onto another without touching the index. I don't think it's an intended limitation of git but more likely no one had a use case for that so they simply used the normal index.
Apart from that, a normal git rebase would merge two versions of the same bug conflict free. Each commit is independent from the other. A merge is simply moving the new operations at the end of the chain of edit.
If for instance, that means that you closed a bug that is already closed, well the bug is still closed and your action will still be displayed in the timeline.
- You should post this to the Git mailing list. We don't bite, and a lot of people would be interested in the details of how it works there.
- If you haven't you should check out git-annex. It solves an entirely different problem, but much of the distributed custom merging of histories, using git for ad-hoc metadata etc. is the same problem you're solving.
- You should be aware if you aren't that the design of having a ref per bug has some drawbacks, some operations in git are O(n) the number of refs.
- It would be really interesting to see some write-up on how the format you're using compares to the format Fossil uses for its bugs. I think some of what Fossil does wouldn't be possible to do in git due to its simpler data model, but still, such a comparison would be educational.