GNU bug report logs - #58383
29.0.50; Make it easier to invert vc-prepare-patches-separately

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58383 in the body.
You can then email your comments to 58383 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Make it easier to invert vc-prepare-patches-separately
Date: Sat, 08 Oct 2022 10:49:29 -0700

Hello,

How about a prefix argument to vc-prepare-patch to invert one's usual
setting for vc-prepare-patches-separately?  Most people who contribute
to more than one project regularly will want to use both.

On the other hand, having a numeric prefix argument mean "send patches
correspoding to the top N revisions of the current branch" would be very
convenient.  Perhaps these two could be combined by using a negative
number to mean also invert?

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 09 Oct 2022 12:54:51 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> How about a prefix argument to vc-prepare-patch to invert one's usual
> setting for vc-prepare-patches-separately?  Most people who contribute
> to more than one project regularly will want to use both.

How would this be preferable to setting `vc-prepare-patches-separately'
as a directory local variable?  That way you don't have to remember to
use a prefix argument whenever invoking `vc-prepare-patch'.

> On the other hand, having a numeric prefix argument mean "send patches
> correspoding to the top N revisions of the current branch" would be very
> convenient.  Perhaps these two could be combined by using a negative
> number to mean also invert?

This is the usual problem with numeric prefix arguments.  You don't get
that much expressivity with just an integer.

That is why I would hesitate to assign any particular interpretation to
prefix arguments, before considering and weighing the options.

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Fri, 04 Nov 2022 22:21:22 +0000

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

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> Hello,
>>
>> How about a prefix argument to vc-prepare-patch to invert one's usual
>> setting for vc-prepare-patches-separately?  Most people who contribute
>> to more than one project regularly will want to use both.
>
> How would this be preferable to setting `vc-prepare-patches-separately'
> as a directory local variable?  That way you don't have to remember to
> use a prefix argument whenever invoking `vc-prepare-patch'.
>
>> On the other hand, having a numeric prefix argument mean "send patches
>> correspoding to the top N revisions of the current branch" would be very
>> convenient.  Perhaps these two could be combined by using a negative
>> number to mean also invert?
>
> This is the usual problem with numeric prefix arguments.  You don't get
> that much expressivity with just an integer.
>
> That is why I would hesitate to assign any particular interpretation to
> prefix arguments, before considering and weighing the options.

Ping?

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 06 Nov 2022 14:44:08 -0700

Hello Philip,

Not sure what input is wanted from me.  Happy to think through anything
in particular you were waiting to hear from me about?

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 06 Nov 2022 21:49:20 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello Philip,
>
> Not sure what input is wanted from me.  Happy to think through anything
> in particular you were waiting to hear from me about?

I was wondering if you had any comments on my last message:

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> How about a prefix argument to vc-prepare-patch to invert one's usual
> setting for vc-prepare-patches-separately?  Most people who contribute
> to more than one project regularly will want to use both.

How would this be preferable to setting `vc-prepare-patches-separately'
as a directory local variable?  That way you don't have to remember to
use a prefix argument whenever invoking `vc-prepare-patch'.

> On the other hand, having a numeric prefix argument mean "send patches
> correspoding to the top N revisions of the current branch" would be
> very
> convenient.  Perhaps these two could be combined by using a negative
> number to mean also invert?

This is the usual problem with numeric prefix arguments.  You don't get
that much expressivity with just an integer.

That is why I would hesitate to assign any particular interpretation to
prefix arguments, before considering and weighing the options.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Mon, 07 Nov 2022 16:06:29 -0700

Hello,

On Sun 09 Oct 2022 at 12:54PM GMT, Philip Kaludercic wrote:

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> Hello,
>>
>> How about a prefix argument to vc-prepare-patch to invert one's usual
>> setting for vc-prepare-patches-separately?  Most people who contribute
>> to more than one project regularly will want to use both.
>
> How would this be preferable to setting `vc-prepare-patches-separately'
> as a directory local variable?  That way you don't have to remember to
> use a prefix argument whenever invoking `vc-prepare-patch'.

