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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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