RFC: Possibility to re-edit last commit message

[John Arbash Meinel]

Jari Aalto wrote:
> John Arbash Meinel <john at arbash-meinel.com> writes:
>>>> message could be re-edited
>>>>
>>>>     bzr ci --re-edit
>>>>
>>>> And that would bring up the editor just like last time. After exiting
>>>> the editor, that message would be updated (no files updated)
>>> But if someone has pulled the branch in the meantime, and you change
>>> the message without creating a new commit, you're in a world of pain.
>>> So just uncommit, edit the message and recommit. It might be nice to
>>> have a plugin that does it for you though.
>>>
>> I always thought of this as a "bzr recommit" command. Which could do 2
>> things.
>>
> [...]
>> For the message, if we spawned an editor with the old message, I could
>> always just accept it. But the command should support '-m' like the
>> current commit command does.
> 
> The reason why "bzr ci --re-edit" is imporartant is that there are many
> non-native speaker's that make typos and grammar mistakes all the time.
> We just don't notice them but only after looking the message second time
> (after the commit is already happened).
> 
> I don't know internals how the thing has been implemented, but
> culd the message have a minor version (flag?) that is incremented
> after each change. The log would only show the latest message, although
> the repository would just keep all messages..

...

This is basically 'versioned revision properties'. Which means that you
need a timeline/version space for the properties of revisions.
Conceptually this is a revision-id + number. But actually that doesn't work.

Because what do we do if you modify the commit message, and *I* modify
the same commit message. And then one of us pulls from the other one. At
this point, we now have conflicting data with the same "handle".

So now what you need is "revision-id + property-revision-id". You can
simplify the common case and have property-revision-id be NULL if it
hasn't been modified.

But it does mean you need a new file which is the annotations-of-history
file. And now it is possible to get conflicts (because 2 people can
change the same thing, so when they are brought together, you have a
conflict).

And when you are iterating through the logs to display them, you now
have to check the "annotations-of-history" file, just in case there is a
new version of the commit message.


Overall, the main difficulty is because we have a distributed system,
you have to be very careful that data is consistent when anyone can
change anything at any time. All of the DVCS's do that my assigning
unique identifiers (some use content-based sha1 hashes, others generate
new random uuids).

Regardless, this seemingly simple change actually has a lot of
long-reaching ramifications in a distributed system. So I will second
Larz's suggestions for: "Don't worry about it too much."

John
=:->