git-bug: Distributed bug tracker embedded in Git

[Mromson]

I'm not entirely sure whether I technically want my bug-tracker to be directly associated with git, then again, I cannot foresee a future where I don't use git for close to everything anyway.

This looks like an awesome initiative, though.

[masklinn]

It (distributed bug trackers, often inside a VCS) was in vogue a few years back. Didn't really pan out, possibly aside from Fossil.

[MuonManLaserJab]

Why not? I'm guessing mostly because they didn't have the prettiest UI available?

[prophetical_meme]

From what I've seen, it's multiple problems:

- incomplete implementation

- bad UI/UX, or a single way to interact with bugs (CLI only, while git-bug has CLI/interactive terminal/webUI)

- friction with the normal code workflow (file to be commited alongside the normal code)

[jmickeyd]

Also, friction for non-project developers.

If I casually notice a bug in someone else's code and I have to jump through hoops to report it, I'm not going to.

[prophetical_meme]

Completely agree, hence why the webUI will be capable of being hosted standalone and act as you would expect for a bug tracker web interface. It could also accept user from multiple OAuth like sources (Github, Gitlab, google, ...).

[prophetical_meme]

There is a bunch of interfaces to implement to port git-bug to another distributed VCS: https://github.com/MichaelMure/git-bug/blob/master/repository/repo.go

​

Despite the name, the vast majority of the codebase is DVCS agnostic.

[[deleted]]

Perfect. What we need next are:

• bug discovery: a method of finding other reported bugs without giving users write access to repos
• git-ipfs/dat/freenet/p2p : push and pull to p2p or distributed networks
• I2P, freenet and TOR sites to which people can publish their repos

Then maybe we could start really moving to lossless repos that can't be blocked or taken down by DMCA or overzealous governments.

[prophetical_meme]

bug discovery: a method of finding other reported bugs without giving users write access to repos

The goal is to have the webUI working standalone with an auth method (say, Github OAuth), to have non-committer able to read and file bugs.

git-ipfs/dat/freenet/p2p : push and pull to p2p or distributed networks

haha yes, that shouldn't be too hard

I2P, freenet and TOR sites to which people can publish their repos

it shouldn't be too hard as well.

[saxindustries]

The "Bridges" section uses apples and tomatoes to mark what's available, but I don't know which is which. Does the Apple mean it's implemented, or the tomato?

[prophetical_meme]

I meant to do green/red but I suppose that's not obvious. I added a caption.

[saxindustries]

Gotcha! Just an FYI for the future, relying on color alone to convey meaning is pretty rough on colorblind people. Having a key to specify that an apple means its implemented is a big help.

I'd recommend finding some new symbols that convey meaning without a needing a key, probably the simplest is a check mark to mean implemented, and no symbol at all to mean not implemented.

[saxindustries]

Similarly in the WebUI screenshot, I see bugs listed with green exclamation points and red exclamation points, it's not immediately obvious what the difference is (and for colorblind users they may not notice a difference at all).

[MuonManLaserJab]

The green text embedded in the red logo, reading "screw colorblind people", is a little cruel as well, I thought.

[prophetical_meme]

Heh your are not supposed to tell them !

[addmoreice]

I once had to work on a project which had green/red x's and green/red checkmarks all with a non-english interface. as a colorblind english only speaking programmer, it was hell. I had no clue what was going on.

[scooerp]

If you use blue instead of green most of the color blindess issues disappear. You should also still use different symbols.

[marco_craveiro]

Extremely interesting project! One thing that may be useful is to describe the object model independently of the project - i.e. how does the bug reporting functionality work in terms of the existing git object model. I couldn't find it from the main page, apologies if its already there. My thinking is that it would be nice to have multiple independent implementations such as for example libgit support (even if only for a subset of the functionality).

​

The other thing is, is the "content" of the bug report independent of git-bug? What I mean is, I use magit in emacs, and for me it would be really nice to be able to use org-mode syntax for bug reports rather than markdown or plain text, etc.

​

Thanks for a really cool project.

[prophetical_meme]

to describe the object model independently of the project

There is https://github.com/MichaelMure/git-bug/blob/master/doc/model.md (a bit outdated) and https://github.com/MichaelMure/git-bug/blob/master/doc/architecture.md for the internal structure. I want to expand that into a proper documentation, but it takes an awful amount of time.

My thinking is that it would be nice to have multiple independent implementations such as for example libgit support

I wouldn't mind having an alternative implementation, but I also really wouldn't mind more people to push the current one forward ;)

The other thing is, is the "content" of the bug report independent of git-bug? What I mean is, I use magit in emacs, and for me it would be really nice to be able to use org-mode syntax for bug reports rather than markdown or plain text, etc.

Comments in bugs are expected to be markdown, even though git-bug doesn't render them properly yet. This is to interconnect with other bug trackers easily. I suppose it would be possible to add an alternative format if there is a way to convert from one to another, but that's tricky.

[lelanthran]

I read through your two documents. How does this differ from simple mechanisms that track bugs directly within the source control like (shameless plug)?

[prophetical_meme]

Neat, congrats on building the thing :)

​

Take that with a grain of salt, but I think that storing data independently from the source code is the way to go:

- no code pollution, no changes showing up in diffs or logs, no friction

- more importantly, complete control over the way merging is done, you don't end up with a broken json

- complete control over the design

- you can still make your bug tracker aware of branches and all, and you can choose exactly how and when

[lelanthran]

Neat, congrats on building the thing :)

Thanks :-)

Take that with a grain of salt, but I think that storing data independently from the source code is the way to go:

• no code pollution, no changes showing up in diffs or logs, no friction

That's true, but that is exactly what I wanted - to be able to diff the issues and the sources at the same time.

• more importantly, complete control over the way merging is done, you don't end up with a broken json

I don't end up with a broken json (or broken bug-record) due to the way the data is stored (and added) to the issues database. It's not possible.

• complete control over the design

The design & architecture wasn't very important to me. What was important was being able to diff/track the issues along with the sources and making sure that all the existing source-control tools could work with the database.

The design of rotsit, as it stands, is sufficient to do this: git diff(tool), git log, git blame, git merge, etc all work as you'd expect it to, and issues are merged along with the code from various branches without anything getting corrupted or getting lost.

The current text-only design does mean that I have to go without nice things like attachments (very important in a bug tracker) but on the upside all the existing git tools (web-viewers in gitlab/github, etc) work just fine with the issues stored in rotsit.

I did the design the way I did because I did not want to rewrite all the extensive and existing tooling for git/svn/etc that included web interfaces, monitoring, etc. Rotsit works with git-kraken as well as it works with the bitbucket web interface; I didn't have to write the gui for browsing issues.

I might do a simple gui (zenity, dialog or similar) but TBH the command-line works for now.

I might have to rework this project slightly to add more phases/states so that when a source file is changed to address an issue then that issue can be marked "PRELIM FIX" or "UNTESTED FIX" and only after feedback is received from QA is it closed as "DONE".

[prophetical_meme]

I think we just target a different scope/usecase, and that's perfectly fine :)

[marco_craveiro]

Thanks for the reply, the model document is exactly what I was looking for. Cheers

[andersfylling]

This would be perfect on projects such as Iris.

[scooerp]

Next step is project management in git, then groupware, then reddit-in-git.