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

Previous Next

Full log

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 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: Tue, 01 Oct 2024 10:37:07 +0800

Hello,

On Sat 17 Jun 2023 at 05:40am +03, Dmitry Gutov wrote:

> We could do something like this: take the remote branch associated with the
> current branch, and its top commit. And then, somehow, see if the commit to be
> edited is reachable by traversing up history.
>
> There likely are some known Git snippets out there on SO or general Internet
> that do these steps, but I haven't looked yet.
>
> Anyway, we could do this check first thing inside vc-git-modify-change-comment
> and, when the operation is dangerous, doubly prompt the user whether they want
> to proceed.

I think that we refuse to proceed, or at least ask for confirmation,
in the case that the commit the user wants to edit does not appear in
*vc-outgoing* (C-x v O).

The difficulty of prompting is that the prompt has to be short to fit in
the echo area.  But something like

  This commit is published; are you sure you want to rewrite history?

is only explanatory to someone who already has a lot of git-specific
knowledge.  So, by default, we I think we should refuse to rewrite any
commit that does not appear in *vc-outgoing*.

Then there could be a defcustom to enable a yes/no prompt (or to enable
unconditionally rewriting).  In the docstring for the defcustom we could
provide a reference to the relevant git documentation, so the user can
find out what this notion of "rewriting history" is all about.

-- 
Sean Whitton

Previous Next

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