On Wed, Mar 19, 2008 at 11:11:59PM +0000, Julian Foad wrote:
> If we accept this principle that the basic algorithm should report all such
> conflicts, then some of the complexities that have been mentioned
> disappear. For example, looking at UC5 (rename onto a modified file), we
> wondered about a modified version of this use case in which the
> merge-source included not just a rename but a modification followed by a
> rename. We wondered whether we should try to follow the history of
> Merge-Left (Foo.c) forward in the source branch to find what it looked like
> at the point it was finally deleted. This is unnecessary, as we have no
> reason to want the merge to succeed if the target isn't similar to the
> merge-left source.
I can't recall this discussion properly, I'm afraid.
What do you mean by "the target isn't similar to the merge-left source"?
If you mean a text-comparison, how do you define "similar"?
Is the decrease in complexity you mention already covered in detection.txt,
with or without your patch?
I approve your version of the patch to detection.txt, by the way,
and will commit it. Thanks for improving my wording in several places
by an order of magnitude :)
> I expect a similar simplification can be made for UC5, but I haven't done that yet.
You must mean a different use case, because you talked about UC5
above already :)
Stefan Sperling <stsp_at_elego.de> Software Developer
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de Geschaeftsfuehrer: Olaf Wagner
Received on 2008-03-21 16:20:21 CET
- application/pgp-signature attachment: stored