41–50 of 82 posts
I understand why the bug IDs are hashes, but that's going to be pretty inconvenient for practical use. Yes I know we manage it with Git commit names, but bug IDs are printed and spoken much more than commits, e.g. when communicating with a test team, management, or even in release notes. I wonder if we could use some sort of distributed naming scheme for this, similar to Blockchain DNS?
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…
Are there any plans to create a bridge to Azure issues? I searched for an open issue but couldn't find one.
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…
Are there any plans to create a bridge to Azure issues? I searched for an open issue but couldn't find one.
Happy user of git-bug for several years here, it’s a great tool, and the author is very receptive about bug fixes and adding new features. Probably my favorite is the built in TUI interface, that feature rocks. I don’t recommend it for larger projects where you have lots of committers, the in-built feature of GitHub/GitLab probably works better for those types of setups. Where I think this tool really shines, and the…
I understand why the bug IDs are hashes, but that's going to be pretty inconvenient for practical use. Yes I know we manage it with Git commit names, but bug IDs are printed and spoken much more than commits, e.g. when communicating with a test team, management, or even in release notes. I wonder if we could use some sort of distributed naming scheme for this, similar to Blockchain DNS?
Earlier quoted context omitted.
You can probably afford it! One thing that would be great is for projects to choose to adopt it without bridging (but I'm partial to decentralized behavior)
I agree, it seems self-defeating that the tool is independently distributed but offers bridges.
Earlier quoted context omitted.
Excellent idea! We need an interoperable format to break the monopoly of the forges like Github, but it will only gain traction if it is integrated in git itself the way it is in Fossil. Have you been in touch with the Git maintainers to see if they are open to the idea?
I haven't but I'm not sure it's really necessary. What needs to happen first is a large enough usage of git-bug, or at least a large enough use case coverage. To do so, I think it needs: - support for pull-requests - support for external auth in the webUI, to make it work as a public frontend where anyone can browse and interact with bugs like any other forge If that happens and people are convinced, I'd think that g…
My main goal is resiliency. A typical Elixir/Phoenix project, for example, will have some dependencies on github. If github or the internet goes down, or even disappears, there would be no way for us to rebuild that from source.