[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57400: 29.0.50; Support sending patches from VC directly
From: |
Philip Kaludercic |
Subject: |
bug#57400: 29.0.50; Support sending patches from VC directly |
Date: |
Thu, 06 Oct 2022 14:37:59 +0000 |
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Thu, 06 Oct 2022 12:38:25 +0000, Philip Kaludercic
> <philipk@posteo.net> said:
> Philip> +(defcustom vc-prepare-patches-inline nil
> Philip> + "Non-nil means that `vc-prepare-patch' creates a single
> Philip> message.
> >>
> >> "Whether `vc-prepare-patch' attaches all revision in a single message."
> >>
> >> Iʼm not sure this should have the suffix '-inline', because you can
> >> have inline attachments and attached attachments, but itʼs not a big
> >> deal.
>
> Philip> If you have a better name, there is no better time to
> Philip> change it than now.
>
> `vc-prepare-patch-attach'? `vc-prepare-patch-attach-patches'? Itʼs all
> a bit of a mouthful to type, and it doesnʼt feel like much of an
> improvement over what you have.
Maybe `vc-prepare-patches-separately' and set the value to t by defaut?
> >> I also wonder about the default. Creating 100 mail buffers by accident
> >> is harder to recover from than a single one with 100 attachments, but
> >> I guess experience will inform us.
>
> Philip> The only case where this might happen by accident is when someone
> Philip> invokes `vc-prepare-patch' in a log-edit buffer where all
> Philip> (or at least a
> Philip> lot) of revisions have been marked. In that case, one could add a
> Philip> "safely check" and make sure that the user actually wants to
> proceed.
>
> That sounds sufficiently hard to achieve by accident that we
> should leave it alone for now.
Ok.
> Philip> +A single message is created by attaching all patches to the body
> Philip> +of a single message. If nil, each patch will be sent out in a
> Philip> +separate message, which will be prepared sequentially."
> Philip> + :type 'boolean
> Philip> + :safe #'booleanp
> Philip> + :version "29.1")
> Philip> +
> >>
> >> (I didnʼt check, can this do the [PATCH n/m] stuff with the
> >> subject that 'git format-patch' can do?)
>
> Philip> Yes, as the Git backend just copies the subject name that
> Philip> git-format-patch generates.
>
> Perfect
>
> Philip> As this is just the default value for
> Philip> `read-multiple-choice' a list with
> Philip> commae should do. That being said, how common is it to have
> multiple
> Philip> people you consistently want to send a patch to? Usually
> Philip> you'd have a
> Philip> central mailing list or something like that, I'd assume.
>
> Right, and itʼs a string, so it caters for multiple addresses.
I am confused, so everything in fine?
> >> ? What does `vc-prepare-patches-inline' have to do with the SUBJECT?
>
> Philip> Because the subject for an "inline patch" is extracted
> Philip> from the commit
> Philip> message.
>
> Perhaps mention that in the docstring?
That should be doable.
> Anyway, I think Iʼve picked enough nits for this patch.
If there is anything more to nit, please pick.
> Robert
- bug#57400: 29.0.50; Support sending patches from VC directly, (continued)
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/05
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly,
Philip Kaludercic <=
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/09
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/10
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/11