[MERGE] Fix #306879 by mentioning the base revision id in the 'BASE' conflict marker lines

Aaron Bentley 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 mailing list