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

-David