[MERGE] remerge doesn't clobber unrelated conflicts

[John Arbash Meinel]

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

Aaron Bentley wrote:
> John Arbash Meinel wrote:
> 
>>> Thanks for doing this. I'm have a little bit of trouble understanding
>>> what the actual fix is, because some of your comments seem to conflict
>>> with the code. Can you do a brief overview of what has changed?
> 
> Sure thing.  The transform_tree operation was ignoring existing
> conflicts when it updated the conflict list.  The actual bug was in
> Merger, which was taking the list of conflicts from the merge operation,
> and setting the working tree conflicts list to that.
> 
> There was a second bug: cmd_remerge wasn't clearing the conflicts lists
> of files it was remerging.  Now, it does that too.

Is it better to clear them, and then set them again? Or to leave them
alone and fix them only if they actually go away?

If you're sure it is better to clean out the conflict list, then +1 from
me. I'm just concerned that we might end up in the same situation. Where
part 1 succeeds, but part 2 doesn't, and then it looks like we have no
conflicts.

...

> 
> Well, in the general case, it's pretty crazy to perform a merge on a
> file that already has conflicts, but if you did, it would make sense to
> combine the conflicts.  For example, a file might have a DuplicateID
> conflict, but adding a TextConflict shouldn't overwrite the DuplicateID.
> 
> Now it could be argued that we shouldn't have two identical conflicts
> for the same file, so I'd be willing to special-case that one.
> 
> But in the specific case of remerge, we've already done
> tree.set_conflicts() to clear all the conflicts for all files we're
> remerging.  So there would have to be a bug in select_conflicts for this
> to produce duplicate conflicts.
> 

I think we should keep the ability to have multiple similar conflicts on
a file. I'm not sure what exact conflicts you have, but if any of them
take a parameter, it would be possible to have multiple values for that
parameter and the same conflict type.

But certainly we wouldn't like to see:

Text conflict in foo.py
Text conflict in foo.py
Text conflict in foo.py

After doing something like remerge.

The rest I'm perfectly happy with.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEpyWwJdeBCYSNAAMRAnz7AKDLQjrZ3m0FMMt14pKEQlsDsl4jpwCg1Y+Z
c0JMKZm8mxGnVUasC48m6Hs=
=PkB3
-----END PGP SIGNATURE-----