bug#58383: 29.0.50; Make it easier to invert vc-prepare-patches-separately

[Sean Whitton]

Hello,

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

> Sean Whitton <spwhitton@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