News for hackers. Stuff that matters.

A comment on The Return of Fancy Tools. Parent comment

Re:The Return of Fancy Tools by Izkata on Saturday May 15, 2021 @04:31AM (#27163459)
Experimenting with distributed issue trackers in git was popular in the early 2010s, there were a whole bunch of different implementations people came up with for git. Most of them died out though, there were typically a few problems - this is what I remember offhand from experimenting with a whole bunch of them:

* Some of them make a mess of some part of git; one of them put its info in separate git branches you couldn't delete without breaking it, to ensure changes were always pushed/pulled even without a special push/pull command for the issue tracker.

* At least one of them kept their info in the repo in a dot-prefixed directory and auto added/committed the file as changes were made; this meant a single issue could be in different statuses depending on which branch you were on and there was no overarching view.

* The rest effectively ran in parallel to the git repo, pushing and pulling their data within it but requiring their own commands to do so, so it was totally possible to clone the repo and not get the issues.

* Most of them didn't have a non-repo way to track issues, for project managers and such. One did have a webview that ran from a repo, but it was up to you to figure out how to keep it in sync with the comments/etc devs were putting in their copies of the issue tracker.

Sibling mentions git-bug, a few others I recalled/quickly found:

https://github.com/aaiyer/bugseverywhere (I think this is one of the original ones)

https://github.com/dspinellis/git-issue

https://github.com/neithernut/git-dit

https://github.com/google/git-appraise (I think this one is newest and I probably never tried it)

[ Parent | on HN ]
Re:The Return of Fancy Tools by morelisp on Saturday May 15, 2021 @04:53AM (#27163558)
> a single issue could be in different statuses depending on which branch you were on

To me this is the main point of storing issues in git!

[ Parent | on HN ]
Re:The Return of Fancy Tools by michaelmure on Saturday May 15, 2021 @06:08AM (#27163903)
It seems to be a polarizing idea. Many people can't stand it, but also I suspect that very few actually worked with something like that.

In any case, I believe that it's better to build a data model/storage without that concept (read: don't store the data in the same branch as the code) to have the freedom to built it with less constraint and make it right. Once that work you can add this "branch sensitivity" concept on top and again make it exactly how you want it.

An example of problem you get when storing the bug data in normal code branch: cool, you got the bugs state deeply stick with the code so you know exactly when a bug is resolved and in which branch. But now you are stuck with git only to deal with merge conflict, which means you might need to have the user fix it when it goes wrong. Will you push that to a non-technical person as well? Also, what happen when you rebase or cherry-pick?

[ Parent | on HN ]
Re:The Return of Fancy Tools by Izkata on Saturday May 15, 2021 @04:04PM (#27168491)
Consider the "no overarching view" part: if you just cloned the repo, you'll see a bunch of open issues and no hint that they're already being worked on, because you have to check out each branch to see if that issue has updates.
[ Parent | on HN ]