[Top][All Lists]

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

Re: Is it time to drop ChangeLogs?

From: David Caldwell
Subject: Re: Is it time to drop ChangeLogs?
Date: Tue, 8 Mar 2016 13:27:15 -0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0

On 3/8/16 1:16 PM, Dmitry Gutov wrote:
> On 03/08/2016 10:56 PM, David Caldwell wrote:
>> Since notes seem like a no-go, what about taking the same approach but
>> using an empty commit to do it (`git commit --allow-empty`)? That way it
>> gets pushed and merged between branches just like normal.
> How would such commit indicate a relation to an existing commit?

I was thinking something along the lines of "reword: <HASH>" in the message.

> And after making it, you can't easily edit the result, you can only
> redo it fully.

Correct. Newest one wins.

> How about putting all corrections as plain files in a subdirectory? Each
> file will be named after a commit whose message it's "changing". IIRC,
> I've seen such idea mentioned before, and it seems like it should work.

Yeah, It would work as well. I just thought it would be nice to keep
meta-data corrections in the meta-data itself.

> We could even implement integration with vc-print-log without too much
> difficulty. The main thing to solve is the cherrypick commits (does the
> correction apply to whose? always?);

Cherry-picks would definitely require more effort.

> but as long as cherrypicks include the references to their parents in
> the message, it should be workable, one way or another.

I don't believe they do, by default. And if they need to be amended to
include that, you might as well amend to include the fixed commit-log


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

reply via email to

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