michaelmure

... which are bidirectional and incremental, meaning that you can use git-bug as an offline and local copy for github[1], without having to convert everyone on the project to that tool.

[1] https://github.com/MichaelMure/git-bug/blob/master/doc/howto...

Hi, author here. Happy to answer questions.

Version 0.8 just got out[1]. For the next one, I'll try to focus on making the codebase fully ready for multi-entities and introduce a Project Board. Later we can add support for code review!

If you are looking for how it works, you can have a look at the data model introduction[2].

git-bug is only pushed forward by volunteers so it's taking its time to fully grow, so I'll take the opportunity to welcome everyone to join the fun :-)

[1]: https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0

[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model...

https://github.com/MichaelMure/git-bug/blob/v0.8.0/doc/model... should answers all those question. In short: merge conflict are handled.

Author here, happy to answer questions.

Hi, git-bug's author here. That's pretty interesting way to have a text interface for PRs. I'd like to have something like that in git-bug.

Hi everyone. I'd like to show you the result of a long maturation process, the reusable distributed data structure of git-bug, that you can use in your own project to store your entities in git and collaborate through git remotes.

I'm hoping that this could spawn a new kind of developer tools, where all the "metadata" (bugs, kanban ...) of a project are stored and shipped alongside the code, always available offline, integrated in our tool of choice and always snappy.

If you have experience in that domain, please pock holes in it. There is always tradeoffs, but I'm hoping to avoid fundamental flaws.

In the mean time, git-bug[0] itself is close to a 1.0 release. This Show HN is a step in making sure the data model is correct and strong. Thank you!

[0]: https://github.com/MichaelMure/git-bug

One thing I've always wanted to see visualized if how the distribution of authorship of code evolve over time. Who wrote most of the code? Does that code remains or does it get rewritten? Who wrote the most foundational and time resistant code?

Do you fancy re-thinking buf trackers? I'm looking for help over at https://github.com/MichaelMure/git-bug to create a distributed bug tracker embeded in git, with bridges.

It's close to be ready for prime time, yet there is so much that could be done to make it better.

I've been doing something a bit similar with https://github.com/MichaelMure/git-bug/tree/master/entity/da... if you care about digging.

It's a generic distrubuted data structure in git, with identities and signature, and conflict merge. At the moment it's used to store bugs, more to come later.

git-bug author here.

It's still not v1 where there would be some sort of backward compatibility guarantee, but it's close if you are using master. Note though that even without that guarantee, there is git-bug-migration to provide you some safety.

There is however some bugs and missing features, as in any software that young with an author busy buying/refurbishing an apartment ;)

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?

Just a note though, you could centralize git-bug. Standardize/build on what git-bug is doing, and just don't expose the bug data in the same repo as the code. You then just need the extra bits of centralized administration.

That's fair, those are indeed hard to do right or impossible (although I hope we can collectively solve the "people use crypto keys properly" problem at some point).

Let see:

-- per-issue/component authorization (secrecy!): git-bug already support internally to attach crypto keypair to an identity and sign/verify the created commits. What's missing is proper tooling around that, ACLs and a way to configure them (a project settings datastructure), possibly a way to encrypt entirely the stored data. It's planned for the most part, good to have otherwise.

-- ease of access to non-git users: the goal is to have the webui to act as the public portal with external auth (github or your company SSO). I definitely agree that a bugtracker should not be just on the dev computer and should not require special tooling.

-- history rewriting/sanitizing: not so sure what you really want here. Editing comments is already possible. Otherwise, it's still possible to just delete a bug or add more concepts in the data model (archive, delete comment ...).

-- built-in large attachment hosting: Definitely planned. The data model already support that, it's just a matter of exposing it in the different user interfaces. Now for the storage usage, see below.

-- gigabytes of issue data and generally large scale deployments for large organizations: The funny thing when you put all the data in git is that the problem becomes "how to host git at scale", which is a sort of solved problem already. On top of the obvious, there is solutions like git LFS if you don't want to retrieve all the potentially large attachments. Also, as each bug is independent from each other, you can also shard a repo or just retrieve the bugs you care about with some filter.

I feel like those goals align pretty well with https://github.com/MichaelMure/git-bug, and many are already there. If you feel like pushing your own project is too much to bear, maybe consider contributing to git-bug to make it your own?

Yes please :)

Edit: consider having a look at the development version. While the core feature hasn't changed much, the webUI definitely improved. Also, the core became more robust and ready to accept more features easily.

It might not be exactly what you are looking for, but git-bug[1] is encoding data into regular git objects, with merges and conflict resolution. I'm mentioning this because the hard part is providing an ordering of events. Once you have that you can store and recreate whatever state you want.

This branch[2] I'm almost done with remove the purely linear branch constraint and allow to use full DAGs (that is, concurrent edition) and still provide a good ordering.

