Junio C Hamano <gitster@xxxxxxxxx> 于2021年3月14日周日 上午7:23写道： > > Yes, it would be, but that is why you need to educate users what > causes it, and what the right way to avoid unrelated commits from > appearing, and how this --left-only fits in the solution. > > If some of the time, "--left-only T1...T2" would give you the same > result as the more strict "B1..T1 B2..T2", that may be why users may > want to use the "--left-only" instead as an easy/lazy alternative. > > But I suspect that it would give an incorrect result some of the > time---for example, in the above example, wouldn't one of the > commits labeled as 's' be completely hidden? And if that is the > case, the end-user documentation would need to warn about it, and > explain that it is a easy/lazy alternative that can produce > incorrect result in the log message. Thanks, I will try to illustrate these issues in the document. My another thinking is: Since `--left-only` inhibits "B1..B2" and "B2..T2" ( let the user choose the left B1..T1 ), To some extent, `--right-only` can also add ( let the user choose the right B2..T2 ). A separate `--left-only` will be strange to the user ( If user call T2...T1 ). Since the `git rebase --apply` will internal call `git format-patch -k --stdout --full-index --cherry-pick --right-only ...`, I don't know what to deal with this `--right-only` yet, because I don't how to teach git to judge if the `--right-only` is pass from user or `git rebase --apply`, Is there any good way? If can solve this problem, the user can choose the left or right side of the free choice. (Or users don't need `--right-only?`)
