Subject: Re: bug#57400: 29.0.50; Support sending patches from VC directly

From: Philip Kaludercic <[email-masked]>
Date: Fri, 07 Oct 2022 08:03:42 +0000

Dmitry Gutov <[email-masked]> writes:

> Hi Philip,
>
> On 06.10.2022 15:38, Philip Kaludercic wrote:
>> I'm glad to hear that.  Here is the updated patch:
>
> This version resolves the main questions I had as well.
>
> Here's one more, though: the way I normally used 'git format-patch' is
> I pass just one ref, and that's usually the name of the branch to
> start the history at (the <since> argument from the manual). So I
> never had to "type revisions in the Git syntax" for this to work,
> something Eli was worried about.

It might be tricky to do this in a VC-generic way, but what I can think
of would be if the command is invoked with a prefix argument, then
instead of querying for specific revisions, we query for one only, then
use 'next-revision' to check if it is a predecessor of the current
revision.  If so, all the commits in-between are used.

The main issue I see here is that 'next-revision' requires a file
argument.  What should that be?

> Should this new command support this usage as well?
>
> The range of revisions could be fetched by passing the base revision
> as LIMIT to the 'print-log' action (like vc-log-mergebase does), but
> how the updated calling convention for vc-prepare-patch will look is
> not obvious to me.

Even if we do this, the value of the argument "files" still remains an
open question.

It is for this reason that I prefer the current approach, especially
when combined with the ability to select commits in a log.