git-bug
git-bug copied to clipboard
MichaelMure
feat: support for pull requests
Might be slightly offtopic because the pull requests are no bugs but the repository limits the scope to bugs. However, i want to expand the vision of distributed development.
I think it would be very interesting if pull requests would also be supported in the same way as bugs. For projects such as lemmy this would be a really great feature, because lemmy has at the moment 3 repositories on github, gitea and gitlab. So you can make a pull request on any of those platforms, but for the issues you have to look at github.
I think a really great improvement would be to decentralize pull requests the same way as bugs. That could allow a development style where you just have different mirrors on github, gitea, gitlab, etc. but for the bugs and pull requests you can use git-bug, so you wouldnt need to use github or so.
And it would make this decentralized style of development actually easier than the status quo, since you do not need to look up multiple places (gitlab, github, gitea) to find out if a pull request has already done something you want to do. You just can look that up in git-bug.
So i think this would be really exciting to avoid being dependent on github or so. You can use github to gain popularity and being easily found, but you github is actually not important for the project as it is just another code mirror.
I completely agree with what you wrote. I would very much like to see PR support happening in git-bug. That's a long road though!
https://github.com/MichaelMure/git-bug/issues/118 is a nice to have before starting this work.
As a suggestion: I would vote for not distinguishing between issues and pull-requests, and instead allow converting an issue to a pull-request. Once the issue has been talked about, someone usually goes and implements something for it. Moving context to somewhere else doesn't seem intuitive (even though github, gitlab and gitea handle it this way). Mailing-lists don't have this distinction, and it doesn't make sense, I think. I think the solution might be to link a branch to the issue.
FYI I understand that github uses the same underlying structure for issues and pull requests.
Whether to follow that approach or not I have no idea, but might make it easier for git-bug.
The first step would be to figure out a data model for a PR with full history, and if possible a data model that is compatible with the github, gitlab and friends.
Next step is to express that data model into operations on a state (the data model), the same way a bug in git-bug is a series of operations. Then we can start implementing that.
Having PRs being enhanced bugs (that is sharing the same entity) is a possibility, but I'm a big afraid it would make things complex for no good reason. Remember that the way it's presented to the user doesn't have to match the data model.
Anyone want to give it a try?
FYI, git-bug data model has evolved greatly since that time and has a reusable data structure that would allow implementing this kind of thing easily-ish.
At the moment I'm working on a project board to force me to address the problem you get when you start linking entities together. I someone else want to give a try on the PRs, that'd be awesome.
@MichaelMure is this something on your near-term roadmap? Is there anywhere to follow along with planning?
Not in my near future roadmap but definitely in the roadmap. Apart from the general stuff, my next step is support for project board (https://github.com/MichaelMure/git-bug/pull/843). This feature is to me the beacon to follow to have all the layers in git-bug ready to accept new entities (pull-request being the next obvious one).
With https://github.com/MichaelMure/git-bug/pull/938 being ironed out, this extensive refactor/rewrite work is near its term.
As for supporting pull-request, there is a bunch of design steps that would greatly help, before even writing any code:
- what would the data model look like?
- what interactions are supported?
- what would the CLI tooling looks like? (there is a bunch of existing CLI tool doing code review already, would be cool to nail the UX)
- does that means we need to have a code explorer first? if so, how do we implement that?
Obviously, help welcome :-)
Just reading through this, I'm supportive @jeyj0's suggestion, but there's an alternative that might make a little more sense. Which is to keep the PR model skinny and for it to reference a bug/issue. Which means you can have many PRs to one issue/bug and forces you to keep discussion in a consistent place, like discussed 😁
