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

[Sean Whitton <spwhitton@spwhitton.name>]

Hello,

On Mon 21 Oct 2024 at 08:56pm +01, Dmitry Gutov wrote:

> On 21/10/2024 08:46, Sean Whitton wrote:
>> On Mon 21 Oct 2024 at 08:39am +03, Eli Zaretskii wrote:
>>
>>> 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.
>> Mainly the terminology.
>> If others think it is fine to go ahead and call the defcustom
>> vc-allow-rewriting-history, I am happy to do so.
>
> Speaking of Git terminology, "rewriting history" can refer to both rewriting
> published commits (often frowned upon) and rewriting local history (can be
> fine and is often encouraged). The proposed name seems to conflate the two
> (although the docstring does clarify that it's referring to the former).
>
> In practice, this also often depends on the upstream branch - e.g. a branch
> "feature/xyz" worked on a single developer might be fine with force-pushes.

Yeah.  I'll use vc-allow-rewriting-published-history.  It's not perfect
but it does a better job covering these various issues.

> I guess my point was we could do with only a prompt warning the user that the
> published history will be rewritten (proceeding on if they agree). Showing an
> error is a safer choice, but I suppose then the error message could reference
> the option to customize.

I think that's what's implemented, except for referencing the option
name, which I'll add, thanks.

-- 
Sean Whitton