Johannes Sixt <j6t@xxxxxxxx> 于2023年10月13日周五 00:41写道： > > [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.] > OK... I get it. > 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? > The CodeReview here is only expected to review the Diff changes (just like jetbrains Space). If it is truly blocked by B, users should understand to remove B or cherrypick A1, A2, A3 into a new branch. > 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. > I have to admit that this is addressing the issue for users who are not very familiar with the git workflow, as they might add 70 commits in a CodeReview. My goal is to enable these users to display the diff of multiple commits that they consider to be related together. > 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? > It would be great if users knew how to do that, and I wouldn't have to explore such unconventional technical solutions :( > -- Hannes >
