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

[Eli Zaretskii]

> Cc: 58383@debbugs.gnu.org
> From: Sean Whitton <spwhitton@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.