[1]: https://github.com/MichaelMure/git-bug [2]: https://github.com/MichaelMure/git-bug/pull/532

See https://github.com/MichaelMure/git-bug

This could be great to integrate in git-bug[1] if/when kanban get supported. This would be the fronted and git-bug would be the storage/collaboration layer.

[1] https://github.com/MichaelMure/git-bug/

It's the whole point of git-bug: breaking the vendor locking.

There is a Github bridge that will import the issues (including the complete history). PRs are not supported yet though.

Shameless plug, but that's exactly the aim of https://github.com/MichaelMure/git-bug.

It's a distributed bug-tracker: it stores issues (and one day, PRs) within git. You can work offline and you always have a full copy of everything. It also has bridges for Github, Gitlab and Jira.

Haha, that's awesome. It's interaction like these (and pretty much this whole thread) that make me think that there is value in this idea. It just has to reach some completion with a good UX ...

I have a bunch of git-bug.tld domains so I guess I'm all set already?

I'd be curious to see your project. Maybe there is a good idea in there? In any case, you are very welcome to join the party.

If you like this idea of embedding a bug-tracker (and eventually the code review) within a DVCS, I'm working on a project[1] that does that for git.

[1]: https://github.com/MichaelMure/git-bug

From what I've seen it's quite common to use a library to output those escape code. Given that, there is often a flag to disable all those colors/decoration at once without implementing a fallback specifically.

> Support for images concern many of us for that reason: sure it seems nice for a few cases used judiciously. But it feels counter-productive to the strengths of the CLI.

Of course those things should be used judiciously, but building CLI app on a broken standard only make it so much harder to build a quality app. You get a crappy end result just because it's difficult to do the "judiciously" part.

My point exactly. Some terminals do the expected thing of doing "bold off" because that make the mapping of codes regular, some follow ECMA-48 and do "double underline" even if that means that "bold off" is not possible.

At the end, there is no way to reliably do either of them.

A new standard would also make it easier to fallback to no colors/decoration if the user wish so. At the moment, there is no way to do that without a flags or similar for each app. Even detecting if the terminal support colors is a pain.

It looks to me that the reality is closer to "40 years of hack over something that was not meant to be a standard (a popular hardware terminal from the 80s)".

I'll give you just one example of the madness that is sometimes required: the escape code \e[1m is doing "bold on". It's counterpart to reset \e[21m, is supposed to do "bold off", but in practice some terminals do "double underline" instead because this standard is not a real standard. As there is also no real way to detect capability, the only reliable way to do "bold off" that I could find is to intercept the stream of data sent to the terminal to compute the attribute state. When you want to do a "bold off" you do a \e[0m "reset all" instead and sent the control character to set the state again without bold [1].

A new standard would also allow to reliably use features like displaying images or links.

[1] https://github.com/MichaelMure/go-term-markdown/blob/master/...

Shameless plug: https://github.com/MichaelMure/git-bug

Yes I realize the irony of pushing a project hosted on github when it's down.

"git" is in the name but it's actually not tied to it so much. If you can implement those interfaces [1], you can port it to another VCS and everything else will work. It's not trivial but entirely possible.

[1]: https://github.com/MichaelMure/git-bug/blob/master/repositor...

I won't comment on BE because I simply don't know enough about it but I'll try to clarify some things.

Instead of storing bug state, git-bug store intent of the users in a chain of commit. When read, those intents are interpreted and compiled into the state of the bug at that point. When a concurrent edition happen and a merge is needed, the concurrent operations are reordered as well as possible and a new state is computed. This state might not be the perfect state but: - it is guaranteed that the bug is in a legal state (no actual merge conflict making the data unreadable) - even if the reorder is not the one you would have wanted, the intent of user is preserved. It is clear who did what and you can "fix" the state manually by adding more operations if needed.

I'm not 100% sure that it's the optimal solution but it works. It might break in some full P2P scenario. To be honest, I'd like to eventually move over a full DAG of operation instead of this purely linear way so the conflicts can be merged in a more optimal way. See [1] and [2] for details.

What I'm sure though is that storing the state directly in git and especially alongside the code is the bad way to do it. It does lead to have unreadable state and badly merged state, and has been stated as a reason for failure by at least one similar project.

> The entire point being that as you make a change to the code in a branch, when finished you can also close the bug in that branch. When merged, that bug is now closed.

It's a nice feature but implementing that way implies the shortcoming described above. I believe the best way to implement that is to have git-bug "aware" of branches and have it react to those changes to either change the state or recompute it on the fly so the conflict resolution characteristics can be preserved. See [3].

[1]: https://github.com/MichaelMure/git-bug/issues/212 [2]: https://github.com/matrix-org/matrix-doc/blob/erikj/state_re... [3]: https://github.com/MichaelMure/git-bug/issues/16#issuecommen...