[For general support questions, please address only the mailing list. It's not necessary to bother the maintainer personally. Though, I'll not remove him from Cc, yet, as to comply with this ML's etiquette.] Am 12.10.23 um 14:00 schrieb ZheNing Hu: > Hi everyone, > > Our company wants to design a "small-batch" code review feature. > Simply put, this "small-batch" means being able to treat multiple > related commits within a MergeRequest as an independent "small" code > review. > > Let me give you an example: We have five commits: A1, B, A2, C, A3. > Among them, A1, A2, and A3 are multiple commits for the same feature. > So when the user selects these commits, the page will return a > "combine diff" that combines them together. > > A1 B A2 A3 C > *--------*----*-----*-------* (branch) > \ A1' \ A2' \ A3' > *------------*------*------- (small branch code review) > > This may seem similar to cherry-picking a few commits from a pile of > commits, but in fact, we do not expect to actually perform > cherry-picking. > > Do you have any suggestions on how we can merge a few commits together > and display the diff? The only reference we have is the non-open > source platform, JetBrains Space CodeReview, they support selecting > multiple commits for CodeReview. [1], . Take a step back. Then ask: What are the consequences of the review? What if the result is: the feature is perfect, we want it merged, however, we cannot, because we do not want commit B. What if the result is the opposite? You need B, but you can't merge it because the feature is not ready, yet? You are looking for a technical workaround for a non-optimal workflow. If A1,A2,A3 are a feature on their own, they, and only they, should be in their own feature branch. So, I would say, the best solution is to reorder the commits in a better manageable order. You do know about git rebase --interactive, don't you? -- Hannes
