[MERGE] Status should not special case conflicts

[Robert Collins]

On Fri, 2006-07-14 at 01:49 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robert Collins wrote:
> > Status currently special cases showing of conflicts based on whether the
> > tree is the 'working tree' or not. In fact, all trees have conflicts()
> > methods, so there is no need to special case it - we just need to show
> > the conflicts from the new tree.
> 
> But.. but..
> 
> Conflicts often indicate that a tree is not in a versionable state, and
> they often refer to unversioned files.  I'd go so far as to say a
> RevisionTree cannot have conflicts by definition, because you can't
> commit when you have conflicts.

Uhm, I'm not sure that the presence of conflicts indications
unversionability at all. Certainly I know of use cases such as switching
machines - where doing a commit *with conflicts*, so as to be able to
pull that to somewhere else, where I would continue working - which have
versioning conflicted trees as a feature. We dont do it today, and I'm
not suggesting we should - but I am saying that the presence of
conflicts does not make any statement about the type of the tree.

> > Eventually I plan to make conflicts be exposed as part of the tree
> > delta, which then lets status be purely a display of a tree delta, which
> > is what we need for dirstate.
> 
> But conflicts aren't part of a delta.  You can't compare two
> RevisionTrees and get conflicts as a result.  Conflicts are a state of a
> tree, without reference to any other tree.

A Delta is by definition a description of the changes to tree state
required to transform tree A to tree B. If tree A has conflicts, and
tree B does not, then those conflicts are part of the changes required
to turn A into B - they have to be removed. 

> It's never been my model that status was all about comparing trees.
> I've thought of it as a collection of info, some comparison-based, like
> added files, some of it tree-based like conflicts or pending merges.

I've always found it weird that status -r
ancestor:../branch-that-I-just-merged shows any pending merges. Surely
as part of status I want the new revisions in this branch, and if there
are more than happen to be recorded on disk, or less, I want those
shown.

> Possibly the convenience of regular interfaces outweighs the weirdness
> of representing conflicts in the RevisionTree interface, but I'm not at
> all sure.  I'm pretty happy with WorkingTrees being different in kind.

RevisionTree already represents conflicts :). This patch just makes use
of it to make the status code simpler. However, please see my comments
above to see my views on the underlying logic.

Cheers,
Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060714/3b456820/attachment.pgp