[MERGE] Status should not special case conflicts

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Fri, 2006-07-14 at 01:49 -0400, Aaron Bentley wrote:

> Uhm, I'm not sure that the presence of conflicts indications
> unversionability at all.

They can.  Conflicts refer to unversioned files:

1. name conflicts can refer to an unverioned file that previously had
the name.  This file may be of a type that we cannot reproduce, e.g. a
devce file, fifo, etc.

2. contents conflicts imply the existence of foo.THIS, and foo.OTHER
files, and these files (particularly foo.THIS) are unversioned files
that may have unique contents.

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

That would imply that if you committed with conflicts, running status
afterward would produce no output, because both the basis tree and the
working tree have conflicts.  This does not seem useful.

The reason it's not useful is that we don't want to compare our conflict
state to another tree, we want to compare it to the ideal state (i.e. no
conflicts).

If conflicts are treated as part of the delta, then our current display
is a display of "new conflicts".  This means that we need to also
provide display of "modified conflicts" and "removed conflicts".  Which
means we also need to decide what conflict identity is: in what cases
should we emit a "modified conflict" versus a "new/removed" pair?

None of this display is particularly useful to users, because it's not
what conflicts are for.  And I don't think we want to go down this road.
 Yes, it's conceivable to represent conflicts as a delta, but it ignores
the purpose of conflicts to do so.

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

That can be fixed, and since you added it post 0.8, it can be fixed
without deprecating the methods.

> This patch just makes use
> of it to make the status code simpler.

Yes, but it entrenches a questionable interface, and that interface
implies that the status code is incomplete, because it's not displaying
removed conflicts or modified conflicts.

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

iD8DBQFEt7Kr0F+nu1YWqI0RAnElAJ4yj+LgD3PxLdTs1t9whJTec2a1EACfXHEX
62dLsbN1o0s06iHJ/KnWyzQ=
=4EsN
-----END PGP SIGNATURE-----