RFC: Possibility to re-edit last commit message

[John Arbash Meinel]

Martin Pool wrote:
...

> So it looks like people agreed this shouldn't alter the files included
> in the revision, only the revision metadata: mostly the message, but I
> suppose possibly also the committer or date.  If you want to change the
> contents of the tree it's probably best to uncommit and recommit, since
> in this case you might well want to edit files as well as including or
> excluding them.

Well, I would like to change the file list/contents more than I would
want to change the message, but that is my workflow. I don't know how
common it is.

> 
> I like Robert's idea of adding a revision property that says that it
> supersedes the removed message.

I think it is an interesting thought, but there is a lot more that we
have to consider before we know if it is possible.

Does it change revision numbering? Or does it just skip one. So if you do:

bzr log -r -3..-1

And you have 2 commits which supersede, would logging 3 revisions only
show you 1?

If it does change revision numbering (sort of 'skipping' the other
revisions) then this effects merge_sort, which means it now needs to
take Revision objects, rather than just a revision graph.

Either that, or this sort of information would need to be included in
the knit index, so you know what revisions are considered 'skipped'
before you build up the graph.

It seems a lot simpler to just do "uncommit + commit a new revision"
than to try and move a revision into being a suppressed merge revision.

> 
> This has some things in common with commit: it (internally) makes a new
> revision, and takes options giving a message.  On the other hand it does
> not take the file options, and from the user's point of view it's quite
> different.
> 
> darcs has 'amend-commit' as a separate command.  Maybe 'fix-commit' or
> 'correct' would be a clear name.  I think 'amend' is ok though.
> 
> We should structure the commit code to avoid duplicating special
> handling of checkouts etc.
> 

Certainly we should not have duplication between whatever amend code and
our regular 'commit' code.

Also, because of how file knit indices are used, it needs to update all
of them as well with the new revision id. Technically it could actually
point to the old delta contents if we wanted to be extra intelligent,
but that probably isn't really worth the effort of just re-creating the
values.

Note that content-based addressing (git) has it a bit easier because
file contents are accessed by the same key, even if the commit is
amended. The trade off is that git does not have per-file change
indices. Instead it has to go to the changelog to know what files were
changed in what commit. And unless I miss my guess this is an index from
revision_id => files, which means you have to parse the whole file when
doing a 'git log filename', whereas theoretically 'bzr log filename' can
read one index and report the results. (Well, I guess 2 since it needs
the revisions as specified by the Branch, and then the interesection
against the revisions for the file)

I still feel like having a separate 'changelog' file is a net win, verus
assuming that the serialized Inventory deltas contain enough
information. The tradeoff is a redundancy between taking 2 full
Inventories and doing a delta versus what is stored in the changelog (so
they theoretically could disagree), versus requiring that the storage
layer create deltas that contain the full pre+post information. (Current
Knit format does not, as it only contains enough info to apply it to a
previous text, but you cannot reverse apply the deltas).

John
=:->