Makes sense.

>> On the other hand, having a numeric prefix argument mean "send patches
>> correspoding to the top N revisions of the current branch" would be very
>> convenient.  Perhaps these two could be combined by using a negative
>> number to mean also invert?
>
> This is the usual problem with numeric prefix arguments.  You don't get
> that much expressivity with just an integer.
>
> That is why I would hesitate to assign any particular interpretation to
> prefix arguments, before considering and weighing the options.

Well, any other options in mind?  Varying the -N argument to
git-format-patch/git-send-email is what I find myself using the most.

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Tue, 08 Nov 2022 20:31:14 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

>>> On the other hand, having a numeric prefix argument mean "send patches
>>> correspoding to the top N revisions of the current branch" would be very
>>> convenient.  Perhaps these two could be combined by using a negative
>>> number to mean also invert?
>>
>> This is the usual problem with numeric prefix arguments.  You don't get
>> that much expressivity with just an integer.
>>
>> That is why I would hesitate to assign any particular interpretation to
>> prefix arguments, before considering and weighing the options.
>
> Well, any other options in mind?  Varying the -N argument to
> git-format-patch/git-send-email is what I find myself using the most.

The issue is finding a way for this to be expressed VC-generically.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Tue, 08 Nov 2022 14:00:31 -0700

Hello,

On Tue 08 Nov 2022 at 08:31PM GMT, Philip Kaludercic wrote:

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>>>> On the other hand, having a numeric prefix argument mean "send patches
>>>> correspoding to the top N revisions of the current branch" would be very
>>>> convenient.  Perhaps these two could be combined by using a negative
>>>> number to mean also invert?
>>>
>>> This is the usual problem with numeric prefix arguments.  You don't get
>>> that much expressivity with just an integer.
>>>
>>> That is why I would hesitate to assign any particular interpretation to
>>> prefix arguments, before considering and weighing the options.
>>
>> Well, any other options in mind?  Varying the -N argument to
>> git-format-patch/git-send-email is what I find myself using the most.
>
> The issue is finding a way for this to be expressed VC-generically.

s/expressed/implemented/, right?

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Wed, 09 Nov 2022 08:28:59 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> On Tue 08 Nov 2022 at 08:31PM GMT, Philip Kaludercic wrote:
>
>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>
>>>>> On the other hand, having a numeric prefix argument mean "send patches
>>>>> correspoding to the top N revisions of the current branch" would be very
>>>>> convenient.  Perhaps these two could be combined by using a negative
>>>>> number to mean also invert?
>>>>
>>>> This is the usual problem with numeric prefix arguments.  You don't get
>>>> that much expressivity with just an integer.
>>>>
>>>> That is why I would hesitate to assign any particular interpretation to
>>>> prefix arguments, before considering and weighing the options.
>>>
>>> Well, any other options in mind?  Varying the -N argument to
>>> git-format-patch/git-send-email is what I find myself using the most.
>>
>> The issue is finding a way for this to be expressed VC-generically.
>
> s/expressed/implemented/, right?

I meant expressed, but I don't remember what I meant ^^

So let's say implement.  What we could do is just call
`previous-revision' for the backend N times, but with what file?

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Wed, 09 Nov 2022 09:36:36 -0700

Hello,

On Wed 09 Nov 2022 at 08:28AM GMT, Philip Kaludercic wrote:

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> Hello,
>>
>> On Tue 08 Nov 2022 at 08:31PM GMT, Philip Kaludercic wrote:
>>
>>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>>
>>>>>> On the other hand, having a numeric prefix argument mean "send patches
>>>>>> correspoding to the top N revisions of the current branch" would be very
>>>>>> convenient.  Perhaps these two could be combined by using a negative
>>>>>> number to mean also invert?
>>>>>
>>>>> This is the usual problem with numeric prefix arguments.  You don't get
>>>>> that much expressivity with just an integer.
>>>>>
>>>>> That is why I would hesitate to assign any particular interpretation to
>>>>> prefix arguments, before considering and weighing the options.
>>>>
>>>> Well, any other options in mind?  Varying the -N argument to
>>>> git-format-patch/git-send-email is what I find myself using the most.
>>>
>>> The issue is finding a way for this to be expressed VC-generically.
>>
>> s/expressed/implemented/, right?
>
> I meant expressed, but I don't remember what I meant ^^
>
> So let's say implement.  What we could do is just call
> `previous-revision' for the backend N times, but with what file?

