GNU bug report logs - #57400
29.0.50; Support sending patches from VC directly

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Robert Pluim <rpluim <at> gmail.com>, 57400 <at> debbugs.gnu.org, Antoine Kalmbach <ane <at> iki.fi>
Subject: bug#57400: 29.0.50; Support sending patches from VC directly
Date: Fri, 7 Oct 2022 15:56:54 +0300

On 07.10.2022 11:03, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov <at> 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

prefix argument? Ok. I would imagine this to be the "default" usage 
scenario, though.

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

<since> is not necessarily a predecessor: 'git format-patch master' 
works even when master has some more extra commits since the "merge 
base" commit. 'master' will point to the commit that's not present in 
the current branch.

But vc-log-mergebase is fine with such situation. It calls 
(vc-call-backend backend 'mergebase rev1 rev2) to find the most recent 
common revision, and start after it.

> The main issue I see here is that 'next-revision' requires a file
> argument.  What should that be?

The 'mergebase' and 'print-log' actions don't seem to require it.

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

vc-log-mergebase passes (list rootdir) as FILES to 'print-log'.

> It is for this reason that I prefer the current approach, especially
> when combined with the ability to select commits in a log.

I'm definitely not going to insist: I'm not the target audience of this 
feature.

Previous Next

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