[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is it time to drop ChangeLogs?

From: Nikolaus Rath
Subject: Re: Is it time to drop ChangeLogs?
Date: Fri, 11 Mar 2016 09:17:02 -0800
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)

On Mar 11 2016, Eli Zaretskii <address@hidden> wrote:
>> From: Richard Stallman <address@hidden>
>> CC: address@hidden, address@hidden, address@hidden
>> Date: Thu, 10 Mar 2016 16:23:48 -0500
>> Even though Git does not permit editing a commit message _as such_, we
>> can provide, at a higher level, a way to correct old commit messages.
>> Maintaining a ChangeLog file in the repository is one way to do this,
>> but if it has flaws in the case of merging, can we design another mechanism
>> for the job that solves the problems with merging?
> The known mechanisms are user-unfriendly, in that they require to
> write the corrections as editing commands for Perl or some other
> Sed-like facility.  This is too error prone for a feature that should
> be usable by non-experts.
> A facility that could be considered is one that allows to type the
> correction as plain text which should replace the existing text in the
> Git log.  We haven't found such a facility yet.  "git replace" sounds
> like a promising alternative, though.

I think the low-tech option of a "commit-msg-override" directory with
one (updated) commit message per file (and the file name being the hash
of the commit being updated) is also still on the table.

This directory could be trivially checked by whatever tool will be used
to turn the git log into a ChangeLog file.


GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«

reply via email to

[Prev in Thread] Current Thread [Next in Thread]