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


Message #253 received at 57400 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Juri Linkov <juri <at> linkov.net>
Cc: Robert Pluim <rpluim <at> gmail.com>, 57400 <at> debbugs.gnu.org,
 Antoine Kalmbach <ane <at> iki.fi>
Subject: Re: bug#57400: 29.0.50; Support sending patches from VC directly
Date: Sun, 09 Oct 2022 12:15:39 +0000
Juri Linkov <juri <at> linkov.net> writes:

>>> Also please note that the most convenient way to select revisions
>>> to submit is to show the log buffer, and use 'm' to mark revisions
>>> (log-view-toggle-mark-entry).  Then 'log-view-get-marked' returns
>>> all marked revisions.
>>
>> This is supported,
>
> Thanks.  Since it's the most convenient UI, shouldn't this be
> documented in the Info?  IOW, what about copying this from the docstring
> to the manual:
>
>   When invoked interactively in a Log View buffer with marked
>   revisions, these revisions will be used.

I can add that.

> Also the use of "," to separate revisions needs to be documented
> in the docstrings and the manual.  Maybe also mention the separator
> in the prompt that reads multiple revisions.

Actually it is whatever was specified by `crm-separator', right?  But
yes, that can be mentioned too.

>> but currently not in this order.  Do you think an option should be
>> added that would use recursive editing to prompt the user?
>
> I see that currently the chronological order of revisions is used from
> the log.  This looks like the right order.  Prompting with the default
> value that is set to these revisions from the log would be also nice
> to do, so users will be able to change the order manually by moving
> revisions between ",".

Again, regarding `crm-separator' I don't know if this is a value that
people change or not (perhaps it should be changed to a defconst).  But
setting that aside, that sounds like a good idea.

I can also imagine that the initial input outside of a log buffer ought
to just be the last commit.

> Additional question: shouldn't the behavior of
> vc-prepare-patches-separately=nil be equivalent to
> vc-prepare-patches-separately=t when only one revision is given?  Both
> cases create just one mail.  So when vc-prepare-patches-separately is
> nil, could it extract the subject from the single revision?  Or maybe
> vc-prepare-patches-separately should support a new customization value
> for this?

Yes, but the formatting is different.  In the one case you attach a
patch to a regular message, while in the other case the message is
prepared in such a way that (at least when using Git) the entire message
is a valid patch, where we can use "git am".




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.