I don't know, but the meaning of "the past N checked-in revisions of the
whole tree" is what we need to agree upon, then it's just coding.

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Wed, 09 Nov 2022 17:46:50 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> On Wed 09 Nov 2022 at 08:28AM GMT, Philip Kaludercic wrote:
>
>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>
>>> Hello,
>>>
>>> On Tue 08 Nov 2022 at 08:31PM GMT, Philip Kaludercic wrote:
>>>
>>>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>>>
>>>>>>> On the other hand, having a numeric prefix argument mean "send patches
>>>>>>> correspoding to the top N revisions of the current branch" would be very
>>>>>>> convenient.  Perhaps these two could be combined by using a negative
>>>>>>> number to mean also invert?
>>>>>>
>>>>>> This is the usual problem with numeric prefix arguments.  You don't get
>>>>>> that much expressivity with just an integer.
>>>>>>
>>>>>> That is why I would hesitate to assign any particular interpretation to
>>>>>> prefix arguments, before considering and weighing the options.
>>>>>
>>>>> Well, any other options in mind?  Varying the -N argument to
>>>>> git-format-patch/git-send-email is what I find myself using the most.
>>>>
>>>> The issue is finding a way for this to be expressed VC-generically.
>>>
>>> s/expressed/implemented/, right?
>>
>> I meant expressed, but I don't remember what I meant ^^
>>
>> So let's say implement.  What we could do is just call
>> `previous-revision' for the backend N times, but with what file?
>
> I don't know, but the meaning of "the past N checked-in revisions of the
> whole tree" is what we need to agree upon, then it's just coding.

The critical edge-case here is what happens when branches are merged.
Do you pick a random branch or collect all the patches.  Or do you raise
an error, but then how do you detect that vc-generically. 

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Wed, 09 Nov 2022 13:56:55 -0700

Hello,

On Wed 09 Nov 2022 at 05:46PM GMT, Philip Kaludercic wrote:

> The critical edge-case here is what happens when branches are merged.
> Do you pick a random branch or collect all the patches.  Or do you raise
> an error, but then how do you detect that vc-generically.

Typically you wouldn't want to format patches across a merge, so I would
suggest raising an error.

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Thu, 10 Nov 2022 20:14:02 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> On Wed 09 Nov 2022 at 05:46PM GMT, Philip Kaludercic wrote:
>
>> The critical edge-case here is what happens when branches are merged.
>> Do you pick a random branch or collect all the patches.  Or do you raise
>> an error, but then how do you detect that vc-generically.
>
> Typically you wouldn't want to format patches across a merge, so I would
> suggest raising an error.

And this is something I don't think can be /expressed/ using vc, because
while I can collect a number of revisions using `previous-revision',
there is no general way to verify if a commit is a merge commit.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Thu, 10 Nov 2022 17:07:03 -0700

Hello,

On Thu 10 Nov 2022 at 08:14PM GMT, Philip Kaludercic wrote:

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>> Hello,
>>
>> On Wed 09 Nov 2022 at 05:46PM GMT, Philip Kaludercic wrote:
>>
>>> The critical edge-case here is what happens when branches are merged.
>>> Do you pick a random branch or collect all the patches.  Or do you raise
>>> an error, but then how do you detect that vc-generically.
>>
>> Typically you wouldn't want to format patches across a merge, so I would
>> suggest raising an error.
>
> And this is something I don't think can be /expressed/ using vc, because
> while I can collect a number of revisions using `previous-revision',
> there is no general way to verify if a commit is a merge commit.

Can we do that part on a VCS-by-VCS basis?  Default to just calling
previous-revision and hoping for the best, but giving vc-git.el a chance
to raise an error.

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Fri, 11 Nov 2022 06:32:06 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

>>> Typically you wouldn't want to format patches across a merge, so I would
>>> suggest raising an error.
>>
>> And this is something I don't think can be /expressed/ using vc, because
>> while I can collect a number of revisions using `previous-revision',
>> there is no general way to verify if a commit is a merge commit.
>
> Can we do that part on a VCS-by-VCS basis?  Default to just calling
> previous-revision and hoping for the best, but giving vc-git.el a chance
> to raise an error.

