[MERGE] Status should not special case conflicts

Aaron Bentley aaron.bentley at utoronto.ca
Fri Jul 14 06:49:28 BST 2006


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

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

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.

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.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtzBn0F+nu1YWqI0RApTpAJ0Vli4TS03XsU2aI+RWFXu/14ggMgCePBFZ
1UhPNBc+9GkOeabL4aMlgiw=
=TDqd
-----END PGP SIGNATURE-----




More information about the bazaar mailing list