Junio C Hamano <gitster@xxxxxxxxx> 于2023年10月13日周五 01:03写道：
>
> ZheNing Hu <adlternative@xxxxxxxxx> writes:
>
> > 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.
>
> If you said "We do not want to", I may be sympathetic, but it is
> curious that you said "We do not expect to", which hints that you
> already have some implementation in mind.
>
Our code platform has the ability to cherry-pick (by libgit2),
but using cherry-pick to merge and display the diff of the same feature
might be challenging for users (as it can easily meet conflicts).
> Whether you use a checkout of the history to a working tree and
> perform a series of "git cherry-pick" to implement it, or use the
> "git replay" machinery to perform them in-core, at the conceptual
> level, you would need to pick a base commit and apply the effect of
> those commits you would want to look at on top of that base in
> sequence, before you can see the combined change, no?
>
Yes, "cherry pick" and "rebase -i" are indeed the most natural
approaches to merging and displaying diffs. It's unfortunate
that we didn't choose to use them in our technical selection.
> Puzzled.
I can only roughly estimate how Jetbrains Space solves this problem:
1. The user selects a few non-consecutive commits in the commit list.
2. The backend service will calculate the set of modified files for the selected
commits in the CodeReview.
3. The backend service it calculates the latest commit and oldest parent commit
of each file that introduced the diff in the selected commits.
4. it calculates the file diff using these two commits.
5. Afterwards, there is some way to filter out the intermediate, non-selected
commits that modified the files. I don't quite understand this
step, it feels rather hacker-like.
