Collaboration with git-bug?

[hoijui]

I was wondering, whether that is an option, or how you'd think about that.
I would imagine, using the same storage model, or at least have a bridge (importer & exporter) from one format to the other would be cool.

Distributed bug trackers are not a simple concept, and are not widely in peoples scope for tools to actually use in practice. Widening market-share by combining efforts, or at least combining the potential user-base should benefit both(/all) projects. Not to mention the sharing of brilliant minds focused on the same topics.

this issue might be a good point for initiating contact, if it does not exist yet.

... or do you see fundamental incompatibilities in the ideas behind the two projects?

[neithernut]

I would imagine, using the same storage model, or at least have a bridge (importer & exporter) from one format to the other would be cool.

It has been a while that I had a look at that project. IIRC and things didn't change dramatically, the data model itself is indeed completely incompatible. While git-dit is modelled after mailing lists, git-bug is essentially based on a file-based data storage of issues which are designed to be easily diffable and mergable (using a custom tool). In git-dit you alter a single knob of an issue while in git-bug you commit a full representation of an issue's metadata (incorporating a change). Both models have their pros and cons. But it is a rather hard choice what model to choose.

An import/export functionality could be drafted. But a seamless interaction between both systems is probably not possible.

That being said, there are opportunities for collaboration. For example, handling of an issue's state (e.g. "open"/"closed") and other metadata may benefit from a common ground. And be it for the user-experience alone. One of my neglected and dormant projects called issue-state was intended as possible base. Authentication and/or exchange of issue data between different forks is also a problem which (probably) all distributed issue trackers based on git face. A solution for one issue-tracker would probably also work for other issue-trackers.

this issue might be a good point for initiating contact, if it does not exist yet.

Well, I don't think that git-bug will completely redesign their storage model. That would not make much sense. I do have to say, however, that git-dit's data model was chosen partly to avoid the entire collision-avoidance mess the issue talks about. So... git-dit simply doesn't have that particular issue 😄 (we have a bunch of other issues, instead)

[hoijui]

sorry for the late answer, I wanted to have a free head to answer...

In git-dit you alter a single knob of an issue while in git-bug you commit a full representation of an issue's metadata (incorporating a change).

I am not sure I understood this correctly, but if I did, I think.. the git-bug model works differently now. There are commits altering a bug, which consists of packs of "Operation"s, each modifying a part of the bug, for example the title, the message, the due-date, ... and there is a different type of Operation for each modification, for example CREATE, MODIFY_DATE, ADD_COMMENT, MODIFY_COMMENT,...
so .. I would guess it is more similar then, no?

[neithernut]

I am not sure I understood this correctly, but if I did, I think.. the git-bug model works differently now.

Well, I may also just have mixed up git-bug's data-model with the data model of another distributed issue tracker in the end (there are quite a few, some also called "git-bug").

The data-model you described is indeed more similar to that of git-dit. However, I do have to have a closer look at git-bug again in order to assess whether direct interaction is feasible or not.