Thread (4 messages) 4 messages, 2 authors, 2021-03-14

Re: [PATCH v3] [GSOC][RFC] format-patch: pass --left-only to range-diff

flat view

From: ZheNing Hu <hidden>
Date: 2021-03-14 02:20:09

Junio C Hamano [off-list ref] 于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?`)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help