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

Previous Next

Package: emacs;

Reported by: Morgan Smith <Morgan.J.Smith <at> outlook.com>

Date: Tue, 13 Jun 2023 23:05:02 UTC

Severity: normal

Tags: patch

Found in version 27.0.50

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Eli Zaretskii <eliz <at> gnu.org>
Cc: Morgan.J.Smith <at> outlook.com, 64055 <at> debbugs.gnu.org
Subject: bug#64055: Implementation of modifying VC change comments for Git
Date: Mon, 21 Oct 2024 20:56:31 +0100
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.

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.




This bug report was last modified 104 days ago.

Previous Next


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