GNU bug report logs - #64055
31.0.50; log-view-modify-change-comment support for Git and Hg

Previous Next

Full log

Message #68 received at 64055 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Robert Pluim <rpluim <at> gmail.com>, 
 Morgan Smith <Morgan.J.Smith <at> outlook.com>, 64055 <at> debbugs.gnu.org
Subject: Re: bug#64055: [WIP Patch] Enable editing commit messages -
 vc-git-modify-change-comment
Date: Fri, 18 Oct 2024 03:46:36 +0300

Hi! Sorry for the late reply, I've been driving a lot the last week.

On 10/10/2024 05:39, Sean Whitton wrote:
> In Dmitry's patch he takes the approach of calling the
> expanded-log-entry backend function to get the message to edit.
> This is not a real VC backend function -- in fact it's a log-view
> feature, log-view-expanded-log-entry-function.

It is, but it is also basically a backend method, i.e. in vc-git.el:

    (setq-local log-view-expanded-log-entry-function
                'vc-git-expanded-log-entry))

So if we determined that its output could be used for editing, perhaps 
after some massaging (e.g. reindenting and keeping only a subset of the 
headers), that could be a minor win -- fewer methods is better in 
general. I haven't tried to code it, so there could be pitfalls.

Also note that we have 'rfc822-goto-eoh' which can be used to skip to 
the end of the headers. 'log-edit-extract-headers' could be used as 
reference for extracting "Summary", even if it doesn't exactly give us 
the desired info now.

> So one thing we could do is add a VC backend action which returns just
> the message text that a human might want to edit.
> Probably a backend action called `get-change-comment'.

The new vc-git-get-change-comment seems good in terms of functionality. 
I was thinking that the headers such as Author, No-Verify and Sign-Off, 
might be good to show as well, but as long as their values are intact 
after the edit, that's optional.

> I think, though, that there might be subtle complexities there.  For
> example, should there be a FILES argument, or just a REVISION argument?
> For Git and Hg it's just REVISION, but we wouldn't want to bake that in.

Makes sense, e.g. if we end up supporting per-file backends later.

Previous Next

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