I guess that would be possible, though it will probably require a new
VC method :/  The new `prepare-patch' takes a revision, so it doesn't
make sense to pass it a number and have it return multiple patches.

Perhaps it will be easier/cleaner to just accept that avoiding merge
revisions is the users responsibility.

But just to have mentioned it:  Do you know that you can mark revisions
in log-view and then vc-prepare-patches will use these as the default
input when prompting for revisions?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: philipk <at> posteo.net, 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50;
 Make it easier to invert vc-prepare-patches-separately
Date: Fri, 11 Nov 2022 09:34:42 +0200

> Cc: 58383 <at> debbugs.gnu.org
> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Thu, 10 Nov 2022 17:07:03 -0700
> 
> >> On Wed 09 Nov 2022 at 05:46PM GMT, Philip Kaludercic wrote:
> >>
> >>> The critical edge-case here is what happens when branches are merged.
> >>> Do you pick a random branch or collect all the patches.  Or do you raise
> >>> an error, but then how do you detect that vc-generically.
> >>
> >> Typically you wouldn't want to format patches across a merge, so I would
> >> suggest raising an error.
> >
> > And this is something I don't think can be /expressed/ using vc, because
> > while I can collect a number of revisions using `previous-revision',
> > there is no general way to verify if a commit is a merge commit.
> 
> Can we do that part on a VCS-by-VCS basis?  Default to just calling
> previous-revision and hoping for the best, but giving vc-git.el a chance
> to raise an error.

Please don't forget that Git's notion and implementation of
merge-commits is (AFAIR) quite unique.  I'm not sure there's another
VCS which handles merge-commits like Git does.

So when you build your notion of what merge-commit is and how to deal
with it in the context of this issue, I think it is best to study what
the other VCSes do, before you base the design on what Git does.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Fri, 11 Nov 2022 13:53:53 -0700

Hello,

On Fri 11 Nov 2022 at 06:32AM GMT, Philip Kaludercic wrote:

> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>
>>>> Typically you wouldn't want to format patches across a merge, so I would
>>>> suggest raising an error.
>>>
>>> And this is something I don't think can be /expressed/ using vc, because
>>> while I can collect a number of revisions using `previous-revision',
>>> there is no general way to verify if a commit is a merge commit.
>>
>> Can we do that part on a VCS-by-VCS basis?  Default to just calling
>> previous-revision and hoping for the best, but giving vc-git.el a chance
>> to raise an error.
>
> I guess that would be possible, though it will probably require a new
> VC method :/  The new `prepare-patch' takes a revision, so it doesn't
> make sense to pass it a number and have it return multiple patches.
>
> Perhaps it will be easier/cleaner to just accept that avoiding merge
> revisions is the users responsibility.

Sounds reasonable -- it can always be enhanced later in a way that's
backwards-compatible.

> But just to have mentioned it: Do you know that you can mark revisions
> in log-view and then vc-prepare-patches will use these as the default
> input when prompting for revisions?

Yeah, but marking in those buffers is way more awkward than marking in,
e.g., dired, and I usually know how many commits I want to send without
looking at the log.

-- 
Sean Whitton

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 13 Nov 2022 13:56:38 +0000

