Sean Whitton writes: > Hello, > > On Fri 11 Nov 2022 at 06:32AM GMT, Philip Kaludercic wrote: > >> Sean Whitton 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: