[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57400: 29.0.50; Support sending patches from VC directly
From: |
Philip Kaludercic |
Subject: |
bug#57400: 29.0.50; Support sending patches from VC directly |
Date: |
Fri, 07 Oct 2022 08:03:42 +0000 |
Dmitry Gutov <dgutov@yandex.ru> 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.
- bug#57400: 29.0.50; Support sending patches from VC directly, (continued)
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Robert Pluim, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Eli Zaretskii, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Juri Linkov, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/06
- bug#57400: 29.0.50; Support sending patches from VC directly,
Philip Kaludercic <=
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/07
- bug#57400: 29.0.50; Support sending patches from VC directly, Richard Stallman, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, German Pacenza, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Dmitry Gutov, 2022/10/08
- bug#57400: 29.0.50; Support sending patches from VC directly, Philip Kaludercic, 2022/10/08