[Message part 1 (text/plain, inline)]

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> On Fri 11 Nov 2022 at 06:32AM GMT, Philip Kaludercic wrote:
>
>> Sean Whitton <spwhitton <at> spwhitton.name> writes:
>>
>>>>> Typically you wouldn't want to format patches across a merge, so I would
>>>>> suggest raising an error.
>>>>
>>>> And this is something I don't think can be /expressed/ using vc, because
>>>> while I can collect a number of revisions using `previous-revision',
>>>> there is no general way to verify if a commit is a merge commit.
>>>
>>> Can we do that part on a VCS-by-VCS basis?  Default to just calling
>>> previous-revision and hoping for the best, but giving vc-git.el a chance
>>> to raise an error.
>>
>> I guess that would be possible, though it will probably require a new
>> VC method :/  The new `prepare-patch' takes a revision, so it doesn't
>> make sense to pass it a number and have it return multiple patches.
>>
>> Perhaps it will be easier/cleaner to just accept that avoiding merge
>> revisions is the users responsibility.
>
> Sounds reasonable -- it can always be enhanced later in a way that's
> backwards-compatible.
>
>> But just to have mentioned it: Do you know that you can mark revisions
>> in log-view and then vc-prepare-patches will use these as the default
>> input when prompting for revisions?
>
> Yeah, but marking in those buffers is way more awkward than marking in,
> e.g., dired, and I usually know how many commits I want to send without
> looking at the log.

How does the following look like:

[Message part 2 (text/plain, inline)]

diff --git a/lisp/vc/vc.el b/lisp/vc/vc.el
index 513fbb23fe..0b8a8d83e3 100644
--- a/lisp/vc/vc.el
+++ b/lisp/vc/vc.el
@@ -3391,14 +3391,24 @@ vc-prepare-patch
 as the default subject for the message (and it will be prompted
 for when called interactively).  Otherwise a separate message
 will be composed for each revision, with SUBJECT derived from the
