Re: [PATCH v1 2/8] format-patch: confirmation whenever patches exist

2 messages, 2 authors, 2021-05-11 · open the first message on its own page

Re: [PATCH v1 2/8] format-patch: confirmation whenever patches exist

From: Junio C Hamano <hidden>
Date: 2021-05-10 07:32:52

Firmin Martin [off-list ref] writes:
quoted
True.  But if we require confirmation before overwriting patches,
that would be overall worsening the end-user experience, I am
afraid.  In a 5-patch series with a cover-letter that was formatted,
proofread, corrected with "rebase -i" and then re-formatted, unless
you rephrased the titles of the patches, you'd get prompted once for
the cover letter (which *IS* valuable) and five-times for patches
(which is annoying).
This is true for this patch, but the semantics changed after the patch
#3. I really should have squashed them together to not create
confusion. Sorry about that.
No, please keep them separate.  What we can do to avoid confusion
like I showed is to make a note on the earlier one, saying "with
this the user experience looks like this, which may be suboptimal
for such and such reasons, but in a later step it will be improved
in this and that way".

Re: [PATCH v1 2/8] format-patch: confirmation whenever patches exist

From: Firmin Martin <hidden>
Date: 2021-05-11 03:17:24

Junio C Hamano [off-list ref] writes:
Firmin Martin [off-list ref] writes:
quoted
quoted
True.  But if we require confirmation before overwriting patches,
that would be overall worsening the end-user experience, I am
afraid.  In a 5-patch series with a cover-letter that was formatted,
proofread, corrected with "rebase -i" and then re-formatted, unless
you rephrased the titles of the patches, you'd get prompted once for
the cover letter (which *IS* valuable) and five-times for patches
(which is annoying).
This is true for this patch, but the semantics changed after the patch
#3. I really should have squashed them together to not create
confusion. Sorry about that.
No, please keep them separate.  What we can do to avoid confusion
like I showed is to make a note on the earlier one, saying "with
this the user experience looks like this, which may be suboptimal
for such and such reasons, but in a later step it will be improved
in this and that way".
Ok, it's noted.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help