[MERGE] Status should not special case conflicts

[Aaron Bentley]

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

Robert Collins wrote:
>> Robert Collins wrote:
>> 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.
> 
> I buy that these two forms of conflicts imply unversionable files. For
> 2. though, the contents of these files is no more or less unique than
> any other file - if there are two trees, their state, including content
> of files, can be compared, for all files with definable content.

For 2, the contents of these files is known, but cannot be predicted
from the contents of the two trees.  So in order to reproduce the
conflicted state, one would need to include unversioned files' contents
in the committed revision.  And in order to do that, one would need to
have some kind of identity that wasn't the file path, and wasn't the
file-id,  either.

>> 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.
> 
> This depends on what we desire to achieve with conflicts. One definition
> - the one this patch introduces - is that we just show the conflicts
> from the 'new' tree pair. We already have options to the delta generator
> to include all files, having one to include all conflicts - and have
> them marked as old|new|old&new seems easy to me.

Could you please explain what you desire to achieve with conflicts,
then?  I can't imagine a situation in which showing just the 'new'
conflicts would be desirable.

>> 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).
> 
> When we compare to a RevisionTree, sure - because RevisionTree is the
> ideal state. I dont buy that when we do status against a different
> WorkingTree that we would want to compare conflicts, and pending merges,
> against the 'ideal' state.

Status only compares against RevisionTrees.  But even if it compared
working trees, and you wanted conflict display, I'm certain you'd want
to display all the conflicts in each tree, not the subset that differed
between them.

>> 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?
> 
> See above for why I dont think we need this complexity, and how we can
> easily avoid it.

Sorry, I don't see how you're avoiding it.

>>> 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.
> 
> I think it is the cleanest way of getting all the status data we want,
> with the round trips or double handling, and no special casing. 

I think you're adding complexity to the model in order to achieve a
minor simplification of the codebase.  And in the end it doesn't
simplify things, because you wind up having to write new code to deal
with conflict deltas.

And what about conflict conflicts?  If you merge between two trees with
conflicts, you could get conflicts in foo.THIS, for example.

Special casing of special things always makes sense, and I think it
makes sense for conflicts to be special.

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

iD8DBQFEu33L0F+nu1YWqI0RAmx+AJ46yorhhmIlgrdwoJ1Q1q6FcrbG4gCcCU/E
SSm0Y0lpcRa9w0Sm8/oREF0=
=hdeF
-----END PGP SIGNATURE-----