-invidividual commits.
-
-When invoked interactively in a Log View buffer with marked
-revisions, those revisions will be used."
+invidividual commits.  When invoked with a numerical prefix
+argument, the last N revisions will be used.  When invoked
+interactively in a Log View buffer with marked revisions, those
+revisions will be used."
   (interactive
    (let ((revs (vc-read-multiple-revisions
                 "Revisions: " nil nil nil
-                (or (and-let* ((revs (log-view-get-marked)))
+                (or (and-let* ((arg current-prefix-arg)
+                               (fs (vc-deduce-fileset t)))
+                      (cl-loop with file = (caadr fs)
+                               repeat (prefix-numeric-value arg)
+                               for rev = (vc-working-revision file)
+                               then (vc-call-backend
+                                     (car fs) 'previous-revision
+                                     file rev)
+                               when rev collect it into revs
+                               finally return (mapconcat #'identity revs ",")))
+                    (and-let* ((revs (log-view-get-marked)))
                       (mapconcat #'identity revs ","))
                     (and-let* ((file (buffer-file-name)))
                       (vc-working-revision file)))))

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 13 Nov 2022 16:06:58 +0000

[Message part 1 (text/plain, inline)]

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

> How does the following look like:

I have prepared a proper patch:

[0001-Have-vc-prepare-patch-handle-prefix-arguments.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#58383: 29.0.50;
 Make it easier to invert vc-prepare-patches-separately
Date: Sun, 13 Nov 2022 18:35:37 +0200

> Cc: 58383 <at> debbugs.gnu.org
> From: Philip Kaludercic <philipk <at> posteo.net>
> Date: Sun, 13 Nov 2022 13:56:38 +0000
> 
> --- a/lisp/vc/vc.el
> +++ b/lisp/vc/vc.el
> @@ -3391,14 +3391,24 @@ vc-prepare-patch
>  as the default subject for the message (and it will be prompted
>  for when called interactively).  Otherwise a separate message
>  will be composed for each revision, with SUBJECT derived from the
> -invidividual commits.
> -
> -When invoked interactively in a Log View buffer with marked
> -revisions, those revisions will be used."
> +invidividual commits.  When invoked with a numerical prefix
> +argument, the last N revisions will be used.  When invoked
> +interactively in a Log View buffer with marked revisions, those
> +revisions will be used."

Can we take this opportunity to get rid of the passive voice and
clarify the doc string, please?

Thanks.

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58383 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 13 Nov 2022 16:45:26 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Can we take this opportunity to get rid of the passive voice and
> clarify the doc string, please?

Done:

[0001-Have-vc-prepare-patch-handle-prefix-arguments.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 13 Nov 2022 18:52:11 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: spwhitton <at> spwhitton.name,  58383 <at> debbugs.gnu.org
> Date: Sun, 13 Nov 2022 16:45:26 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Can we take this opportunity to get rid of the passive voice and
> > clarify the doc string, please?
> 
> Done:

Thanks, and the same with package-vc-prepare-patch, please?

Btw, this kind of reformatting:

> -SUBJECT and REVISIONS are passed on to `vc-prepare-patch', which see.
> -PKG must be a package description.
> -Interactively, prompt for PKG, SUBJECT, and REVISIONS.  However,
> -if the current buffer has marked commit log entries, REVISIONS
> -are the tags of the marked entries, see `log-view-get-marked'."
> +SUBJECT and REVISIONS are passed on to `vc-prepare-patch', which
> +see.  PKG must be a package description.  Interactively, prompt
> +for PKG, SUBJECT, and REVISIONS.  When invoked with a numerical
> +prefix argument, the last N revisions will be used.  When invoked
> +interactively in a Log View buffer with marked revisions, those
> +revisions will be used."

is IMO for the worse: when the sentence starting with "Interactively"
begins a new line, it stands out, which helps users find the most
relevant parts faster.

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

From: Philip Kaludercic <philipk <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58383 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Sun, 13 Nov 2022 18:17:43 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: spwhitton <at> spwhitton.name,  58383 <at> debbugs.gnu.org
>> Date: Sun, 13 Nov 2022 16:45:26 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Can we take this opportunity to get rid of the passive voice and
>> > clarify the doc string, please?
>> 
>> Done:
>
> Thanks, and the same with package-vc-prepare-patch, please?
>
> Btw, this kind of reformatting:
>
>> -SUBJECT and REVISIONS are passed on to `vc-prepare-patch', which see.
>> -PKG must be a package description.
>> -Interactively, prompt for PKG, SUBJECT, and REVISIONS.  However,
>> -if the current buffer has marked commit log entries, REVISIONS
>> -are the tags of the marked entries, see `log-view-get-marked'."
>> +SUBJECT and REVISIONS are passed on to `vc-prepare-patch', which
>> +see.  PKG must be a package description.  Interactively, prompt
>> +for PKG, SUBJECT, and REVISIONS.  When invoked with a numerical
>> +prefix argument, the last N revisions will be used.  When invoked
>> +interactively in a Log View buffer with marked revisions, those
>> +revisions will be used."
>
> is IMO for the worse: when the sentence starting with "Interactively"
> begins a new line, it stands out, which helps users find the most
> relevant parts faster.

Addressed both issues here:

[0001-Have-vc-prepare-patch-handle-prefix-arguments.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

That being said, the patch now relies on changes made in
scratch/package-vc-fixes.  I can "backport" it onto master, or push it
in a few days when the issues related to that branch are resolved.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 58383 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Mon, 14 Nov 2022 14:41:55 +0200

> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: spwhitton <at> spwhitton.name,  58383 <at> debbugs.gnu.org
> Date: Sun, 13 Nov 2022 18:17:43 +0000
> 
> Addressed both issues here:

Thanks!

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58383 <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Tue, 15 Nov 2022 17:04:10 -0700

Hello,

Just based on reviewing the docstrings, lgtm.  Thank you for your
interest in my idea.

-- 
Sean Whitton

Message #84 received at 58383-done <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 58383-done <at> debbugs.gnu.org
Subject: Re: bug#58383: 29.0.50; Make it easier to invert
 vc-prepare-patches-separately
Date: Wed, 16 Nov 2022 07:50:21 +0000

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> Hello,
>
> Just based on reviewing the docstrings, lgtm.  Thank you for your
> interest in my idea.

Great, I'll close the issue then.  The patch will be pushed along with
some package-vc related changes in the next new days.

Previous Next

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