RFC: Possibility to re-edit last commit message

[Martin Pool]

On  6 Feb 2007, John Arbash Meinel <john at arbash-meinel.com> wrote:

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

The way I saw it, it would basically uncommit and make a new commit.
However, we would also remember the removed revision id, so as to
possibly handle it better if someone else had already got a copy of it.
However this is pretty much an edge case.

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

That is an interesting point - yes it would, and this is of course what
happens if you recommit now.

> 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)

Since it is separated by directory they don't need to look at the whole
inventory every time, but yes as far as I know there is no inverse
index.

-- 
Martin