[MERGE] Fix #306879 by mentioning the base revision id in the 'BASE' conflict marker lines
aaron at aaronbentley.com
Tue Dec 16 20:27:30 GMT 2008
Vincent Ladeuil wrote:
>>>>>> "aaron" == Aaron Bentley <aaron at aaronbentley.com> writes:
> aaron> Vincent Ladeuil wrote:
> >> Simple fix which add the revid of the base revision after the
> >> 'BASE-REVISION' marker.
> aaron> I'd rather not use revision-ids where we can avoid it.
> I rather not use dotted revnos where I can avoid it until we know
> how to calculate them without being O(history).
As a project, it's been our consistent UI policy not to expose file-ids
or revision ids unless the user specifically asked for them. Is there a
particular reason to change that policy in this case?
> aaron> Since we can use dotted revnos, I'd rather use them.
> Are you saying that merge as already calculated dotted revnos ?
> aaron> Additionally, your fix is bogus because it will emit a
> aaron> revision id when the basis tree is a working tree with
> aaron> uncommitted changes (ie merge --uncommitted).
> What is the revision base in that case ?
It is working_tree.last_revision in that case. I was mistaken.
It is perfectly valid, and supported by the code, to use a working tree
with uncommitted changes as a base. Such a tree has no meaningful
revid. But I don't believe the UI exposes that option at present.
More information about the bazaar