patch versus 3-way merge for moved contents

[Aaron Bentley]

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

Martin Pool wrote:
| On 28/10/05, John A Meinel <john at arbash-meinel.com> wrote:
|
|>Sometimes, one of the advantages of patch is that it uses a local
|>context to determine where the patch should be applied.
|
|
| Yes, it might well do better in some cases.  Wiggle might be better again.
|
| I suppose people won't know ahead of time whether it will be better or
| not.  If the 3-way merge is bad, people could invoke diff/patch by
| hand using the BASE/OTHER/THIS files, but it might be nice if it was
| more automatic.
|
| It might be good if there were a command something like
|
|   bzr remerge --merge-type=patch hello.c
|
| that looked up the correct parents and did the merge again.

Yeah, that could be neat.  We can use pending-merges to find the common
base.

And we can plug in any of our existing merge strategies
(merge3[--show-base][--reprocess], weave, diff3) quite easily.

Maybe it's too magic, but we could try each option and keep the results
that left us with the least conflicts.  Sort of like pngcrush for
conflicts. :-)

| It might be good if there were a command something like
|
|   bzr remerge --merge-type=patch hello.c

Sure.  There's certainly room for diff/patch merging in our stable.

|
| We could have the automatic merge try a patch if it gets conflicts on
| the 3-way merge, but that probably depends on having a reliable way to
| detect which one is better.

I worry a bit about the risk of incorrect clean merges if we do that.

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

iD8DBQFDYZBP0F+nu1YWqI0RApJGAJ97b01uDQUF++9nejz9RV4P6st7uwCfUyY9
R1hOHZjPpMnSOwtogDM62Pk=
=3c8p
-----END PGP SIGNATURE-----