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

Previous Next

Full log

View this message in rfc822 format

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Morgan.J.Smith <at> outlook.com, rpluim <at> gmail.com, 64055 <at> debbugs.gnu.org, dmitry <at> gutov.dev
Subject: bug#64055: [WIP Patch] Enable editing commit messages - vc-git-modify-change-comment
Date: Sun, 20 Oct 2024 08:56:12 +0800

Hello,

On Fri 18 Oct 2024 at 03:18pm +03, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: 64055 <at> debbugs.gnu.org,  Morgan.J.Smith <at> outlook.com,  rpluim <at> gmail.com,
>>   dmitry <at> gutov.dev
>> Date: Fri, 18 Oct 2024 17:30:16 +0800
>>
>> The main point is that parsing text out of the log view buffer is much
>> more error-prone.  For example, with a non-distributed VCS like CVS,
>> what if someone else has edited the comment in the meantime?  It makes
>> sense to fetch the latest known version instead of relying on buffer
>> text.
>
> Now I'm confused: didn't you just tell me that CVS already had this
> implemented, without ever needing the new backend method?  How do we
> solve this problem in the CVS case without risking the errors?  What
> you say above seems to tell that we do need an implementation of this
> method for CVS as well, no?  Or what am I missing?
>
>> So, I hope that we will eventually completely replace
>> log-view-extract-comment.
>
> So you do agree with me that we should have this implemented for other
> backends, and the sooner the better?

The VC design principle here is that commands should be implemented for
more than one version control system, in part because that way we ensure
they really are general version control user operations, and not
something parochial to the way a particular VCS sees the world.

In the context of this bug, the relevant command for this design
principle is log-view-modify-change-comment.  Previously, that command
worked only for src, rcs, sccs, cvs and svn, and partly for Hg.  Soon it
will also work for git.  So, the design principle is respected.

On the other hand, the design principle doesn't apply directly to the
new get-change-comment backend action, because src, rcs, sccs, cvs and
svn do not *require* an implementation of get-change-comment in order
for the log-view-modify-change-comment command to work, so far as I
understand it -- otherwise the feature would not have been implemented
the way it is, or we'd have bug reports.

Git, I think, does require an implementation of get-change-comment, or
at least, I concluded that it's the most natural way to implement
log-view-modify-change-comment for git.

In a similar vein, non-distributed VCS require a receive-file backend
action, but it would not make sense to write a function
vc-git-receive-file.  The VC design principle does not apply directly to
backend actions.  For many backend actions, including
get-change-comment, only certain kinds of VCS will require an
implementation, in order to support the high-level VC user commands.

Nevertheless, although src, rcs, sccs, cvs and svn do not *require*
get-change-comment, I think it would be preferable if they did have an
implementation, instead of using log-view-extract-comment, for the
reasons given previously.  But we are talking about changing working
code.  We should not rush to replace log-view-extract-comment.  We can
do so incrementally and gradually, and it's low priority.

-- 
Sean Whitton

Previous Next

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