bug#64055: Implementation of modifying VC change comments for Git

[Eli Zaretskii <eliz@gnu.org>]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Morgan.J.Smith@outlook.com,
>   64055@debbugs.gnu.org
> Date: Mon, 21 Oct 2024 10:01:28 +0800
> 
> > On 20/10/2024 08:19, Sean Whitton wrote:
> >> +*** New user option 'vc-git-allow-rewriting-history'.
> >> +Many Git commands can change your copy of published change history
> >> +without warning.  If VC commands detect that this could happen, they
> >> +will stop.  You can customize this variable to permit rewriting history
> >> +even though Emacs thinks it is dangerous.
> >
> > Curious: do we consider Git to be different from others? Or would we have
> > corresponding options for Hg, Bzr, (maybe) Svn?
> >
> > If we think rewriting history dangerous for all, we could mark the command as
> > 'disabled' instead.
> 
> I think that for some VCS editing the commit message is not a form of
> rewriting history in any sense.  And we can hope for a future VCS that
> keeps change histories for commit messages, so that we might easily
> correct our mistakes.  So I don't believe it would make sense to just
> disable log-view-modify-change-comment.
> 
> We might, though, want to consider a more general
> vc-allow-rewriting-history instead of vc-git-allow-rewriting-history,
> and use it wherever its applicable -- it will be VCS-dependent where
> exactly it applies.
> 
> I'm cautious about doing that without more information, because
> "rewriting history" is, in my mind, a Git-specific piece of terminology
> to begin with.

Which aspects of "rewriting history" you consider Git-specific?  I
think any dVCS has the same issues with that, and supports similar
workflows, so the concept is relevant to all of them.