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.

Michael Muré (MichaelMure) changed the title from feat: support for pull requests to [feat] support for pull requests 5 years ago

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.

Michael Muré (MichaelMure) changed the title from [feat] support for pull requests to feat: support for pull requests 5 years ago

Michael Muré (MichaelMure) added label enhancement 5 years ago

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.

I fully agree that support for PRs would be a great feature

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?

#17 is a duplicate of this

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 😁

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

Not stale.

github-actions (github-actions) removed label lifecycle/stale 1 year ago

sudoforge removed label enhancement 1 year ago

sudoforge added label kind/feature 1 year ago

sudoforge added label area/changesets 1 year ago

sudoforge added label priority/important-longterm 1 year ago

sudoforge added label triage/needs-information 1 year ago

sudoforge added label triage/needs-approval 1 year ago

sudoforge removed label priority/important-longterm 1 year ago

sudoforge added label priority/awaiting-more-evidence 1 year ago

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/stale 1 year ago

Not stale

This would be what I'm currently searching for… Too bad I can't use it yet :(

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.

While I initially liked @jeyj0 idea, I'm not sure if it is a good approach. But that may come from a lack of insight how the datamodel works.

First of what data is needed for a Pull request:

• Probably everything an Bug has
• a Target branch (Ref?)
• a source branch (Ref?)
• Since we want to review, every comment probably should have the commit hash of source Since while incorporating feedback the branch move on and older comments might get outdated
• We may also want the current commit hash of the target branch for comments
• A comment can also have a reference to an File (Git object) and a position in it
  • For Text
    • linen number start
    • number of lines (length)
    • column start (optional?)
    • column end (optional?)
  • Maybe other formats to? x,y coordinates for pictures? I wouldn't try to think to hard about that, but don't close this path since it looks like a nice features
• other comments could be made on review comments that reference code, starting a discussion in the code.

That is how I would imagen the data (roughly). The reason why I think converting an issue to an pull request is not a good idea, is that I think target and source branch should be immutable (resetting a Branche to a completely different commit is problematic enough) and that converting would make it harder to merge.

Think of following scenario: There is an open issue and both Alice and Bob start a pull request locally (converting the ticket) and start developing and committing in the Pull request branch. Then both push. There may now be a conflict, if an issue can only have one source. Then one pull request would win and the other is "overwritten". Or it is implemented that one issue/pull request can have multiple source branches, then merging is not a problem, since both can coexist. But then one discussion will have comments to two different code bases. I think neither is optimal.

What the structure is still missing, is a real "Review" workflow, that gives the Ok for the merge, maybe with some security that prevent merging, when not reviewed.

PS: If someone implement Reviews, please allow commenting on lines that have not been changed… github pull requests forbid that (for whatever reason), and that is currently a blocker for me :(

sudoforge removed label lifecycle/idle 7 months ago