I'm a contributor of Jujutsu, a git-compatible VCS. I'm also a happy Forgejo self-hoster! 😄 Jujutsu is currently engaged in an effort that would benefit from collaboration across the Git ecosystem, including Forgejo. I will explain as concisely as possible.
Many VCS-enthousiasts are excited about patch-based code review / stacked PRs. Code review tools that descend from the GitHub tradition, including those of GitLab and Forgejo, don't support these workflows well. That's because it's hard to track what has and hasn't been reviewed between force-pushes. This incentivizes continuously adding meaningless "fixup commits" on top of a branch, to make iterative code review easier. At the end, PRs are often squashed to clean up the history, losing valuable intermediary information in the process.
Unfortunately, there is no trivial solution to this. After a force-push, it's not generally possible for Forgejo & Co. to associate old and new versions of a commit. Content- and metadata-based heuristics could probably go a long way, but they won't be perfect. Jujutsu and other projects have the answer to this: In addition to the SHA hash, a commit is associated with a change-id that doesn't change after a commit --amend or rebase -i. Jujutsu, GitButler and Gerrit have just agreed to standardize on a common format for a change-id commit header. That means Jujutsu users will soon start pushing commits to Forgejo instances that contain this header. It could be used by Forgejo to provide a reliable, patch-based review experience.
My question to Forgejo contributors is: Would you be interested in adding a patch-based review UI to Forgejo that uses this commit header? I'm actually interested in contributing / helping with this UI myself. I have many ideas about how that could work and what benefits it will bring. The important part is that commits (and commit messages!) should be at the center and reviewers can easily track what they haven't reviewed yet, even across a force-push. By default, reviewers should only be presented with the interdiff of the current version and the one they previously reviewed. Feel free to ask about / discuss details, just trying to keep this first message short.
We are also planning to convince the Git project itself to support this new standardized header. This would mean that every Forgejo user would benefit from reliable patch-based code review, not just Jujutsu users. We assume the Git project will be the hardest to convince, so we're gathering all the social momentum we can before we talk to them 😉
I'm looking forward to discuss with you how to improve Forgejo and at the same time uplift the entire Git ecosystem.
I'm a contributor of [Jujutsu](https://github.com/jj-vcs/jj?tab=readme-ov-file#jujutsua-version-control-system), a git-compatible VCS. I'm also a happy Forgejo self-hoster! 😄 Jujutsu is currently engaged in an effort that would benefit from collaboration across the Git ecosystem, including Forgejo. I will explain as concisely as possible.
Many VCS-enthousiasts are excited about [patch-based code review](https://blog.gitbutler.com/interdiff-review-with-git-range-diff/) / [stacked PRs](https://graphite.dev/blog/stacked-prs). Code review tools that descend from the GitHub tradition, including those of GitLab and Forgejo, don't support these workflows well. That's because it's hard to track what has and hasn't been reviewed between force-pushes. This incentivizes continuously adding meaningless "fixup commits" on top of a branch, to make iterative code review easier. At the end, PRs are often squashed to clean up the history, losing valuable intermediary information in the process.
Unfortunately, there is no trivial solution to this. After a force-push, it's not generally possible for Forgejo & Co. to associate old and new versions of a commit. Content- and metadata-based heuristics could probably go a long way, but they won't be perfect. Jujutsu and other projects have the answer to this: In addition to the SHA hash, a commit is associated with a change-id that doesn't change after a `commit --amend` or `rebase -i`. Jujutsu, [GitButler](https://gitbutler.com/) and [Gerrit](https://www.gerritcodereview.com/) have just agreed to standardize on a common format for a _change-id commit header_. That means Jujutsu users will soon start pushing commits to Forgejo instances that contain this header. It could be used by Forgejo to provide a reliable, patch-based review experience.
My question to Forgejo contributors is: Would you be interested in adding a patch-based review UI to Forgejo that uses this commit header? I'm actually interested in contributing / helping with this UI myself. I have many ideas about how that could work and what benefits it will bring. The important part is that commits (and commit messages!) should be at the center and reviewers can easily track what they haven't reviewed yet, even across a force-push. By default, reviewers should only be presented with the interdiff of the current version and the one they previously reviewed. Feel free to ask about / discuss details, just trying to keep this first message short.
We are also planning to convince the Git project itself to support this new standardized header. This would mean that every Forgejo user would benefit from reliable patch-based code review, not just Jujutsu users. We assume the Git project will be the hardest to convince, so we're gathering all the social momentum we can before we talk to them 😉
I'm looking forward to discuss with you how to improve Forgejo and at the same time uplift the entire Git ecosystem.