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

[Sean Whitton <spwhitton@spwhitton.name>]

Hello,

On Mon 21 Oct 2024 at 01:09am +01, Dmitry Gutov wrote:

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

I think it is probably okay to keep vc-git-allow-rewriting-history even
if we decide to deprecate it in favour of a more general variable at
some point.

> Otherwise, seems to work well, even though, as you said, a bit slower than one
> might naively expect.

Ah, thank you for testing.

I'm not whether the slowness is coming from the safety check in
vc-git--assert-allowed-rewrite or from the rebase command, or both.  I
do know that rebases don't tend to be fast.

-- 
Sean Whitton