[michaelmure]

It's significantly more friction for little benefit compared to git-bug's solution. First, storing this data alongside the code means requiring everyone agreeing to use that tool (quite high ask). Then, that means that you let git merge said data in case of conflict, which leaves you two options: merge failure, or requiring the user to fix things. None of that is acceptable, and it's why many of previous attempt failed.

[makapuf]

Thanks for the reply, interesting. Regarding everyone agreeing, isn't someone quite obliged to use the project approach to bugtracking? If there are bridges, then you could implement them for this also. Re: merging, if you merge some branch that corrects or detects some bug, you have to correct bug definition anyway ? So I'd think its better to merge it explicitly? Not saying it should be good, but I'm tempted to try it to see if it can work.

[michaelmure]

A bugtracker being "branch aware" and able to say where an issue started, where it was fixed ... can (and should IMHO) be a different concern than how the data is stored and how conflict resolution happen. By conflict resolution here, I mean: what happens when two user on different machines edit their issues and then states get merged? If you have this data into some format (let say JSON) and rely on git automatically merging, you eventually end up with corrupted formatting. Instead, you can do all that in your own branches, not pollute the normal code and not let git do any merging. Then, you can still have your bugtracker understand branches and track that information.

[makapuf]

I understand that decoupling storage and features is useful. Regarding merge, and again I'm linking storage and functionality, but storing one file per issue would alleviate this. And two users working on the same issue would need to sync anyway. Well, maybe its foolish and would not work, I agree.