GNU bug report logs - #57400
29.0.50; Support sending patches from VC directly

Previous Next

Package: emacs;

Reported by: Antoine Kalmbach <ane <at> iki.fi>

Date: Thu, 25 Aug 2022 08:49:01 UTC

Severity: normal

Found in version 29.0.50

Done: Philip Kaludercic <philipk <at> posteo.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Philip Kaludercic <philipk <at> posteo.net>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 57400 <at> debbugs.gnu.org, Antoine Kalmbach <ane <at> iki.fi>
Subject: bug#57400: 29.0.50; Support sending patches from VC directly
Date: Thu, 06 Oct 2022 14:37:59 +0000
Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Thu, 06 Oct 2022 12:38:25 +0000, Philip Kaludercic
> <philipk <at> 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




This bug report was last modified 2 years and 219 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.